PC Card Standard 7.0

P C C A R D S TA N D A R D
Volume 1
Overview and Glossary
PCMCIA
JEIDA
©1999, PCMCIA/JEIDA PCMCIA HAS BEEN NOTIFIED BY OS/2 is a trademark of IBM
All rights reserved. CERTAIN THIRD PARTIES THAT Coporation.
THE IMPLEMENTATION OF THE
No part of this publication may be STANDARD WILL REQUIRE A Intel and Pentium are registered
reproduced, stored in a retrieval LICENSE FROM THOSE THIRD trademarks of Intel Corporation.
system, or transmitted, in any form or PARTIES TO AVOID
by any means, mechanical, MS-DOS, OnNow and Windows NT
INFRINGEMENT OF THEIR are trademarks and Microsoft,
electronic, photocopying, recording RIGHTS. PCMCIA HAS OBTAINED
or otherwise, without prior written Windows and Win32 are registered
FROM SOME, BUT NOT ALL, OF trademarks of Microsoft Corporation.
permission of PCMCIA and JEIDA. THOSE PARTIES A GRANT OF
Printed in the United States of All other product names are
IMMUNITY THAT PCMCIA WILL
America. trademarks, registered trademarks, or
EXTEND TO YOU, CONTINGENT
PCMCIA (Personal Computer UPON YOUR ENTERING INTO servicemarks of their respective
Memory Card International AND DELIVERING TO PCMCIA owners.
Association) THE RECIPROCAL GRANT OF
2635 North First Street, Suite 209 IMMUNITY AGREEMENT
San Jose, CA 95134 USA CONTAINED ELSEWHERE IN
+1-408-433-2273 THIS STANDARD.
+1-408-433-9558 (Fax) IMPORTANT:
http://www.pc-card.com
In order to receive the Grant of
JEIDA (Japan Electronic Industry Immunity, the owner of this
Development Association) Standard must sign and return the
Kikai Shinko Kaikan, 3-5-8, Shibakoen enclosed Registration Card to:
Minato-ku, Tokyo 105, JAPAN PCMCIA
+81-3-3433-1923 2635 North First Street, Suite 209
+81-3-3433-6350 (Fax) San Jose, CA 95134 USA
http://www.pc-card.gr.jp
NEITHER PCMCIA NOR JEIDA
The PC Card logo and PC Card are MAKES ANY WARRANTY,
trademarks of PCMCIA, registered in EXPRESS OR IMPLIED, WITH
the United States. The PC Card logo RESPECT TO THE STANDARD,
and PC Card are trademarks of INCLUDING AS TO NON-
JEIDA, registered in Japan. INFRINGEMENT,
MERCHANTABILITY OR FITNESS
Cover Design: Greg Barr FOR A PARTICULAR PURPOSE.
THIS STANDARD IS PROVIDED TO
YOU ÒAS IS.Ó
Document No. 0299-01-2000

First Printing, February 1999
OVERVIEW AND GLOSSARY
CONTENTS
1. Introduction____________________________________________1
1.1 PC Card Standard Overview ..............................................................................................1
1.2 History .................................................................................................................................2
1.2.1 History of the PC Card Standard ........................................................................................................................................2
1.2.2 PCMCIA Standard Release 1.0/JEIDA 4.0 (June 1990)...............................................................................................3
1.2.3 PCMCIA Standard Release 2.0/JEIDA 4.1 (September 1991)..................................................................................3
1.2.4 PCMCIA Standard Release 2.01 (November 1992) ......................................................................................................3
1.2.5 PCMCIA Standard Release 2.1/JEIDA 4.2 (July 1993) ...............................................................................................3
1.2.6 PC Card Standard February 1995 (Release 5.0) ............................................................................................................3
1.2.6.1 PC Card Standard March 1995 Update............................................................................................................4
1.2.6.2 PC Card Standard May 1995 Update................................................................................................................4
1.2.6.3 PC Card Standard November 1995 Update.....................................................................................................4
1.2.6.4 PC Card Standard March 1996 Update............................................................................................................4
1.2.7 PC Card Standard March 1997 (Release 6.0) .................................................................................................................4
1.2.8 PC Card Standard 6.1 Update (April 1998)....................................................................................................................4
1.2.9 PC Card Standard Release 7.0 (February 1999) ............................................................................................................5
1.3 Uses......................................................................................................................................6
1.4 Future Trends ......................................................................................................................6
1.5 The PC Card Standard ¾ A PCMCIA and JEIDA Joint Release......................................7
2. Definitions and Terminology ____________________________9

3. Compatibility _________________________________________11
4. Technical Descriptions _________________________________13
4.1 Electrical Specification.......................................................................................................13
4.2 Physical Specification........................................................................................................14
4.3 Metaformat Specification..................................................................................................15
4.4 Card Services Specification ...............................................................................................16
4.5 Socket Services Specification.............................................................................................17
4.6 Media Storage Formats Specification ...............................................................................18
4.7 PC Card ATA Specification..............................................................................................19
4.8 XIP (eXecute In Place) Specification .................................................................................20
4.9 Guidelines ..........................................................................................................................21
4.10 Host System Specification...............................................................................................22
4.11 Specific Extensions ..........................................................................................................23
4.11.1 PCMCIA Specific Extensions ............................................................................................................................................2 3
Ó 1999 PCMCIA/JEIDA iii

CONTENTS
4.11.1.1 Auto-Indexing Mass Storage (AIMS).............................................................................................................2 3

4.11.1.2 15 Position Shielded Latching I/O Connector ............................................................................................2 3
4.11.1.3 Modem I/O Connector for Open Systems.....................................................................................................2 3
4.11.1.4 Recommended Extensions..................................................................................................................................2 3
4.11.2 JEIDA Specific Extensions .................................................................................................................................................2 3
4.11.2.1 Small Block FLASH Format ..............................................................................................................................2 3
4.11.2.2 Still Image, Sound and Related Information Format for PC Card Digital Still Camera (DSC)
68-Pin Standards.........................................................................................................................................................2 3
4.11.2.3 DRAM Card Specifications................................................................................................................................2 3
5. Glossary______________________________________________ 25
iv Ó1999PCMCIA/JEIDA
1. I N T R OD U C T ION
This Overview describes the Personal Computer Memory Card International Association (PCMCIA)
and the Japan Electronic Industry Development Association (JEIDA) PC CardÔ Standard which is
the result of countless hours of effort by the members of JEIDA and PCMCIA. PCMCIA and JEIDA
are grateful for and acknowledge the dedicated efforts of the PCMCIA and JEIDA staff and
volunteer members in the creation and production of this Standard.
1.1 PC Card Standard Overview

The Personal Computer Memory Card International Association has an international membership
comprising hundreds of member companies from all disciplines: computer manufacturers,
semiconductor companies, peripheral vendors, software developers, and more. The Japan Electronic
Industry Development Association was established in 1958 as a non-profit organization interested in
contributing to JapanÕs economic prosperity by stimulating development in the electronics industry.
PCMCIA and JEIDA have developed a standard for a credit card-sized adapter, called a ÔPC CardÕ
that does for notebook and other portable computers what the AT bus did for desktop PCs ¾
provide universal, non-proprietary expansion capability.
The Physical Specification defines a 68-pin interface between the peripheral card and the PC Card
ÔsocketÕ into which it gets inserted. It also defines two standard form factors, full-size and Small PC
Cards, each in three thicknesses, called Type I, Type II and Type III. Type I, the smallest form
factor, often used for memory cards, measures 3.3 mm in thickness. Type II, available for those
peripherals requiring taller components such as LAN cards and modems, measures 5 mm thick.
Type III is the tallest form factor and measures 10.5 mm thick. Type III PC Cards can support small
rotating disks and other tall components. Smaller size cards can always fit into larger sockets but the
reverse is not true.
The Electrical Specification defines three basic classes of PC Cards: 16-bit PC Cards, 32-bit CardBus
PC Cards, and Custom Interface PC Cards. Defined are characteristics of each interface including
power, signaling, configuration, and timing requirements. Also, the PC Card Host System
Specification describes host-side power management and a thermal ratings system.
In addition to specifying electrical and physical requirements, the PC Card Standard has also
defined a software architecture to provide Òplug and playÓ capability across the widest possible
range of products. The Socket Services Specification defines a BIOS level interface that masks the
hardware implementation from card vendorsÕ drivers. It identifies how many sockets are in the host
and when a card is inserted or removed from a socket. It prevents the card driver from having to
talk directly to a specific chip. The Card Services Specification defines an Application Programming
Interface that interfaces to Socket Services and automatically provides management of system
resources, such as interrupt assignments and memory windows, for cards as they become active in
the system. Also, the Metaformat Specification defines the structure and contents of card description
information called the Card Information Structure.
The PC Card Standard also includes three application specific specifications. The Media Storage
Formats Specification defines how data are to be formatted on some PC Card storage devices. The
PC Card ATA Specification defines the operation of mass storage devices using the ANSI ATA
Interface for Disk Drives in the PC Card environment. The XIP Specification defines a method to
directly execute applications from ROM without loading the image into RAM. Also included is a set
of Guidelines intended to assist developers with implementation examples along with further
explanations of the PC Card Standard.
Ó 1999 PCMCIA/JEIDA 1
INTRODUCTION
1.2 History
1.2.1 History of the PC Card Standard

In 1985, the standardizing activity of PC Card Technology began with the Japan Electronic Industry
Development Association (JEIDA). The organization was formed to promote memory cards, personal
computers and other portable information products, and by 1990, JEIDA had released four
specifications.
The Personal Computer Memory Card International Association (PCMCIA) was founded in 1989 by
a small group of companies that wanted to standardize memory cards for the classic reasons behind
standardization ¾ multiple sources, lower and shared risks, and larger markets. At that time a
company called Poqet Computer had designed a computer that used only memory cards as
removable storage. Poqet needed software application developers to put their products on memory
cards. At the same time there were ten different types of memory cards sold by different
manufacturers and no real effort at standardizing them.
An initial group of about 25 companies met in San Jose, California and agreed on the need for
memory card standardization. This was the birth of PCMCIA. From the beginning, there have been
two primary committees within PCMCIAÑthe Technical and Marketing committees. These
committees have worked together to develop the PC Card standards based not only on what was
technologically feasible but also on what the market demanded. These two committees quickly
recognized that the same slot in a host system and the same form factor card could be used for I/O
capabilities such as fax/modem in addition to memory cards.
The ability to put I/O capabilities on a card soon became the main attraction for the adoption of the
technology in the rapidly expanding mobile computing market. The addition of a PC Card slot
would allow mobile computers to have an easily accessible bus expansion capability. PCMCIA and
JEIDA also expanded their mission and purpose to embrace any technology that would work in a
PC Card form factor rather than restricting it to silicon-based technology. This allowed for the
development of high capacity rotating storage cards.
Today, virtually every type of card imaginable is available, including fax/modems, audio, SCSI,
video, LAN adapter, and global positioning system cards. Almost all mobile computers shipped
today have PC Card sockets which support 16-bit PC Cards along with the latest 32-bit CardBus
technology. JEIDA and PCMCIA have ensured that PC Card technology has kept pace with
industry trendsÑallowing for lower voltage and higher performance cards. PC Card technology has
fast become the preferred bus expansion interface in mobile computing and is a growing force in
the mobile computing and consumer electronics markets.
PCMCIA and JEIDA are both standards setting bodies and trade associations. PCMCIAÕs mission is
ÒTo develop standards for modular peripherals and promote their worldwide adoption.Ó
There have been various revisions of the PC Card Standard as described in the following section.
2 Ó1999PCMCIA/JEIDA
1.2.2 PCMCIA Standard Release 1.0/JEIDA 4.0 (June 1990)

The first release of the Standard defined the 68-pin interface and both the Type I and Type II PC
Card form factors. The Integrated Circuit card form factor which utilized the 68-pin and socket
connectors was originally defined by the Japan Electronic Industry Development Association
(JEIDA) in 1985. The initial release of the PCMCIA Standard also specified all the electrical and
physical requirements for memory cards. It defined the Metaformat or Card Information Structure
(CIS) that is critical to interoperability and plug-andÐplay for PC Cards.
There was no concept of input/output (I/O) cards in the first release of the PC Card Standard.
1.2.3 PCMCIA Standard Release 2.0/JEIDA 4.1 (September 1991)

The second release of the standard defined an I/O interface for the same 68Ðpin interface as was
used for the PCMCIA memory cards in the first release of the Standard. The second release of the
Standard also added various clarifications to the first release, support for dualÐvoltage memory
cards, and sections dealing with card environmental requirements and test methods.
The initial version of the software Application Programming Interface (API) embodied in the
BIOSÐtype Socket Services Specification was published in Release 2.0. Many additions were made
to enhance the Card Information Structure (CIS) definitions, including the addition of geometry and
interleaving tuples. Support for eXecute In Place (XIP) was also added in this release.
1.2.4 PCMCIA Standard Release 2.01 (November 1992)

The initial version of the PC Card ATA Specification defining an interface for PC Cards using the
AT Attachment Standard was defined in this release. To accommodate rotating media PC Cards, the
Type III PC Card was added with this release. The Auto-Indexing Mass Storage (AIMS)
Specification, geared toward digital images, was also added.
The initial version of the Card Services Specification was published with this release. This part of
the standard PC Card software API defined the operating system extensions required for resource
management of cards, sockets and drivers. Socket Services was enhanced to accommodate the
requirements of the new Card Services interface.
Additional changes were made to the Metaformat (CIS) definitions to accommodate new PC Card
functionality.
1.2.5 PCMCIA Standard Release 2.1/JEIDA 4.2 (July 1993)

The Card and Socket Services software specifications were enhanced based on implementations done
in compliance with the previous Standard to form a complete and robust software architecture and
API necessary for compatible implementations.
The Electrical and Physical sections of the standard were updated with corrections and additions,
and the CIS was again improved with additional definition information.
1.2.6 PC Card Standard February 1995 (Release 5.0)

The PC Card Standard February 1995 Release added information to improve compatibility with the
Standard by requiring a Card Information Structure (CIS) on every PC Card, extending the amount
of information within the CIS, adding a Guidelines volume to help developers implement the
Standard, and defining common media storage formats.
INTRODUCTION
The Standard was also enhanced to support the following optional features:
· Low-voltage-only operation (3.3 volt)
· Hardware Direct Memory Access (DMA)
· Multiple-function cards
· Industry standard power management interface (APM)
· A high throughput 32Ðbit bus mastering interface (CardBus)
1.2.6.1 PC Card Standard March 1995 Update

Included as an errata to the First Printing of the February 1995 Release. Included general editorial
changes.
1.2.6.2 PC Card Standard May 1995 Update

Included along with the March 1995 Update in the Second Printing. Included change to Power
Waveforms at Power-on in the Electrical Specification.
1.2.6.3 PC Card Standard November 1995 Update

Included along with the March 1995 & May 1995 Updates in the Third Printing. Included Custom
Interfaces and other updates.
1.2.6.4 PC Card Standard March 1996 Update

Released only as errata. Included Flash Translation Layer, Zoomed Video Port and other updates.
1.2.7 PC Card Standard March 1997 (Release 6.0)

The PC Card Standard March 1997 Release provided a variety of compatibility and functionality
features. All of the Updates to the February 1995 release, including Custom Interfaces and the
Zoomed Video (ZV) Port Custom Interface were incorporated into this release.
A Thermal Ratings system was added that allows cards and hosts to be rated for thermal output,
providing an interface to warn users of a potentially damaging thermal condition.
The following features were also added:
· Power Management
· ISDN Function Extension Tuples
· Security and Instrumentation Card Function ID Tuples
· Physical Socket Naming
· Hot Dock/Undock Software Support
· Streamlined PC Card Software Configuration
1.2.8 PC Card Standard 6.1 Update (April 1998)

The PC Card Standard 6.1 Update added the following features:
· PCI/CardBus Power Management
· Small PC Card Form Factor

· Socket Services Packet Interface
· Win32 Bindings
· Editorial changes to the Electrical Specification, Metaformat Specification, Card Services
Specification, Media Storage Formats Specification (FTL), PC Card ATA Specification, and
PCMCIA Specific Extensions (Modem I/O Unshielded Connector)
1.2.9 PC Card Standard Release 7.0 (February 1999)

The PC Card Standard Release 7.0 added the following features:
· DVB Custom Interface
· Windows NT 4.0 Kernel Mode Bindings
· PC Card Memory Paging
· Serial Bus Adapter Function Extension Tuples
· Editorial changes to the Electrical Specification, Metaformat Specification, Card Services
Specification, and Host System Specification
INTRODUCTION
1.3 Uses
PC Card technology is used in a wide variety of products including notebook computers, sub-
notebook computers, palmtop computers, pen computers, desktop computers, cameras, printers,
telephones, medical instruments, television set-top boxes and other embedded application hosts. PC
Cards supporting storage and I/O applications for the host systems mentioned above also
incorporate PC Card technology as does the system and application software required to operate the
cards and hosts.
The PC Card Standard is aimed at developers of the above mentioned PC Card-based products
and is designed for the technical audience. The Standard is used by technical developers to create
standard PC Card products such as cards, hosts, silicon, and software.
1.4 Future Trends

The future holds great promise for the PC Card technology which has been widely adopted by the
mobile computer industry. We can look forward to the continuing acceptance of this technology by
the computing industry in desktops, printers, and other computer peripherals as well as products
that are the result of the merging of computers with other technologies such as telephones and
television set-top boxes. The future will also see the PC Card interface evolve to include high speed
serial buses to support high speed networking, video and other applications. Any applications that
require a small, portable and rugged industry standard interface to a system bus will find PC Card
technology and the PC Card Standard suitable to their needs.
PCMCIA and JEIDA will continue to maintain, enhance, and extend the PC Card Standard to
accommodate the ever-changing technological and market requirements.
1.5 The PC Card Standard ¾ A PCMCIA and JEIDA Joint

Release
This PC Card Standard had its early roots in technical organizations and volunteers in Japan and in
the United States. The more recent activities creating the PC Card Standard have been worldwide.
The Japan Electronic Industry Development Association, JEIDA, recognized the importance of
integrated circuit memory cards back in 1985 and has standardized a wide range of card interfaces
and form factors since that time. This work included publication of the JEIDA Version 3 IC Memory
Card Specifications; one of which, the 68-pin version, served as the starting point for the PC Card
Standard.
The Personal Computer Memory Card International Association, PCMCIA, was founded in Silicon
Valley, California in 1989 to promote the development and standardization of memory cards for
mobile computers. PCMCIA grew quickly to encompass a worldwide membership with chapters
and local host offices on several continents.
Beginning in 1989, JEIDA and PCMCIA worked closely together to develop the similar documents
of the JEIDA IC Memory Card Specification and the PCMCIA Standards. While these documents
and their later enhancements were similar, they were not identical and in some cases there were
discrepancies both in language and content between the documents. TodayÕs PC Card Standard is
the unified result of a joint effort between PCMCIA and JEIDA to enhance the clarity and scope of
the documents as well as to resolve the differences between the specifications.
The PC Card Standard is published jointly by PCMCIA and JEIDA. Thousands of hours contributed
by corporations and individuals from all around the globe have supplemented the efforts of the
professional staffs of JEIDA and PCMCIA in creating this worldwide PC Card Standard.
2. DE F IN IT ION S AN D TE R MIN OL OGY

There are many terms and conventions used in the PC Card Standard and a good understanding
of them will make reading and working with the Standard much easier. General terms and
conventions that can be broadly applied will be described in this section. Specific terms and
conventions that relate to individual sections of the Standard will be described at the beginning of
each section.
The term ÔPCMCIAÕ is an abbreviation for Personal Computer Memory Card International
Association, and is used to refer to the organization itself. The term ÔPC CardÕ is used to refer to the
technology as well as being a generic term for any products based upon the PC Card Standard.
ÔPC CardÕ is used as a generic term to refer to both 16-bit PC Cards and 32-bit CardBus PC Cards.
The term ÔPC Card StandardÕ is the official name of the set of specifications produced jointly by
PCMCIA and JEIDA. The term ÔStandardÕ, with a capital ÔSÕ, is a proper name used as a short form
replacement for the complete term: the PC Card Standard.
When referring to products (both card and sockets) that support 16-bit operation, the terms Ô16-bit
PC CardÕ or Ô16-bit PC Card socketÕ should be used. ÔCardBus PC CardÕ is the correct term that can
be used when referring to the 32-bit bus master specification of the PC Card Standard. Note that
both the ÒCÓ and the ÒBÓ are capitalized. The terms ÔPCMCIA CardsÕ and ÔPCMCIA socketÕ should
never be used.
3 . C O M P AT I B I L I T Y
Over time, PC Cards containing new technologies have been introduced, and significant new
capabilities have been added to the Standard. At the same time, considerable experience has been
gained by card, host and software vendors, and opportunities to improve compatibility have been
recognized. The goal remains to make PC Card technology as easy to use as possible with the ideal
scenario being that the customer takes the PC Card out of its box, plugs it into the system and
begins to use it. It is recommended that in order to support PC Card technology, developers keep
the goal of compatibility in mind and use the areas of the Standard designed to support
compatibility and interoperability. Also, there is opportunity within the PCMCIA organization
meetings to discuss compatibility and share information.
The Standard encompasses many capabilities and optional features. Due to this complexity,
manufacturers can choose different feature sets or even have different interpretations. 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 of the significant components: from software functions and modules to entire platforms.
On a very general level, the following describes how a card and system interact when they are
Òcompatible:Ó
For a card to operate properly, the host must first be able to provide adequate power at the correct
voltage(s) to identify and operate the card. It must successfully identify the card by reading its Card
Information Structure (CIS), and, in some cases, by sensing several pins on the interface. These pins
are important in systems mechanically able to accept CardBus or other low voltage cards. The CIS
contains detailed information on a card including its allowed ÒconfigurationsÓ which tell the host
system the various ways that the card can be set up and what system resources are required.
Once the card has been identified, the system must determine if the card requires a user-installed
Card Services client driver (typically LAN cards, SCSI cards, audio cards or CardBus cards). If no
user installed driver software is found, the system then determines whether the card can be
supported by the hostÕs built-in ÒSuper ClientÓ driver (typically memory cards, ATA devices or
Fax/Modems). The host then links the card with the appropriate driver and configures the card and
the socket.
In the case of a data storage device such as a memory card or disk drive, the file system must be
able to access the data on the card. This sometimes requires a link to be established with a specific
installable file system.
A user may want to ÒsuspendÓ and ÒresumeÓ the operation of notebook or other system with PC
Cards in the slots. To do this successfully, a card-specific routine must communicate with advanced
power management software, which must then access the card through Card and Socket Services.
Lastly, Card Services Client Drivers must operate consistently from one card supplier to the next,
and be as flexible as possible to accommodate varying system configurations automatically. Also,
Òcard-awareÓ application programs, like communications programs, need to coexist with older
applications programs.
4 . TE C H N IC AL DE S C R IP T ION S
4.1 Electrical Specification

The Electrical Specification specifies the connector pinout, interface protocol, signaling environment,
interface timings, programming model, and specifics of card insertion, removal, power up, and
configuration. The Electrical Specification describes three basic classes of PC Cards: 16Ðbit PC
Cards, CardBus PC Cards, and Custom Interface PC Cards.
The 16-bit PC Card interface provides an ISA compatible interface for full-size and Small PC Cards.
This interface supports standard ISA interrupts, and is intended to support both memory and I/O
applications. The 16-bit PC Card interface also supports advanced features such as DMA.
To address the class of applications which require higher performance and to take advantage of host
systems that implement the PCI system bus, a 32-bit interface was developed known as CardBus.
This interface provides 32-bit bandwidth, reduced latency via bus master capability, or both.
CardBus hosts are required to support 16-bit PC Cards. The Small PC Card form factor does not
support the CardBus interface.
Custom Interface PC Cards allow the PC Card interface to be tailored to specific applications. The PC
Card Custom Interface has been used to provide a high speed video path through the Zoomed
Video (ZV) Port Custom Interface and to provide security to television set-top boxes through the
Digital Video Broadcasting (DVB) Custom Interface. PC Cards which implement Custom Interfaces
must include CIS information to allow a compatible host to identify and configure the card for
operation.
TECHNICAL DESCRIPTIONS
4.2 Physical Specification

The Physical Specification specifies the PC CardÕs physical outline dimensions, basic mechanical
capabilities and the environmental conditions under which the PC Cards are expected to operate.
Information is provided for Type I, II, and III full-size and Small PC Cards, for 5 volt and low
voltage equivalents, and CardBus (the 32-bit PC Card interface).
Interface dimensions for the 68-position host connectors (with pin contacts) and the mating card
connectors (with female socket contacts) are provided. The specification, in consideration of EMI
issues, also presents a method for grounding the PC Card along with applicable material and
electrical considerations helpful to both system designers and card users. Connectors for CardBus
applications are included. A special host/header connector is required that will assure proper
grounding. This host will also accept standard low voltage Type I, II and III PC Cards.
Host PCB board layout dimensions are provided for various footprint options, for both SMT (Surface
Mount Technology) and through-hole mounting.
The PC Cards are intended to function in both office and harsh environments. These environments
are defined. Test criteria are provided using industry MIL, ISO and JIS Standard specifications. This
provides manufacturers with quantitative data to help confirm expected application performance. It
is up to the individual suppliers to qualify their parts to this, and any other manufacturerÕs
specification.
Separate criteria are defined for PC Cards involving SRAM and rotating memory components.
Where applicable, the specificationÕs requirements include considerations for PC Cards
incorporating write-protect switches and batteries.
4.3 Metaformat Specification

The Metaformat Specification specifies the structure and contents of card description information.
This card description information is stored on the card and is commonly called the Card Information
Structure or CIS.
As is done with networking standards, the Metaformat is a hierarchy of layers. Each layer has a
number, which increases as the level of abstraction gets higher. Below the Metaformat is the
physical layer: the electrical and physical interface characteristics of PC Cards. The Metaformat
layers include the Basic Compatibility Layer, the Data Recording Format Layer, the Data
Organization Layer, and the System-Specific Layer.
The benefits of using Metaformat include flexibility in describing configuration options, ability to
handle numerous somewhat incompatible data recording formats and data organizations.
4.4 Card Services Specification

The Card Services Specification specifies a software Application Programming Interface (API). The
main purpose behind the Card Services (CS) API is to provide a universal software interface that is
independent from the hardware that manipulates PC Cards and PC Card Sockets.
The Card Services interface has two goals. The first is to promote sharing of PC Cards, sockets and
host system resources. Second, the interface provides a centralized location for common functionality
required by PC Card software. The Card Services interface is structured in a client/server model.
Software applications and device drivers that utilize PC Cards are the clients. Card Services is the
server providing services requested by the clients.
The API is specified in a host system/operating system-independent format. However, there are
bindings included that describe the detail of how to access a Card Services implementation in a
particular environment. Clients register with Card Services and are notified of PC Card events
synchronously via a Callback. Clients use Card Services to allocate system resources to a PC Card
function and to configure the PC Card.
Card Services is very closely related to Socket Services. Card Services is the middle layer in a
multiple layer software architecture. The clients make up the top layer of the architecture.
4.5 Socket Services Specification

The Socket Services Specification specifies a software Application Programming Interface (API). The
main purpose behind the Socket Services (SS) API is to provide a universal software interface to the
hardware that controls sockets for PC Cards. The interface masks the details of the hardware used to
implement these sockets. This masking allows the development of higher-level software that is able
to utilize PC Cards without any detailed knowledge of the actual hardware interface.
Socket Services manages the hardware by utilizing it as a number of object types. Each object type
has a particular area of functionality. Sockets are the receptacles for PC Cards. Windows provide
access via host system memory or I/O address space to PC Card address space. EDC Generators
calculate error detection codes by monitoring data transfers. Adapters connect a host systemÕs bus to
PC Card sockets and provide the sockets, windows and EDC generators.
Individual services of Socket Services provide certain functionality. Some services allow software to
inquire about the capabilities for a specified object. Other services return the current settings of a
specified object. Also, the settings for a specified object are updated using other services. In addition,
there are services that report on current card status and provide indirect access to PC Cards for
socket controllers that cannot map PC Card address space into host system address space.
Socket Services performs all of these services when software requests them. These requests are made
in a host system processor and operating environment-specific manner. For example, on x86
architecture platforms running DOS, a Socket Services implementation is invoked via a software
interrupt with commands and data passed in CPU registers.
Socket Services is very closely related to the Card Services Specification. Socket Services is the
lowest layer in a multiple layer software architecture.
4.6 Media Storage Formats Specification

The Media Storage Formats Specification specifies how data are formatted on PC Card storage
devices to promote the exchange of these cards among different host systems. These include
memory cards using various types of volatile and non-volatile devices and ATA disk drives, for
both silicon and rotating media. Each of these storage technologies have unique characteristics
which may benefit from different storage techniques and handling. This has resulted in the
development of different storage formats and/or partitioning for PC Cards using these devices.
The Media Storage Formats Specification is intended to provide enough information to allow
software developers to use data stored on PC Cards by other host systems using potentially different
operating and file systems. Unless required to understand the data structures used on the PC Card,
algorithms for updating the data on the PC Card are not specified, only the storage format.
NOTE: The inclusion of partition, file format, translation layer or media type
information in this document does not constitute an endorsement by
PCMCIA or JEIDA. PCMCIA and JEIDA are only acknowledging this
information has been used to record data on a PC Card and, in some cases,
that PCMCIA and JEIDA members have agreed that using the documented
implementation may reduce problems encountered when attempting to
interchange data between host systems.
4.7 PC Card ATA Specification

The PC Card ATA Specification specifies the operation of mass storage PC Cards using the protocol
of the ANSI AT Attachment (ATA) Interface for Disk Drives (X3.221-1994) in the PC Card
environment. This standard includes both the usage of the ANSI ATA-defined protocols and the
differences required due to conflicts between the PC Card and ANSI ATA Standards.
The PC Card ATA Specification defines four mappings of the ANSI ATA Command/Control
Registers into host memory and I/O space: memory mapped, block I/O, ANSI ATA Primary and
ANSI ATA Secondary. This definition includes how the 8-bit ANSI ATA registers are accessed and
the use of the RESET, READY, and IREQ# signals depending on whether memory mapped or I/O
mode addressing is used.
Since both the PC Card ATA Specification and the ANSI ATA Standard define resets, the effects
and protocols associated with the different reset methods are described. The method for
implementing ANSI ATA Master/Slave devices is described as the Twin Card option in the PC
Card ATA Specification, detailing the operation required since inter-card communication is not
provided. In addition, both Cylinder-Head-Sector as well as Logical Block addressing are supported.
Finally, mandatory and optional CIS tuples for PC Card ATA mass storage devices are defined to
ensure that PC Card ATA implementations are consistent from vendor to vendor.
4.8 XIP (eXecute In Place) Specification

The XIP (eXecute In Place) Specification specifies a method to directly execute applications from
ROM without loading the image of the application into RAM prior to execution. The benefit of XIP
is savings of both system RAM and system ROM. Usually, in the non-XIP world, a program is
loaded from a disk (or ROMDISK) and essentially copied into system RAM, from where it is
executed. Thus, there is an immediate waste of space since two images of the program exist: one in
RAM and one on the disk. Under the XIP scheme, only the data is stored in RAM; code is left
executing from the original instance in ROM. The current PC Card specification for XIP is designed
primarily for low-end real mode x86 type systems, where price sensitivity is high and system RAM
is a precious resource.
The XIP Specification describes the Metaformat tuples, data structures, driver architecture, and the
Application Programming Interface (API) for XIP, as well as the architecture and load format of XIP-
compliant applications.
Three types of XIP support are defined in order to support three real-world architectures: LXIP, SXIP
and EXIP.
LXIP is for systems where demand-paging is required (i.e., pages not in memory must be explicitly
paged in by software at some level). LXIP Applications are structured to operate in a 16 KB paged-
execution environment.
SXIP is for those systems which have only very limited paging mechanisms. SXIP applications
comprise an execution image of at most 64K of code and/or read-only data, and are monolithic in
nature. These applications do no overlaying of any sort.
EXIP is for those systems with very large address spaces or with implicit paging (i.e., pages not in
memory when accessed are placed into memory without intervention at a software level). EXIP
applications are structured to operate in an environment where no paging is necessary, similar to an
Intel 80386 extended-addressing-mode-execution environment.
4.9 Guidelines
The Guidelines document provides implementation examples and further explanations of the PC
Card Standard to:
· Enhance the interoperability of PC Card components, including card hardware and
software, system hardware and software, and applications.
· Facilitate the development of PC Card technology by increasing the understanding of the
Standard by PC Card Implementation community.
These guidelines are not requirements made by the PCMCIA or JEIDA Standards organizations.
Rather, they are implementation examples, suggestions and hints. The Guidelines included are
described below.
Electrical Guidelines
· CardBus/PCI Common Silicon
· Thermal Logo Usage
Physical Guidelines
· Modem I/O Unshielded Connector for Open Systems
· 15 Position Shielded Latching I/O Connector
· Maximum I/O Connector Dimensions
· Extended Card Dimensions
Software Guidelines
· Enabler Capabilities and Behavior
· Card-Application Interaction
· CardBus Operational Scenarios
· CIS Design for Several Common Implementations
4.10 Host System Specification

The PC Card Host System Specification specifies requirements for host systems containing a PC
Card socket.
The System Thermal and Power section defines a method which can be used in determining the
host platform thermal rating. The purpose of determining the thermal rating is to ensure that the
heat generated and dissipated within the body of the PC Card does not thermally exceed the
capabilities of the host system to remove excessive heat in order to maintain the PC Card at an
acceptable temperature limit.
The PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges establishes a
standard set of PCI peripheral power management hardware interfaces and behavioral policies.
Once established, this infrastructure enables an operating system to intelligently manage the power
of PCI functions and buses.
The PCI-to-CardBus Bridge Register Description section is provided to aid in development of
CardBus bridges that have some level of software interface commonality. The device described is a
bridge between a PCI bus and two CardBus/16-bit PC Card sockets.
4.11 Specific Extensions

Prior releases of the PC Card Standard included two additional volumes: PCMCIA Specific
Extensions and JEIDA Specific Extensions. These two volumes allowed each organization to provide
specifications unique to its respective clientele, while maintaining all other features under a
common standard release. As of the current release, there are no unique specifications. The
following sections explain the disposition of the previous Specific Extensions.
4.11.1 PCMCIA Specific Extensions
4.11.1.1 Auto-Indexing Mass Storage (AIMS)

The AIMS Specification has been removed from the PC Card Standard. Please refer to previous
releases of the PC Card Standard or contact PCMCIA for the AIMS Specification.
4.11.1.2 15 Position Shielded Latching I/O Connector

This section has been moved to the Guidelines.
4.11.1.3 Modem I/O Connector for Open Systems

4.11.1.4 Recommended Extensions

4.11.2 JEIDA Specific Extensions
4.11.2.1 Small Block FLASH Format

This specification has been extended and included as the Physical Format Specification of the
SmartMedia Standard.
4.11.2.2 Still Image, Sound and Related Information Format for PC Card
Digital Still Camera (DSC) 68-Pin Standards
This specification is maintained independently by JEIDA. Please refer to previous releases of the PC
Card Standard or contact JEIDA for this specification.
4.11.2.3 DRAM Card Specifications

This specification is maintained independently by JEIDA. Please refer to previous releases of the PC
Card Standard or contact JEIDA for this specification.
5 . G L OS S AR Y
Combined Terms and Abbreviations

16-bit PC Card PC Cards using the PC Card Standard 16-bit interface originally defined in PCMCIA 1.0/JEIDA 4.0 and
PCMCIA 2.0/JEIDA 4.1 publications.
access latency The time between a master requesting access to CardBus PC Card and the completion of the first data
phase. Access latency consists of three parts: arbitration latency, bus acquisition latency and target
latency.
Adapter The hardware which connects a host system bus to 68-pin PC Card sockets.
Address Space An address space is a collection of registers and storage locations contained on a PC Card which are
distinguished from each other by the value of the Address Lines applied to the Card. There are three
separate address spaces possible for a card. These are the Common Memory space, the Attribute
Memory space and the I/O space.
Address Space(s), A reference to the three separate physical address spaces of CardBus PC Card: memory, I/O, and
CardBus configuration.
A reference to any of the CardBus PC Card card's physical address spaces, which include:
· six spaces which may map the card I/O or memory into the host system address space
· one space which may map the card expansion ROM into the host system address space
· the card's configuration spaces (one for each function)
agent A logical entity that operates on a host system bus. The term applies collectively to functions of a bus
master, a bus slave or to a combination of both.
ANSI ATA Standard ANSI X3.221-1994.
Application Program Interface A function interface provided by one level of software to the level above it.
(API)
arbitration latency The first component of access latency. The time that the master waits after having asserted CREQ# until
it receives CGNT#.
area See memory area.
ASCIIZ A text string in ASCII format terminated with a byte of zero.
Asserted A signal is asserted when it is in the state which is indicated by the name of the signal. Opposite of
Negated.
asserted, deasserted These terms refer to the state of a signal on the clock (CCLK) rising edge, not to signal transitions.
AT Acronym for Advanced Technology. Refers to a 16-bit host system architecture using the 80x86
processor family which formed the basis for the ISA Bus definition.
ATA Acronym for AT Attachment. Refers to the interface and protocol used to access a hard disk in AT
compatible host systems. Disk drives adhering to the ATA protocol are commonly referred to as IDE
interfaced drives for PC compatible host systems.
ATA Command Block See Command Block registers.
ATA Registers These registers are accessed by a host to implement the ATA protocol for transferring data, control and
status information to and from the PC Card. They are defined in the ÒANSI ATA Standard.Ó These
registers include the Cylinder High, Cylinder Low, Sector Number, Sector Count, Drive/Head, Drive
Address, Device Control, Error, Feature, Status, and Data registers. The I/O and memory address
decoding options for these registers are defined in the PC Card ATA Specification
ATA Soft Reset The condition of the PC Card ATA mass storage card when the SRST bit in the Device Control register
is set. This condition directly affects only the ATA registers and protocol. Except for reflecting the state of
the Busy condition and Interrupt condition, the Configuration registers are unaffected.
Attribute Memory 16-bit PC Card memory region selected by the REG pin for storage of CIS data and card configuration
registers.
Attribute Memory Space One of the three address spaces available on a PC Card. This address space is accessed by memory
read and memory write operations which occur while the REG# signal is asserted. This address space
is defined only for bytes located on even byte addresses. This space is the primary location for the Card
Information Structure and for the Configuration registers on the card.
GLOSSARY
Audio Device A device that normally provides both a speaker and microphone for input/output of audio. Optionally, if the
application allows, the device can be limited to only output (speaker) capability.
Average Current Maximum current required averaged over 1 second.
backoff A directive to terminate the current transaction and retry it at a later time, also referred to as retry.
Base Address Register Window A memory or I/O space mapping supported by a Base Address Register in the card's configuration
space.
BIOS Acronym for Basic Input/Output System. When BIOS is in Read-Only Memory devices it may be
referred to as ROM BIOS.
BIST register An optional register in the header region of the CardBus Configuration Space. It is used for control and
status of built-in self tests.
bit field A field containing only 1 bit.
Block A block is the basic 512 byte region of storage into which the storage media is divided. Addressing in the
ATA protocol is performed on block boundaries. Each block of data represents one sector of data using
the ATA Cylinder-Head-Sector address protocol. The Logical Block Address protocol uses sequential
block addresses to access the media.
Block Allocation Map (BAM) An FTL control structure that is used to store Erase Unit block allocation information when hidden areas
are not used to store this information. See the Media Storgage Formats Specification.
BPB Acronym for BIOS Parameter Block. A data structure used by the Microsoft BPB/FAT File System to
describe the size and format of storage media.
bridge The logic that connects one computer bus to another, allowing an agent on one bus to access an agent on
the other, such as a CardBus controller.
BSY (ATA Busy bit) A bit in the ATA Status register which is used by the ATA protocol to indicate that the ATA registers on
the card are not available for use by the host.
burst transfer The basic data transfer mechanism of CardBus PC Cards. A burst is comprised of an address phase
and one or more data phases.
bus acquisition latency The second component of access latency. The amount of time that a requesting device waits for the bus
to become free after CGNT# has been asserted.
bus commands Used to indicate to a target. The type of transaction the master is requesting.
bus master An agent which has an ability to obtain control of the interface and perform memory or I/O reads and
writes to system resources. The master initiates a bus transaction.
Bus Segment Reset Bus Segment Reset is defined as the hardware reset signal that is taken as actual physical input to a
given component within a system. For example the Bus Segment Reset signal for a PCI to CardBus
bridge component is RST# as defined in the PCI Local Bus Specification. For CardBus cards, this is
the CRST# signal.
bus slave An agent that sends or receives data under control of a bus master, also referred to as bus target or a bus
transaction target.
There are two types of slaves:
I/O slave - selected by its address in the I/O address space;
memory slave - selected by its address in the memory address space.
Callback Handler A Client routine to which Card Services may transfer control when events requiring Client notification
occur.
Card Configuration and Status This Configuration register provides the host control for the following functions: Status Changed Signal,
Register Audio Signal, and Power Down Request. It provides status information about Status Changed state and
Interrupt Request state. In addition, it can be used to advise the card that all I/O to the card will be eight
bits wide. Refer to the PC Card Standard Electrical Specification for detailed information about this
register.
Card Enumeration The process performed by the host to provide a unique card identification number to each drive when the
Twin Cards option is used. The host writes a unique number to the Copy field in the Socket and Copy
register of each card sharing the same configuration.
Card Information Structure A data structure which is stored on a PC Card in a standard manner which contains information about
(CIS) the capabilities of the card as well as the formatting and organization of data on the card.
Card software Software which configures and/or accesses the card. This may include:
· device drivers
· applications
· generic enablers
In PC Card parlance, card software is that software which could be a Card Services client.
CardBus Function A set of functionality inside a CardBus card represented by one 256 byte configuration space. Each
CardBus function within a device generally has a separate software driver.
CardBus PC Card PC Cards which use the 32-bit interface defined in the PC Card Standard. A single CardBus PC Card
may contain up to eight CardBus Functions.
CardBus PC Card adapter The chip(s) that isolate(s) the CardBus PC Cards from the rest of the system. Depending on the
definition of the system bus, this might be a set of electrical buffers or it may be a complete bus bridge.
This is the same as the host CardBus PC Card adapter.
CardBus PC Card arbiter A function which controls access to the CardBus PC Card interface.
CardBus PC Card connector An expansion connector that conforms to the electrical and mechanical requirements of the PC Card
Standard for CardBus PC Cards.
CardBus PC Card sequencer An entity which performs the actual CardBus PC Card operations in a device, e.g., a state machine. The
sequencer guarantees that the CardBus PC Card protocol is not violated.
CardBus PC Card socket A receptacle into which a CardBus PC Card can be inserted. The term socket has similar meaning, but
can apply to either 16-bit PC Card, CardBus PC Card, or both types of sockets.
central resource The interface support functions supplied by the host system which is typically in a host CardBus PC
Card adapter, or could be distributed in the system.
CHS Acronym for Cylinder-Head-Sector addressing.
CIS Acronym for Card Information Structure.
Clear (a bit) A bit is Cleared when its value is set to "0."
Client A user of Card Services, Socket Services, or XIP functions. May be a device driver, utility program or
application program.
clock edge (or edge) Refers to the rising edge of the clock (CCLK). The only time that the signals have any significance on
the CardBus PC Card interface is at the rising edge of the clock.
Cluster Another term for a block.
Command Block Registers The ATA Command Block registers include the following ATA registers: Data register(s), Error register,
Feature register, Sector Count register, Sector Number register, Cylinder Low register, Drive/Head
register, Command register, and Status register, but not the Alternate Status register. Seven of the
Command Block registers are written by the host to provide a command and its parameters. These
registers are: Feature register, Sector Count register, Sector Number register, Cylinder Low register,
Cylinder High register, Drive/Head register, and Command register.
Common Memory Conventional memory area on 16-bit PC Cards when REG# is negated.
Common Memory Space This 16 bit wide, memory space is one of the three address spaces available on the 16-bit PC Card.
This address space is accessed by memory read and memory write operations which occur while the
REG# signal is negated. This address space is defined both for bytes located at even and odd byte
addresses. A PC Card bus multiplexing protocol is used to ensure that the odd bytes of this space can
be accessed by both eight and 16 bit hosts. The ATA registers are located in this space when Memory
Mapped ATA registers are supported.
Configuration Configuration is a process by which a host initializes or alters its socket operation and the Configuration
registers on a PC Card to match the PC Card's capabilities to the host's capabilities and available
system resources.
configuration address space See configuration space
configuration cycle A CardBus PC Card cycle used for system configuration via the configuration address space.
Configuration Option Register This register is the first of the Card Configuration registers located in the Attribute Memory Space of a
PC Card. It is used by the host to control the PC Card's Configuration Index in bits 5 to 0, its Interrupt
Mode in bit 6 (Pulsed = 0 or Level =1) and the PC Card Soft Reset in bit 7 (Soft Reset asserted = 1).
Configuration Registers A set of registers, defined by the PC Card Standard, which are used by the host to control the operational
configuration of the card.
Configuration Space A CardBus PC Card address space, used for configuration and error handling, which consists of a 64-
byte header space and a 192-byte device-dependent space.
Contiguous I/O Addresses An I/O address decoding in which the Card decodes address lines (example A[3::0]), while the Socket is
responsible for decoding all other address lines to produce the Card Enable signals for I/O cycles to the
card.
Control Block Registers The ATA Control Block registers include the following ATA registers: Alternate Status register, Device
Control register and Drive Address register.
Custom Interface Custom Interfaces support enhanced features, such as internal bus extensions, or customized signals
not applicable across architectures.
Cylinder Group of tracks accessed without moving the head used to read or write rotating media.
Cylinder-Head-Sector Address A method for specifying the location of a block of data on a mass storage device. This is the traditional
method for addressing a block of data on rotating media using the ATA protocol. This method partitions
an address into a cylinder portion, one or more heads within each cylinder and one or more sectors
within each cylinder-head combination.
GLOSSARY
DAA Direct Access Attachment. A device that provides electrical protection to telecommunications medium. It
may be internal or external to a Modem I/O Card. (See Guidelines)
Device Dependent Space The last 192 bytes of the CardBus PC Card Configuration Space. In this context, ÒdeviceÓ is synonymous
to Òfunction.Ó
Digital Video Broadcasting Port A PC Card Custom Interface which provides a bi-directional video and audio bus and a command
control interface providing a DVB compliant Conditional Access system.
Direct Memory Access (DMA) The process of moving data from I/O to memory or vice versa without the intervention of the processor.
Direct Memory Access, third When DMA is performed by a DMA controller as opposed to having an I/O device become a master on
party the bus and move the data to/from memory on its own.
Directory A system file used to maintain the structure of a file system.
DMA Acronym for Direct Memory Access
DOS Acronym for Disk Operating System. More specifically, the term refers to MS-DOS, DR DOS, Novell
DOS, Datalight ROM DOS, et al.
Double Word A 32-bit block of data, also known as Quadlet.
Dual Drive The Dual Drive option defines a single PC Card ATA mass storage card that contains two separate and
distinct logical ATA devices. One device acts as the ATA Master, the other as the ATA Slave.
DUT Device Under Test.
DVB An acronym for Digital Video Broadcasting, a European television standardization body
DWORD See Double Word.
Edge Sensitive Interrupt An interrupt detected by the host system based upon the transition of the signal from negated to asserted.
The host must see the edge to latch this type of interrupt. Commonly used in ISA Bus machines.
EISA Acronym for Extended Industry Standard Architecture. Refers to an expansion bus promoted by
manufacturers of IBM-compatible personal computers that feature 32-bit addressing and bus-mastering
capabilities. Not compatible with Micro Channel. Compatible with ISA 8-bit and 16-bit adapter cards.
EISA Bus An internal host Bus which is available in some hosts and can be used to connect PC Card sockets to the
host CPU. An EISA bus can program each interrupt request line for either positive-true, edge sensitive,
interrupts (IRQn) or negative-true, level sensitive, interrupts (IRQn#).
End-user A person who uses a host system.
Erase Unit The area of flash media that is handled as a single erasable unit by the FTL. An Erase Unit may be one
(1) or more Erase Zones. All Erase Units in an FTL partition are the same size. The size of an Erase
Unit is set when the FTL partition is formatted and the Erase Unit Headers written to the media. See the
Media Storgage Formats Specification.
Erase Unit Header An FTL data structure that describes an Erase Unit. See the Media Storgage Formats Specification.
Erase Zone An area of flash media that must be erased as a single unit due to the characteristics of the media. May
be determined from DGTPL_BUS and DGTPL_EBS in the Device Geometry Info field of the Device
Geometry tuple, if present in the Card Information Structure. See the Media Storgage Formats
Specification.
exclusive access An access to a target's address range which is guaranteed to complete without being interrupted by an
access to the same target by another bus master. Also known as atomic operation.
FFS Acronym for Flash File System.
field Depending on context, field may have different meanings.
· In the context of a tuple, a field is the smallest readable unit which has a distinct meaning.
· In the context of configuration and memory space, a field is a distinct area in a register.
File A related unit of information stored on media.
File System Part or extension of an operating system that manages files on a host system. May be limited or
optimized to one type of media.
Flash A type of non-volatile media that may allow byte read and write access, but requires the media to be
erased before it is written. In addition, erase operations are required to be performed on a block of
contiguous bytes.
FTL Acronym for Flash Translation Layer.
Function A PC Card capability, for example, a modem or LAN function.
function X (X is a number) In a multifunction PC Card, each function is numbered uniquely. Numbering begins at 0, and all cards
will therefore have a function 0. From the Card Services' client point of view, functions are numbered 1
to n, and all cards will therefore have a function 1.
generic enabler A Card Services client which is capable of configuring a variety of cards. It may or may not have other
capabilities such as:
· providing an alternate interface to Card Services
· providing the user information about the installed cards
This type of enabler is not custom designed for configuring specific cards; but, using the CIS and the
Card Services interface, it can configure many different kinds of cards.
graceful rejection It is made clear to the user that the PC Card is not usable in that socket, either through a message
(visual or audio), or mechanical keying. In addition, no data corruption and no physical, electrical, or
functional damage is caused to the system or card.
Handle A Card Services assigned identifier associated with Card Services managed system resources.
Hardware Reset See PC Card Hardware Reset.
Hardware Window A 16-bit PC Card physical window (either memory or I/O). This is an area in a host systemÕs memory
or I/O address space through which a 16-bit PC Card may be addressed.
Header Space The first 64 bytes of the CardBus PC Card Configuration Space. The Header Space consists of fields
which allow a CardBus PC Card function to be generically controlled. See also Device Dependent
Space.
Hidden Arbitration Arbitration that occurs during a previous access so that no CardBus PC Card bus cycles are consumed
by arbitration, except when the bus is idle.
High (Logic Level) A signal is in the high logic state when it is above VIH level. See the PC Card Standard Electrical
Specification for the precise electrical definition.
Host A computer system or other equipment which contains hardware (a Socket) and software for utilizing a
PC Card.
Host System Same as host
hot swapping The ability to insert or remove a PC Card without cycling the system power or re-booting the system.
I/O An abbreviation for Input / Output.
I/O Address Space The I/O address space is one of the three address spaces available on a PC Card. The I/O address
space is accessed by asserting the I/O Read signal, IORD#, or the I/O Write signal, IOWR#, while the
Attribute Memory Select Signal, REG#, and at least one Card Enable, CE1# or CE2# are asserted.
I/O Card PC Card Standard compliant card used for I/O (input/output) operations and connected internally to
medium via a Medium Access Device. (See Guidelines)
I/O Cycle An I/O cycle is an Input operation(I/O Read) or Output operation (I/O Write) which accesses the PC
Card's I/O address space.
I/O Interface The I/O Interface is an interface supporting both memory cycles and I/O cycles. This interface is not
active at power up or following a PC Card reset. This interface is permitted to be enabled when both the
PC Card socket and PC Card installed in the socket support the I/O interface. The host configures a PC
Card for the I/O interface using the Configuration Option register. PC Cards which support the I/O
interface must indicate their support in the CIS on the card.
I/O Mapped A storage location or register is I/O mapped when it is available to be accessed using I/O cycles. The
register or storage location might also be accessible using memory cycles, in which case it would also
be memory mapped.
IDE Acronym for Integrated Drive Electronics. Disk storage devices with IDE are often referred to as ATA
drives.
idle state Any clock period that the bus is idle (CFRAME# and CIRDY# are deasserted).
IEEE Acronym for the Institute for Electrical and Electronic Engineers
IEEE 1394 A high speed serial bus that supports both arbitrated asynchronous communications and high-priority
isochronous transmissions necessary for real-time full motion video and other high-speed data transfer.
Init. or Initialization The state that a device must enter immediately following the Reset state. In this state, the device must
allow access to its Configuration Space. It must draw a minimum current/power necessary for
accessing its Configuration Space, and for the device initialization.
IREQ# The Interrupt Request signal between a PC Card and a socket when the I/O interface is active.
IRQn One of the Interrupt Request Signals between a socket and the host's CPU. Selection of the specific
Interrupt Request Signal which is used to carry an Interrupt Request from a PC Card to the Host's CPU
is controlled by hardware associated with the socket. Depending upon the host system implementation
the IRQn signal may be either IRQn or IRQn#.
ISA Acronym for Industry Standard Architecture. Refers to an IBM-compatible expansion bus of the type
incorporated in IBM-AT compatible personal computers. Uses 16-bit addressing.
ISA Bus Acronym for Industry Standard Architecture Bus. An internal host Bus which is available in some hosts
and can be used to connect PC Card sockets to the host CPU. While serving the same basic purpose as
GLOSSARY
a Micro Channel bus or an EISA bus, some bus protocols and signals are different. An ISA bus uses
positive-true, edge sensitive, interrupt request lines (IRQn).
JEDEC Acronym for Joint Electronic Device Engineering Council.
JEIDA Acronym for Japan Electronic Industry Development Association.
keepers Another name for pull-up resistors that are only used to sustain a signal state.
latency See access latency.
latency timer A mechanism for ensuring that a bus master does not extend the access latency of other masters beyond
a specified value.
LBA Acronym for Logical Block Address.
legacy PCI devices A class of devices built before the PCI Bus Power Management Interface Specification for PCI-to-
CardBus Bridges was added to the PC Card Standard and are PC Card Standard, February 1995
compliant. Legacy PCI to CardBus bridge and CardBus card devices are assumed to be in the D0 power
management state whenever power is applied to them.
Level Sensitive Interrupt A host system interrupt based upon the logic level of the signal which causes repeated interrupts as long
as the interrupt request signal is in the asserted state, and the interrupt request is not disabled. Used in
Micro Channel Architecture bus hosts and available in EISA bus hosts.
LIM Acronym for Lotus/Intel/Microsoft, commonly used to refer to an Expanded Memory Specification, for
page swapping and memory management on DOS-based computers (LIMÊ4.0).
livelock A condition in which two or more operations require completion of another operation before they can
complete.
Logical Address An address based on accessing the media in Logical Erase Unit order. See the Media Storgage
Formats Specification.
Logical Block Address A logical block address is a sequential address for accessing the blocks on the storage media. The first
block of the media is addressed as block 0 and succeeding blocks are numbered sequentially until the
last block is encountered.
Logical Erase Unit Number A logical number assigned to an Erase Unit by the FTL. The FTL assigns logical numbers to Erase
(LogicalEUN) Units to remap the ordering of the physical media and simplify recovering superseded areas. See the
Media Storgage Formats Specification.
LONGLINK A LONGLINK is a pointer from one tuple chain to another. Such a link is described by one of the
LONGLINK tuples: CISTPL_LONGLINK_A, CISTPL_LONGLINK_C, CISTPL_LONGLINK_CB. See
Metaformat Specification
Low (Logic Level) A signal is in the low logic level when it is below or equal to the VIH level. See the Electrical
Specification for the precise electrical definition.
LSB Acronym for Least Significant Bit and Least Significant Byte. That portion of a number, address or field
which occurs rightmost when its value is written as a single number in conventional hexadecimal or
binary notation. The portion of the number having the least weight in a mathematical calculation using the
value.
Mandatory A characteristic or feature which must be present in every implementation of the standard.
mapping Associating a given card address space with a host system address space.
master See Bus Master
master-abort A termination mechanism that allows a master to terminate a transaction when no target responds.
Maximum Interface A 7 position connector interface on the I/O Modem PC Card, connected to DAA. (See Guidelines)
MBR Acronym for Master Boot Record. An MBR is a specially formatted first physical sector on block
storage media.
Media Material used to store data. May be silicon, magnetic oxide or any other material that can retain
information for later retrieval.
Medium Access Device A device that provides access to a communications medium; in this instance through a Data Access
Arrangement (Modem or Modem-FAX). (See Guidelines)
memory area An area of the card memory addressed by a memory handle. It may be part of a single memory region
or span two or more memory regions.
Memory Cycle A memory cycle is a memory read operation (using Output Enable) or memory write operation (using
Write Enable) which accesses the PC Card's common memory or attribute memory address space.
memory handle A Card Services-assigned identifier for a card memory area. Used to access memory on a card with the
Card Services read, write, copy, and erase memory functions.
Memory Interface The memory interface is the default interface after power up, PC Card Hardware Reset and PC Card
Soft Reset for both PC Card cards and sockets. This interface supports memory operations only.
Contrast with I/O interface.
Memory Mapped A storage location or register is memory mapped when it is available to be accessed using memory
cycles. The register or storage location might also be accessible using I/O cycles, in which case it would
also be I/O mapped.
memory paging A method of extending PC Card memory space to contain as many as 242 Common Memory locations.
Without memory paging, the 26 address signals at the PC Card connector allow 64Mbytes of Common
Memory.
memory region A homogeneous card memory area using one type of memory device.
Metaformat Low level format standard of a PC Card.
Micro Channel Micro Channel Architecture. Refers to an IBM expansion bus of the type incorporated in some of the
personal computers in the PS/2 line. Features 32-bit addressing and bus-mastering capabilities. Not
compatible with ISA or EISA. A Micro Channel Bus uses negative-true, level sensitive, interrupt request
lines (IRQn#).
Minimum Interface A 4 position connector interface on the I/O Modem PC Card, connected to DAA. (See Guidelines)
motherboard A circuit board containing the basic functions (e.g., CPU, memory, I/O, and expansion connectors) of a
host system.
MSB Acronym for Most Significant Bit and Most Significant Byte. That portion of a number, address or field
which occurs leftmost when its value is written as a single number in conventional hexadecimal or
binary notation. The portion of the number having the most weight in a mathematical calculation using the
value.
MTD Acronym for Memory Technology Driver. Embedded or installable component of Card Services that
contains device-specific read, write, copy and erase algorithms.
Negated A signal is negated when it is in the state opposed to that which is indicated by the name of the signal.
See the Conventions section. Opposite of Asserted.
NMI Acronym for Non-Maskable Interrupt (usually caused by a catastrophic error).
Offset The offset of a port or a memory location is the difference between the address of the specific port or
memory address and the address of the first port or memory address within a contiguous group of ports
or a memory window. This term is used when identifying the locations of registers located with respect
to the base address of a block of contiguous I/O ports. It is also used when identifying the location of
memory mapped registers with respect to the base address of the memory window.
Open System Cards Cards which contain selected I/O connectors and electrical-performance components, such that cables
using connector plugs described herein can be used interchangeably with similar function cards
regardless of supplier. (See Guidelines)
Operating System Software on a host system that manages resources and provides services, including power
management services, device drivers, user mode services, and/or kernel mode services.
optional A characteristic or feature which is not mandatory, but is specifically permitted. If an optional
characteristic or feature is present, it must be implemented as described in this the PC Card Standard.
Optional characteristics or features are specifically identified.
GLOSSARY
originating device From the perspective of the operating system (Host CPU), the first bridge component encountered with
a PCI bus downstream of it is defined as the Originating Device for that PCI bus segment. For a
CardBus card, the originating device is the PCI to CardBus bridge controlling its bus (see figure below).
CPU
Host Bus I/F
Host Bridge
Originating Device
PCI Bus I/F for bus(0)
PCI Bus(0)
Primary Bus I/F
PCI to CardBus
Bridge
Secondary Bus I/F Originating Device
for CardBus bus
CardBus bus
output driver An electrical drive element (transistor) for a single signal on a CardBus PC Card device.
page A subdivision of a 16-bit PC Card window. If there is more than one page in a window, all pages are 16
KBytes in size.
Paging See memory paging
partition A subdivision of a storage device, typically formatted for use with a single type of file system.
PC Acronym for Personal Computer. Often used to refer to an 80x86 based computer system.
PC Card A memory or I/O card compatible with the PC Card Standard. When cards are referred to as PC
Cards, what is being addressed are those characteristics common to both 16-bit PC Cards and CardBus
PC Cards.
PC Card Hardware Reset PC Card Hardware Reset is caused when the socket asserts the RESET signal to the PC Card. During
PC Card Hardware Reset, the PC Card interface is set to be the Memory Only Interface, and the
Configuration Option register is set to 00H. Other configuration registers and the READY signal are also
affected as detailed in the PC Card Standard.
PC Card Soft Reset PC Card Soft Reset is caused when the host sets bit 7 of a PC Card's Configuration Option register. PC
Card Soft Reset is asserted while bit 7 of Configuration Option register is set. The effect of PC Card Soft
Reset is identical to the effect of PC Card Hardware Reset except that bit 7 of the Configuration Option
register is not cleared by the reset condition. Because the other bits of the Configuration Option are
written at the same time as the PC Card Soft Reset bit, it is recommended that the PC Card Soft Reset
bit be cleared by writing a 00H to the Configuration Option register.
PC Card Standard The PC Card Standard. The applicable revision is given in the Related Documents section.
PCI Acronym for the Peripheral Component Interface bus
PCI to CardBus bridge PCI to CardBus bridges couple two independent buses together. They are characterized by a primary
bus interface, and a secondary bus interface and are always a PCI bus and a CardBus card bus.
PCI device A physical device consisting of one load on the PCI bus and having only one IDSEL input. This single
PCI Device may contain up to 8 PCI Functions.
PCI or CardBus function A set of functionality inside a PCI or CardBus Device represented by one 256 byte configuration space.
Each PCI and CardBus function within a device generally has a separate software driver.
PCI Function Context The variable data held by the PCI function, usually volatile. Function context refers to small amounts of
information held internal to the function. Function Context is not limited only to the contents of the
functionÕs PCI registers, but rather refers also to the operational states of the function including state
machine context, power state, execution stack (in some cases), etc. For a PCI to CardBus Bridge, the
internal status and mask registers and the VCC control signals would be a special case of Function
Context which must be preserved.
PCMCIA Acronym for the Personal Computer Memory Card International Association.
peer-to-peer This term is used to describe data transfers between two agents which are both capable of gaining the
bus mastership. It is used to specify the rules of changing the master/slave relationships between such
agents.
phase One or more clocks in which a single unit of information is transferred, consisting of:
· an address phase (a single address transfer)
· a data phase (one transfer state plus zero or more wait states)
Physical Address An address based on accessing the media in Physical Erase Unit order. See the Media Storgage
Physical Erase Unit Number The number assigned to an Erase Unit based on its location on the physical media. This number never
(PhysicalEUN) changes and is implied by the Erase Unit's position on the media. The Erase Unit at the beginning of an
FTL partition is known as the First Physical Erase Unit. If the partition begins at physical address zero
(0), the First Physical Erase Unit is number zero (0). See the Media Storgage Formats Specification.
Pin Replacement Register The Pin Replacement register is the third Card Configuration register. It is used to retrieve status
information from the PC Card about Battery, Busy and Write Protect while the card has the I/O interface
active.
plug-n-play An ability to insert and put into operation, or remove a PC Card without cycling the system power, re-
booting the system, or requiring a manual user intervention for configuration.
PME Context Power Management Event Context is defined as the functional state information and logic required to
generate Power Management Events (PMEs), report PME status, and enable PMEs.
positive decoding A method of address decoding in which a device responds to accesses only within an assigned address
range. See also subtractive decoding.
POST Acronym for Power-On Self Test. A series of diagnostic routines performed when a system is powered
up.
power management Mechanisms in software and hardware to minimize system power consumption, manage system
thermal limits and maximize system battery life. Power management involves tradeoffs among system
speed, noise, battery life, and AC power consumption.
Power Management Event A power management event is the process by which a PCI or CardBus function can request a change of
(PME) its power consumption state. Typically a device uses a PME to request a change from a power savings
state to the fully operational (and fully powered) state. However, a device could use a PME to request a
change to a lower power state. A power management event is requested via the assertion of the PME#
signal for a PCI-to-CardBus Bridge, assertion of CSTSCHG for a CardBus card and STSCHG# for a
PC Card. The power management policies of the system ultimately dictate what action is taken as a
result of a power management event.
primary (ordinate) bus/side The primary bus of a PCI to CardBus bridge or CardBus PC Card refers to the bus that is topologically
closest to the CPU that is running the operating system.
Primary I/O Addresses As applicable to PC Card ATA mass storage cards, it is the set of addresses 1F0H-1F7H and 3F6H-3F7H
at which the first fixed disk controller is located in a PC/AT computer system. Use of these addresses
allows emulation of the first ATA or IDE disk controller at its standard addresses.
Pull-ups Resistors used to insure that signals maintain stable values when no agent is actively driving the bus.
Pulse Mode Interrupt A method of transmitting an Interrupt Request from a PC Card to a socket using the IREQ# signal. In this
mode, the IREQ# signal is asserted momentarily when the Card initiates an interrupt and is then negated
regardless of whether or not the interrupt is acknowledged. The method of acknowledgment is specific to
devices on the PC Card. In the case of a PC Card ATA mass storage card, acknowledgment takes place
when the ATA Status register is read. The pulse mode interrupt is designed to be used with the ISA bus
(and the EISA bus when ISA bus interrupt emulation is being performed). The host socket must use an
"open-collector" non-inverting output to drive the ISA bus IRQn signal when it is expecting to share pulse
mode interrupts from the PC Card.
Read/Write Block A subdivision of an Erase Unit. Used by the FTL to track media allocation. The FTL maintains the
allocation state of each Read/Write Block. See the Media Storgage Formats Specification.
READY When asserted, this signal Indicates that the PC Card is completely available for use. The negated state
of the READY signal is used by a PC Card to indicate that it is busy with an internal operation and
access to the card may be restricted. Refer to the Electrical Specification, READY signal and
GLOSSARY
RREADY bit for detailed information about this signal.

Region See memory region.
Replacement Page Values in a Replacement Page override values in the original page of the Virtual Map as follows: If an
entry in an original page is zero (0), the logical address is retrieved from the corresponding entry on the
Replacement Page. Replacement pages delay the need to reallocate a Page in the Virtual Map when an
entry in the page is updated. See the Media Storgage Formats Specification.
Reset Refers to the state of a bit within a register or variable. Reset is equivalent to off or zero(0). It is the
deviceÕs default state after Power-up or reset.
restore time Restore time is defined as the time required to fully restore a PCI or CardBus function to its fully
operational state from a power saving mode of operation. It is measured as the total elapsed time
between when the system software request for restoration occurs to when the function is fully configured
and activated.
Retry A directive to terminate the current transaction and retry it at a later time, also referred to as backoff.
RREADY The Registered READY Status Bit, RREADY, is located in the Pin Replacement register if that register
is present on the PC Card. The bit is provided to indicate the state of the READY function while the
READY signal is unavailable because the Memory-Only Interface is not currently configured on the card.
secondary (subordinate) The secondary bus of a PCI to CardBus bridge or CardBus PC Card refers to the bus that is
bus/side topologically farthest from the CPU that is running the operating system.
Secondary I/O Addresses As applicable to a PC Card ATA mass storage card, it is the set of addresses 170H-177H and 376H-377H
at which the second fixed disk controller is located in a PC/AT computer system. Use of these
addresses allows emulation of the second ATA or IDE disk controller at its standard addresses.
Sector The smallest unit of information that may be stored on a block device. Typically 512 bytes, but may be
other powers of two in size (128, 256, 1024, 2048, etc.).
Set Refers to the state of a bit within a register or variable. Set is equivalent to on or one(1).
Shared memory Any memory accessible by more than one agent.
Sideband signal Any signal that is not part of the CardBus PC Card that connects two or more CardBus PC Card
compliant agents, and has meaning only to those agents.
sleeping state A computer state where the computer consumes a small amount of power, user mode threads are not
being executed, and the system ÒappearsÓ to be off (from an end userÕs perspective, the display is off,
etc.). Latency for returning to the Working state varies on the wakeup environment selected prior to entry
of this state (for example, should the system answer phone calls, etc.). Work can be resumed without
rebooting the OS because large elements of system context are saved by the hardware and the rest by
system software. It is not safe to disassemble the machine in this state.
Small PC Card A PC Card form factor measuring 45.00 mm by 42.80 mm in various heights. The Small PC Card form
factor does not support the CardBus interface.
Socket The socket is the hardware, 68 pin socket, in the host which is responsible for accepting a PC Card into
the host and mapping the host's internal bus signals to the PC Card interface signals.
Socket and Copy Register The Socket and Copy register is the fourth Card Configuration register located on a PC Card. One use of
this Configuration register allows the host to configure a PC Card ATA mass storage card to respond as
either Drive 0 or Drive 1.
soft off state A computer state where the computer consumes a minimal amount of power. No user mode or system
mode code is run. This state requires a large latency in order to return to the Working state. The
systemÕs context will not be preserved by the hardware. The system must be restarted to return to the
Working state. It is not safe to disassemble the machine.
Special Cycle A message broadcast mechanism for communicating processor status and/or (optionally) logical
sideband signaling between CardBus PC Card agents.
SRAM Acronym for Static Random Access Memory.
SRST (Soft Reset Bit) The ATA Soft Reset Bit, SRST, is located in the Device Control register of a PC Card ATA mass
storage card. This bit provides the ATA Soft Reset Function but does not cause the PC Card interface to
perform PC Card Reset processing.
Status Changed Signal The Status Changed Signal is present at the PC Card interface only when the I/O Interface is enabled. It
(STSCHG#) is asserted when any of the four Changed Status bits in the Pin Replacement register are set while the
Enable Status Changed bit is set in the Card Configuration and Status register. This signal replaces the
BVD1 signal of the Memory-Only interface when the I/O Interface is configured.
stepping The ability of an agent to spread assertion of qualified signals over several clocks.
subtractive decoding A method of address decoding in which a device accepts all accesses not positively decoded by other
agents. See also positive decoding.
system bus arbiter A function which controls access to the system bus.
system master An agent or a group of agents which controls system configuration and resource management. This is
the same as host from the CardBus PC Card point of view.
system software Includes Socket Services, Card Services and generic enablers.
target An agent that responds (with a positive acknowledgment by asserting CDEVSEL#) to a bus transaction
initiated by a master.
target abort A termination mechanism that allows a target to terminate a transaction in which a catastrophic error
has occurred, or to which the target will never be able to respond.
target latency The third component of access latency - the amount of time that the target takes to assert CTRDY# for
the first data transfer.
Task File Registers In obsolete versions of the ATA Specification, ATA Command Block registers were referred to as the
Task File. See Command Block registers.
termination A transaction termination brings the bus transaction to an orderly and systematic conclusion. All
transactions are concluded when CFRAME# and CIRDY# are deasserted (an idle cycle). Termination
may be initiated by the master or the target.
Thermal Rating A number representing the heat generated by PC Cards (see the Physical Specification) or the ability
of PC Card hosts to remove heat (see the PC Card Host System Specification).
Track Group of sectors all accessed by a single head on one cylinder of a rotating media storage device.
transaction An address phase plus one or more data phases.
transfer state Any CardBus PC Card clock, during a data phase, in which data is transferred.
Transfer Unit An Erase Unit reserved for storing Read/Write Blocks from an Erase Unit being emptied by the FTL
prior to erasure. Transfer Units are not included in the formatted size of the FTL partition presented to
the host file system. See the Media Storgage Formats Specification.
Tuple A tuple is an element of a Card Information Structure. Each tuple has a tuple code which identifies the
type of tuple which is present, a tuple length which specifies the amount of space occupied by the tuple,
and an information area which contains the content of the tuple. Tuples located in the CIS of a PC Card
are examined by host software to determine the capabilities of the card.
tuple chain A linked set of tuples which is parsed completely before any LONGLINK is followed to another tuple
chain. There is at most one LONGLINK per tuple chain.
tuple parsing The action performed by a client whereby a CIS is interpreted into configuration requests and other
useful information.
tuple traversal Locating and reading in sequence all of the tuples on the card. This action is best performed by Card
Services for a client. This is also referred to as "tuple walking" or "walking the CIS.Ó
turnaround cycle A CardBus PC Card cycle used to prevent contention when one agent stops driving a signal and another
agent begins. A turnaround cycle must last one clock and is required on all signals that may be driven by
more than one agent.
Twin Cards An optional field in a Configuration Entry tuple which permits configurations to be described in which
several cards share the same system resources such as I/O ports. The cards are uniquely labeled by
the host using the Copy Number field of the Socket and Copy register. For PC Card ATA, this feature is
used to permit a Drive 0 and a Drive 1 to coexist at the same Primary or Secondary I/O addresses.
Support for the Twin Cards Option is optional in PC Card ATA mass storage cards.
Universal Serial Bus A serial bus standard which allows operation at 12 Mbps with a low speed un-shielded sub-channel
operating at 1.5 Mbps, and offers both asynchronous and isochronous data transfer.
USB See Universal Serial Bus
User Within this document, the term ÒuserÓ refers to the user of Card Services, typically a higher-level
software layer such as a client, and not the end-user of the host computer.
Virtual Address The address recorded in a Read/Write Block's allocation information representing where the stored data
appears in the virtual image presented to the host system. See the Media Storgage Formats
Specification.
Virtual Block The unit of information used by the file system layer above the FTL to read and write data to the media.
The FTL uses Virtual Block sizes that are a logical power of two of 128 bytes or larger. The Virtual
Block size is set when the FTL partition is formatted.
Virtual Block Map (VBM) An array of 32-bit entries used to map a Virtual Block number to a logical address on the media. Space
is always reserved on the media to store the entire VBM. The FirstVMAddress field describes how
much of the VBM is maintained on the media by the FTL.
Virtual Page Map (VPM) An array of 32-bit entries used to map Pages of the Virtual Block Map to a logical address on the media.
The VPM is never stored on the media.
wait state A CardBus PC Card clock, during a data phase, in which no transfer occurs.
Wakeup Event An event which can be enabled to wake the system from a Sleeping or Soft Off state to a Working state
to allow some task to be performed.
GLOSSARY
Window An area in a host computer's memory or I/O port space through which a PC Card may be addressed.
working state A computer state where the system dispatches user mode (application) threads and they execute. In this
state, devices (peripherals) are dynamically having their power state changed. The user will be able to
select (through some user interface) various performance/power characteristics of the system to have
the software optimize for performance or battery life. The system responds to external events in real
time. It is not safe to disassemble the machine in this state.
X86 Any of a number of CPU chips compatible with the Intel iAPX8086, the Intel iAPX80286, the Intel
iAPX80386, the Intel iAPX80486, or the Intel Pentium.
XIP Acronym for eXecute-In-Place. Refers to specification for directly executing code from a PC Card.
Zoomed Video Port A PC Card Custom Interface which provides a single-source uni-directional video bus between a PC
Card socket and a VGA controller.
ZV Port See Zoomed Video Port
Volume 2
Electrical Specification
PCMCIA
JEIDA
©1999, PCMCIA/JEIDA PCMCIA HAS BEEN NOTIFIED BY
All rights reserved. CERTAIN THIRD PARTIES THAT
No part of this publication may be STANDARD WILL REQUIRE A
reproduced, stored in a retrieval LICENSE FROM THOSE THIRD
by any means, mechanical, INFRINGEMENT OF THEIR
or otherwise, without prior written FROM SOME, BUT NOT ALL, OF
Printed in the United States of IMMUNITY THAT PCMCIA WILL
America. EXTEND TO YOU, CONTINGENT
PCMCIA (Personal Computer UPON YOUR ENTERING INTO
Memory Card International AND DELIVERING TO PCMCIA
+1-408-433-9558 (Fax) IMPORTANT:
JEIDA (Japan Electronic Industry In order to receive the Grant of
Development Association) Immunity, the owner of this
Kikai Shinko Kaikan, 3-5-8, Shibakoen Standard must sign and return the
Minato-ku, Tokyo 105, JAPAN enclosed Registration Card to:
+81-3-3433-1923 PCMCIA
+81-3-3433-6350 (Fax) 2635 North First Street, Suite 209
San Jose, CA 95134 USA
The PC Card logo and PC Card are
trademarks of PCMCIA, registered in NEITHER PCMCIA NOR JEIDA
the United States. The PC Card logo MAKES ANY WARRANTY,
and PC Card are trademarks of EXPRESS OR IMPLIED, WITH
JEIDA, registered in Japan. RESPECT TO THE STANDARD,
INCLUDING AS TO NON-
INFRINGEMENT,
FOR A PARTICULAR PURPOSE.
YOU ÒAS IS.Ó

ELECTRICAL SPECIFICATION
CONTENTS
1. Overview ______________________________________________1
1.1 Summary of Electrical Specification Changes....................................................................2
1.1.1 PCMCIA 2.0/JEIDA 4.1 (September 1991).......................................................................................................................2
1.1.2 PCMCIA 2.1/JEIDA 4.2 (July 1993)....................................................................................................................................2
1.1.3 PC Card Standard February 1995 Release (Release 5.0) ............................................................................................2
1.1.4 PC Card Standard March 1995 Update (Release 5.01)...............................................................................................3
1.1.5 PC Card Standard May 1995 Update (Release 5.02)...................................................................................................3
1.1.6 PC Card Standard November 1995 Update (Release 5.1)..........................................................................................3
1.1.7 PC Card Standard May 1996 Update (Release 5.2) .....................................................................................................3
1.1.8 PC Card Standard 6.0 Release (March 1997) .................................................................................................................3
1.1.9 PC Card Standard 6.1 Release (April 1998)....................................................................................................................3
1.1.10 PC Card Standard 7.0 Release (February 1999)..........................................................................................................3
1.2 Conventions .........................................................................................................................3

1.2.1 Signal Naming............................................................................................................................................................................4
1.2.2 Numeric Representation..........................................................................................................................................................4
1.2.3 Bit Action Representation.......................................................................................................................................................4
1.2.4 Signal Summary ........................................................................................................................................................................4
2. Common Pin Description ________________________________5

2.1 Power and Ground Pins ......................................................................................................5
2.1.1 VCC and GND Pins....................................................................................................................................................................5
2.1.2 VPP1 and VPP2 Pins...................................................................................................................................................................5
2.2 Interface Configuration Pins ...............................................................................................6

2.2.1 Card Detect Pins (CD[2::1]# and CCD[2::1]#)..................................................................................................................6
2.2.2 Voltage Sense Pins (VS[2::1]# and CVS[2::1]) .................................................................................................................6
3. Card Type Detection Mechanism _________________________7

3.1 PC Card Encodings .............................................................................................................7
3.2 Socket Key Selection ............................................................................................................8
3.3 Graceful Rejection in 16Ðbit PC Card Only Sockets...........................................................8
3.4 Determining Card Type in CardBus PC Card Capable Sockets........................................9
4. 16-bit PC Card Electrical Interface _______________________11

4.1 Compatibility Issues .........................................................................................................11
4.1.1 RESET and WAIT# Support................................................................................................................................................1 1
4.1.2 VS1# replaces RFSH (pin 43)...............................................................................................................................................1 1
4.2 Pin Assignments................................................................................................................11

4.3 16-bit PC Card Features....................................................................................................14
© 1999 PCMCIA/JEIDA iii

CONTENTS
4.3.1 Memory Address Space........................................................................................................................................................1 4

4.3.2 Memory Only Interface .........................................................................................................................................................1 5
4.3.3 I/O Address Space..................................................................................................................................................................1 5
4.3.4 I/O Interface ..............................................................................................................................................................................1 6
4.3.5 Custom Interfaces ....................................................................................................................................................................1 6
4.3.6 Configurable Cards ................................................................................................................................................................1 7
4.4 Signal Description..............................................................................................................17

4.4.1 Address BUS (A[25::0]).........................................................................................................................................................1 7
4.4.2 Data BUS (D[15::0]) ................................................................................................................................................................1 7
4.4.3 Card Enable (CE[2::1]#)........................................................................................................................................................1 7
4.4.4 Output Enable (OE#) ..............................................................................................................................................................1 8
4.4.5 Write Enable (WE#)................................................................................................................................................................1 8
4.4.6 Ready (READY) .......................................................................................................................................................................1 8
4.4.7 Interrupt Request (IREQ#) [I/O and Memory Interface]...........................................................................................1 9
4.4.7.1 Interrupt Request Routing......................................................................................................................................1 9
4.4.7.2 Level and Pulsed Mode Interrupt Support......................................................................................................2 0
4.4.7.2.1 Level Mode Interrupt Signal ......................................................................................................................2 0
4.4.7.2.2 Pulsed Mode Interrupt Signal....................................................................................................................2 0
4.4.8 Card Detect (CD[2::1]#) .........................................................................................................................................................2 1
4.4.9 Write Protect (WP) [Memory Only Interface]................................................................................................................2 1
4.4.10 I/O Is 16 Bit Port (IOIS16#) [I/O and Memory Interface].....................................................................................2 1
4.4.11 Attribute Memory Select (REG#)....................................................................................................................................2 1
4.4.12 Battery Voltage Detect (BVD[2::1]) [Memory Only Interface].............................................................................2 2
4.4.13 Status Changed (STSCHG#) [I/O and Memory Interface] ....................................................................................2 2
4.4.14 Audio Digital Waveform (SPKR#) [I/O and Memory Interface].......................................................................2 2
4.4.15 Program and Peripheral Voltages (VPP[2::1]) ............................................................................................................2 3
4.4.16 Voltage and Ground (VCC & GND) ...............................................................................................................................2 3
4.4.16.1 Socket VCC for CIS Read......................................................................................................................................2 3
4.4.16.2 PC Card VCC for CIS Read..................................................................................................................................2 4
4.4.16.3 Changing PC Card VCC........................................................................................................................................2 4
4.4.17 Voltage Sense (VS[2::1]#) ...................................................................................................................................................2 4
4.4.18 I/O Read (IORD#) [I/O and Memory Interface] .......................................................................................................2 5
4.4.19 I/O Write (IOWR#) [I/O and Memory Interface] .....................................................................................................2 5
4.4.20 Card Reset (RESET) .............................................................................................................................................................2 6
4.4.21 Extend Bus Cycle (WAIT#)................................................................................................................................................2 6
4.4.22 Input Port Acknowledge (INPACK#) [I/O and Memory Interface] ...................................................................2 6
4.5 DMA Signals Replacing I/O Interface Signals.................................................................26

4.5.1 DMA Request (DREQ#).........................................................................................................................................................2 6
4.5.2 DMA Acknowledge (DACK) [replaces REG#].............................................................................................................2 7
4.5.3 DMA Read (IOWR#) ..............................................................................................................................................................2 7
4.5.4 DMA Write (IORD#) ..............................................................................................................................................................2 7
4.5.5 Terminal Count (TC#)............................................................................................................................................................2 7
4.6 Memory Function...............................................................................................................27

4.6.1 Common Memory Function.................................................................................................................................................2 7
iv ©1999 PCMCIA/JEIDA
4.6.1.1 Common Memory Read Function for PC Cards ...........................................................................................2 7

4.6.1.2 Common Memory Write Function for PC Cards ..........................................................................................2 8
4.6.1.3 Common Memory Write Function for OTPROM, EPROM and Flash Memory...............................2 8
4.6.2 Attribute Memory Function.................................................................................................................................................2 8
4.6.2.1 Attribute Memory Read Function ......................................................................................................................2 9
4.6.2.2 Attribute Memory Write Function .....................................................................................................................2 9
4.6.2.3 Attribute Memory Write Function for Dual Supply OTPROM, EPROM and Flash Memory.....2 9
4.6.3 Write Protect Function ...........................................................................................................................................................3 0
4.7 Timing Functions...............................................................................................................30

4.7.1 Common Memory Read Timing........................................................................................................................................3 0
4.7.2 Common and Attribute Memory Write Timing..........................................................................................................3 2
4.7.2.1 Common Memory Write Timing........................................................................................................................3 3
4.7.3 Attribute Memory Read Timing Specification.............................................................................................................3 3
4.7.4 Attribute Memory Write Timing Specification............................................................................................................3 3
4.7.5 Memory Timing Diagrams .................................................................................................................................................3 4
4.8 DMA Function...................................................................................................................35

4.8.1 DMA Read Function (Memory Read - I/O Write) ......................................................................................................3 6
4.8.2 DMA Read Timing (Memory Read - I/O Write).........................................................................................................3 6
4.8.3 DMA Write Function (I/O Read - Memory Write) .....................................................................................................3 7
4.8.4 DMA Write Timing (I/O Read - Memory Write)........................................................................................................3 8
4.9 Electrical Interface .............................................................................................................39

4.9.1 Signal Interface.........................................................................................................................................................................3 9
4.9.2 Memory Address Decoding................................................................................................................................................4 0
4.9.2.1 Function Configuration Registers Address Decoding................................................................................4 1
4.9.3 I/O Address Space Decoding .............................................................................................................................................4 1
4.9.3.1 Independent I/O Address Window ..................................................................................................................4 1
4.9.3.2 Overlapping I/O Address Window..................................................................................................................4 2
4.10 Card Detect......................................................................................................................43

4.11 Battery Voltage Detect ....................................................................................................43
4.12 Power-up and Power-down............................................................................................44
4.12.1 Power-up/Power-down Timing .....................................................................................................................................4 4
4.12.2 Average Current During Card Configuration............................................................................................................4 5
4.12.3 Data Retention........................................................................................................................................................................4 6
4.12.4 Supplement ..............................................................................................................................................................................4 6
4.13 I/O Function....................................................................................................................46

4.13.1 I/O Transfer Function .........................................................................................................................................................4 6
4.13.2 I/O Input Function for I/O Cards ...................................................................................................................................4 6
4.13.3 I/O Output Function for I/O Cards................................................................................................................................4 7
4.13.4 I/O Read (Input) Timing Specification .........................................................................................................................4 8
4.13.5 I/O Write (Output) Timing Specification.....................................................................................................................5 0
4.14 Function Configuration ...................................................................................................51

4.14.1 Overview..................................................................................................................................................................................5 1
4.14.2 Single Function PC Cards...................................................................................................................................................5 1
© 1999 PCMCIA/JEIDA v
CONTENTS
4.14.3 Multiple Function PC Cards..............................................................................................................................................5 1

4.14.4 Function Configuration Registers (FCRs).....................................................................................................................5 2
4.15 Card Configuration .........................................................................................................53

4.15.1 Configuration Option Register.........................................................................................................................................5 4
4.15.2 Configuration and Status Register .................................................................................................................................5 6
4.15.3 Pin Replacement Register ...................................................................................................................................................5 8
4.15.4 Socket and Copy Register...................................................................................................................................................5 9
4.15.5 Extended Status Register ...................................................................................................................................................5 9
4.15.6 I/O Base Registers (0 .. 3) ...................................................................................................................................................6 0
4.15.7 I/O Limit Register ................................................................................................................................................................6 0
4.15.8 Power Management Support Register...........................................................................................................................6 1
4.15.9 Address Extension Registers............................................................................................................................................6 2
4.16 Indirect Access to PC Card Memory ..............................................................................64
5. CardBus PC Card Electrical Interface ____________________ 67

5.1 CardBus PC Card Signal Description...............................................................................67
5.1.1 Pin Assignments.......................................................................................................................................................................6 8
5.1.2 Signal/Pin Description..........................................................................................................................................................7 2
5.1.2.1 System Pins .................................................................................................................................................................7 2
5.1.2.2 Address and Data Pins ..........................................................................................................................................7 2
5.1.2.3 Interface Control Pins..............................................................................................................................................7 3
5.1.2.4 Arbitration Pins (Bus Masters Only) ................................................................................................................7 3
5.1.2.5 Error Reporting Pins...............................................................................................................................................7 4
5.1.2.6 Interrupt Request Pin ...............................................................................................................................................7 4
5.1.2.7 Additional Signals ..................................................................................................................................................7 4
5.1.3 Central Resource Functions..................................................................................................................................................7 5
5.2 CardBus PC Card Operation............................................................................................75

5.2.1 Bus Commands ........................................................................................................................................................................7 5
5.2.1.1 Command Definition ..............................................................................................................................................7 5
5.2.1.2 Command Usage Rules..........................................................................................................................................7 7
5.2.2 CardBus PC Card Protocol Fundamentals....................................................................................................................7 8
5.2.2.1 Basic Transfer Control ...........................................................................................................................................7 9
5.2.2.2 Addressing .................................................................................................................................................................7 9
5.2.2.3 Byte Alignment..........................................................................................................................................................8 1
5.2.2.4 Bus Driving and Turnaround..............................................................................................................................8 1
5.2.3 Bus Transactions .....................................................................................................................................................................8 2
5.2.3.1 Read Transaction .....................................................................................................................................................8 2
5.2.3.2 Write Transaction ....................................................................................................................................................8 4
5.2.3.3 Transaction Termination ......................................................................................................................................8 4
5.2.3.3.1 Master Initiated Termination....................................................................................................................8 5
5.2.3.3.2 Target Initiated Termination.....................................................................................................................8 7
5.2.4 Arbitration.................................................................................................................................................................................9 1
5.2.5 Arbitration Signaling Protocol ..........................................................................................................................................9 1
5.2.5.1 Fast Back-to-Back Transactions.........................................................................................................................9 3
vi ©1999 PCMCIA/JEIDA
5.2.5.2 CardBus PC Card Idle Condition.......................................................................................................................9 5

5.2.5.3 Latency .........................................................................................................................................................................9 5
5.2.5.3.1 Managing Latency on CardBus PC Card..............................................................................................9 5
5.2.5.3.2 Low Latency Design Guidelines...............................................................................................................9 6
5.2.6 Exclusive Access ......................................................................................................................................................................9 7
5.2.6.1 Starting an Exclusive Access................................................................................................................................9 9
5.2.6.2 Continuing an Exclusive Access.......................................................................................................................100
5.2.6.3 Accessing a Locked Agent..................................................................................................................................101
5.2.6.4 Completing an Exclusive Access......................................................................................................................102
5.2.6.5 Supporting CBLOCK# and Write-back Cache Coherency......................................................................102
5.2.6.6 Complete Bus Lock................................................................................................................................................103
5.2.7 Other Bus Operations..........................................................................................................................................................103
5.2.7.1 Device Selection......................................................................................................................................................103
5.2.7.2 Special Cycle............................................................................................................................................................104
5.2.7.3 Address/Data Stepping......................................................................................................................................105
5.2.7.4 Configuration Cycle..............................................................................................................................................106
5.2.7.4.1 Generating Configuration Cycles..........................................................................................................108
5.2.7.4.1.1 Configuration Mechanism...........................................................................................................108
5.2.7.4.1.2 Generating Special Cycles with the Configuration Mechanism ....................................110
5.2.8 Error Functions .....................................................................................................................................................................110
5.2.8.1 Parity..........................................................................................................................................................................110
5.2.8.2 Error Reporting......................................................................................................................................................112
5.2.8.2.1 Parity Error Response and Reporting on CPERR#..........................................................................112
5.2.8.2.2 Error Response and Reporting on CSERR#.......................................................................................113
5.2.9 Cache Support ........................................................................................................................................................................114
5.2.10 Clock Control.......................................................................................................................................................................116
5.2.10.1 Clock Frequency...................................................................................................................................................116
5.2.10.2 Clock Control Protocol......................................................................................................................................116
5.2.10.2.1 Clock Stop or Slow down ......................................................................................................................117
5.2.10.2.2 Clock Restart or Speed up ......................................................................................................................117
5.2.10.2.3 Maintaining the Interface Clock..........................................................................................................118
5.2.11 Status Changed Notification..........................................................................................................................................119
5.2.11.1 Card Status Changed.........................................................................................................................................119
5.2.11.2 System and Interface Wake up .......................................................................................................................119
5.2.11.3 Register Descriptions.........................................................................................................................................121
5.2.11.3.1 Function Event Register ..........................................................................................................................121
5.2.11.3.2 Function Event Mask Register..............................................................................................................123
5.2.11.3.3 Function Present State Register ............................................................................................................125
5.2.11.3.4 Force Event Capability............................................................................................................................126
5.2.11.3.5 Default Field Values ................................................................................................................................128
5.2.12 Card Audio ..........................................................................................................................................................................128
5.2.13 Special Design Considerations.....................................................................................................................................129
5.2.13.1 Multiple Retry Termination............................................................................................................................129
5.3 CardBus PC Card Electrical Specification......................................................................129

5.3.1 Overview .................................................................................................................................................................................129
© 1999 PCMCIA/JEIDA vii

CONTENTS
5.3.1.1 Dynamic vs. Static Drive Specification .........................................................................................................130

5.3.2 Component Specifications .................................................................................................................................................130
5.3.2.1 3.3 V Signaling Environment............................................................................................................................131
5.3.2.1.1 DC Specifications.........................................................................................................................................131
5.3.2.1.2 AC Specifications.........................................................................................................................................132
5.3.2.1.3 CSTSCHG Buffer Specification...............................................................................................................132
5.3.2.1.4 CCLK AC Specifications ...........................................................................................................................132
5.3.2.1.5 Maximum AC Ratings and Device Protection (CCLK) .................................................................133
5.3.2.1.6 Noise Considerations.................................................................................................................................134
5.3.2.2 Timing Specification ............................................................................................................................................135
5.3.2.2.1 Clock Specifications....................................................................................................................................135
5.3.2.2.2 Timing Parameters .....................................................................................................................................136
5.3.2.2.3 Measurement and Test Conditions.......................................................................................................137
5.3.2.3 Vendor Provided Specifications......................................................................................................................138
5.3.3 System (Motherboard) Specifications ..........................................................................................................................138
5.3.3.1 Clock Skew...............................................................................................................................................................138
5.3.3.2 Reset............................................................................................................................................................................139
5.3.3.3 Pull-ups......................................................................................................................................................................140
5.3.3.3.1 Pull-up Values for Control Signals .......................................................................................................141
5.3.3.3.2 Pull-up Values for Card Detect and Voltage Sense Pins ...............................................................141
5.3.3.3.3 Pull-up Resistor Requirements................................................................................................................142
5.3.3.4 Power Sequencing..................................................................................................................................................145
5.3.3.5 System Timing Budget ........................................................................................................................................145
5.3.3.6 Physical Requirements.........................................................................................................................................145
5.3.3.6.1 Routing and Layout of Four Layer Boards .......................................................................................145
5.3.3.6.2 Motherboard Impedance..........................................................................................................................145
5.3.4 CardBus PC Card Specifications ....................................................................................................................................146
5.3.4.1 Power Requirements.............................................................................................................................................146
5.3.4.1.1 Decoupling .....................................................................................................................................................146
5.3.4.1.2 External Power Supplies...........................................................................................................................146
5.3.4.2 Physical Requirements.........................................................................................................................................146
5.3.4.2.1 Trace Length Limits ...................................................................................................................................146
5.3.4.2.2 Impedance ......................................................................................................................................................146
5.3.4.2.3 Signal Loading.............................................................................................................................................147
5.4 CardBus PC Card Programming Model.........................................................................147

5.4.1 Overview .................................................................................................................................................................................147
5.4.2 Card Organization ..............................................................................................................................................................147
5.4.2.1 Configuration Space .............................................................................................................................................152
5.4.2.1.1 Command.......................................................................................................................................................155
5.4.2.1.2 Status................................................................................................................................................................156
5.4.2.1.3 Cache Line size .............................................................................................................................................158
5.4.2.1.4 Latency Timer...............................................................................................................................................158
5.4.2.1.5 Header Type ..................................................................................................................................................159
5.4.2.1.6 Built-in Self Test (BIST).............................................................................................................................15 9
5.4.2.1.7 Base Address Register............................................................................................................................... 159
viii ©1999 PCMCIA/JEIDA

5.4.2.1.8 CIS Pointer......................................................................................................................................................161

5.4.2.1.9 Expansion ROM Base Address Register ............................................................................................162
5.4.2.1.10 Cap_Ptr .........................................................................................................................................................163
5.4.2.1.11 Interrupt Pin ................................................................................................................................................163
5.4.2.1.12 Tuple Space..................................................................................................................................................163
5.4.2.1.13 Register Summary ....................................................................................................................................164
5.4.2.2 Memory Space ........................................................................................................................................................165
5.4.2.3 I/O Space ..................................................................................................................................................................166
5.4.2.4 Expansion ROM.....................................................................................................................................................166
5.5 Requirements For CardBus PC Cards and Sockets........................................................168

5.5.1 Overview .................................................................................................................................................................................168
5.5.2 Software Requirements ......................................................................................................................................................168
5.5.2.1 Socket Services........................................................................................................................................................168
5.5.2.2 Card Services ..........................................................................................................................................................169
5.5.2.3 System Resource Availability...........................................................................................................................169
5.5.2.4 System Resource Determination ......................................................................................................................169
5.5.2.5 Enabler Support .....................................................................................................................................................170
5.5.3 Card Requirements ..............................................................................................................................................................170
5.5.3.1 Configuration Space .............................................................................................................................................170
5.5.3.2 Required CIS............................................................................................................................................................170
5.5.3.3 Required Signals....................................................................................................................................................171
5.5.3.4 Pull-up/Pull-down Resistors ............................................................................................................................171
5.5.3.5 CSTSCHG Support ................................................................................................................................................171
5.5.3.6 Power Consumption .............................................................................................................................................172
5.5.3.7 I/O Space Support .................................................................................................................................................172
5.5.4 Socket Requirements............................................................................................................................................................172
5.5.4.1 16-bit PC Card Support .......................................................................................................................................172
5.5.4.2 Address Spaces ......................................................................................................................................................173
5.5.4.2.1 Memory Space ..............................................................................................................................................173
5.5.4.2.2 I/O Support....................................................................................................................................................174
5.5.4.2.2.1 CardBus PC Card with Memory Mapped I/O....................................................................174
5.5.4.2.2.2 CardBus PC Card with I/O Space ............................................................................................174
5.5.4.2.2.3 ISA Support Implications.............................................................................................................175
5.5.4.3 Interrupt Handling and Routing......................................................................................................................175
5.5.4.3.1 Functional Interrupts (CINT#) ................................................................................................................175
5.5.4.3.2 Status Change Events .................................................................................................................................175
5.5.4.4 Register Descriptions ...........................................................................................................................................176
5.5.4.4.1 Socket EVENT Register.............................................................................................................................17 6
5.5.4.4.2 Socket MASK Register............................................................................................................................... 177
5.5.4.4.3 Socket PRESENT STATE Register ........................................................................................................178
5.5.4.4.4 FORCE Event Capability ..........................................................................................................................181
5.5.4.4.5 CONTROL Register ....................................................................................................................................183
5.5.4.5 VPP[2::1] Power Requirements ..........................................................................................................................183
5.5.4.6 Card Insertion and Removal.............................................................................................................................18 4
5.5.4.6.1 Card Insertion...............................................................................................................................................184
© 1999 PCMCIA/JEIDA ix
CONTENTS
5.5.4.6.2 Card Removal...............................................................................................................................................185

5.5.4.7 Power Cycling the Interface ............................................................................................................................... 186
5.5.4.7.1 Signal Requirements...................................................................................................................................186
5.5.4.7.2 CSTSCHG Requirements...........................................................................................................................186
5.5.4.7.3 In-Rush Current ............................................................................................................................................186
5.5.4.8 Required Pins ..........................................................................................................................................................187
5.5.4.9 Clock Stopping Support.......................................................................................................................................187
5.5.4.10 Special Cycle Support ........................................................................................................................................187
5.5.4.11 Actions When Adapter Is Reset......................................................................................................................187
6. PCI Bus Power Management Interface for CardBus Cards 189

6.1 Introduction.....................................................................................................................189
6.1.1 Goals of this Specification.................................................................................................................................................189
6.1.2 Target Audience....................................................................................................................................................................190
6.1.3 Overview/Scope ...................................................................................................................................................................190
6.1.4 Glossary of Terms................................................................................................................................................................192
6.1.5 Related Documents ..............................................................................................................................................................193
6.1.6 Conventions Used in this Chapter ..................................................................................................................................194
6.2 CardBus Power Management Overview.........................................................................194

6.2.1 CardBus Power Management States.............................................................................................................................19 4
6.2.1.1 CardBus Function Power States.......................................................................................................................195
6.2.1.2 Bus Power States....................................................................................................................................................195
6.2.1.3 Device-Class Specifications ............................................................................................................................... 195
6.2.1.4 Bus Support for CardBus Function Power Management........................................................................196
6.3 CardBus Power Management Interface ..........................................................................197

6.3.1 Capabilities List Data Structure .....................................................................................................................................198
6.3.1.1 Capabilities List Cap_Ptr Location................................................................................................................199
6.3.2 Power Management Register Block Definition .........................................................................................................200
6.3.2.1 Capability Identifier - Cap_ID (Offset = 0)...................................................................................................200
6.3.2.2 Next Item Pointer - Next_Item_Ptr (Offset = 1) ...........................................................................................201
6.3.2.3 PMC - Power Management Capabilities (Offset = 2)................................................................................201
6.3.2.4 PMCSR - Power Management Control/Status (Offset = 4) ....................................................................202
6.3.2.5 PMCSR_BSE - PMCSR PCI-to-PCI Bridge Support Extensions (Offset=6) Ð Not Used in
CardBus Cards - Reserved....................................................................................................................................204
6.3.2.6 Data (Offset = 7) .....................................................................................................................................................205
6.4 CardBus Bus Power States .............................................................................................207

6.4.1 CardBus B0 State - Fully On.............................................................................................................................................207
6.4.2 CardBus B1 State..................................................................................................................................................................208
6.4.3 CardBus B2 State..................................................................................................................................................................208
6.4.4 CardBus B3 State - Off........................................................................................................................................................208
6.4.5 CardBus Bus Power State Transitions .........................................................................................................................209
6.4.6 CardBus Clocking Considerations ................................................................................................................................209
6.4.7 Control/Status of CardBus Bus Power Management States................................................................................210
6.4.7.1 Control of Secondary Bus Power Source and Clock.................................................................................210
x ©1999 PCMCIA/JEIDA
6.5 CardBus Function Power Management States...............................................................211

6.5.1 CardBus Function D0 State...............................................................................................................................................211
6.5.4.1 Software Accessible D3 (D3hot).........................................................................................................................213
6.5.4.2 Power Off (D3cold)..................................................................................................................................................213
6.5.5 CardBus Function Power State Transitions ...............................................................................................................213
6.5.6 CardBus Card Function Power Management Policies ...........................................................................................215
6.5.6.1 State Transition Recovery Time Requirements ..........................................................................................219
6.6 CardBus Cards and Power Management.......................................................................219

6.6.1 CardBus Card Context .......................................................................................................................................................222
6.6.2 PME_En/PME_Status and CardBus Cards ..............................................................................................................223
6.7 Power Management Events.............................................................................................224

6.7.1 Auxiliary Power for D3cold Power Management Events .......................................................................................224
6.8 Software Support for PCI Power Management..............................................................225

6.8.1 Identifying CardBus Function Capabilities................................................................................................................225
6.8.2 Placing CardBus Functions in a Low Power State...................................................................................................226
6.8.2.1 Buses...........................................................................................................................................................................226
6.8.2.2 D3 State .....................................................................................................................................................................226
6.8.3 Restoring PCI Functions From a Low Power State ..................................................................................................226
6.8.3.1 Dx States and the DSI Bit....................................................................................................................................226
6.8.3.2 D1 and D2 States ...................................................................................................................................................226
6.8.3.3 D3 State .....................................................................................................................................................................226
6.8.4 Wake Events ...........................................................................................................................................................................227
6.8.4.1 Wake Event Support .............................................................................................................................................227
6.8.4.2 The D0 "Initialized" State From a Wake Event...........................................................................................227
6.8.5 Get Capabilities.....................................................................................................................................................................228
6.8.6 Set Power State ......................................................................................................................................................................228
6.8.7 Get Power Status...................................................................................................................................................................228
6.9 Other Considerations.......................................................................................................228
7. Special Cycle Messages________________________________229

7.1 Message Encodings..........................................................................................................229
7.2 Use of Specific Encodings ...............................................................................................229
8. CardBus PC Card Connector Test Methodology__________231

8.1 Background......................................................................................................................231
8.2 Test Hardware Recommendations..................................................................................231
8.2.1 General Recommendations...............................................................................................................................................231
8.2.2 Host-side Requirements .....................................................................................................................................................232
8.2.3 Card-side Recommendations ..........................................................................................................................................232
8.2.4 Measurement Equipment Recommendations ............................................................................................................232
© 1999 PCMCIA/JEIDA xi
CONTENTS
8.3 Test Board Considerations..............................................................................................232

8.3.1 Host-side Implementation.................................................................................................................................................233
8.3.2 Card-side Implementation................................................................................................................................................234
8.4 Measurement Methodology.............................................................................................235

8.4.1 Finding the Worst Case Ground Bounce......................................................................................................................235
9. PC Card Custom Interfaces ____________________________ 237

9.1 Custom Interface Requirements......................................................................................237
9.1.1 Purpose/Overview...............................................................................................................................................................237
9.1.2 Compatibility.........................................................................................................................................................................237
9.1.3 Pin Assignments....................................................................................................................................................................237
9.1.4 Features ....................................................................................................................................................................................237
9.1.5 Signal Description................................................................................................................................................................237
9.1.6 Functions..................................................................................................................................................................................238
9.1.7 Timing ......................................................................................................................................................................................238
9.1.8 Electrical Interface ...............................................................................................................................................................238
9.1.9 Specific Signals and Functions........................................................................................................................................238
9.2 ZV Port Custom Interface (0141H) .................................................................................239

9.2.1 Overview .................................................................................................................................................................................239
9.2.2 Compatibility.........................................................................................................................................................................239
9.2.3 Pin Assignments....................................................................................................................................................................241
9.2.4 Features ....................................................................................................................................................................................243
9.2.5.1 PCLK ..........................................................................................................................................................................243
9.2.5.2 VSYNC.......................................................................................................................................................................243
9.2.5.3 HREF ..........................................................................................................................................................................243
9.2.5.4 Y[7::0] .........................................................................................................................................................................243
9.2.5.5 UV[7::0] .....................................................................................................................................................................243
9.2.5.6 LRCLK.......................................................................................................................................................................243
9.2.5.7 SDATA ......................................................................................................................................................................244
9.2.5.8 SCLK ..........................................................................................................................................................................244
9.2.5.9 MCLK ........................................................................................................................................................................244
9.2.6 Functions..................................................................................................................................................................................245
9.2.7 Timing ......................................................................................................................................................................................245
9.2.7.1 Video Interface Timing .......................................................................................................................................245
9.2.7.2 Audio Interface Timing.......................................................................................................................................246
9.2.10 PC Card Connector Test Methodology ......................................................................................................................247
9.3 DVB CI Port Custom Interface (0241h) .........................................................................249

9.3.1 Overview .................................................................................................................................................................................249
9.3.2 Compatibility.........................................................................................................................................................................250
9.3.3 Pin Assignments....................................................................................................................................................................251
9.3.4 Features ....................................................................................................................................................................................252
xii ©1999 PCMCIA/JEIDA


9.3.5.1 MDI[7::0]...................................................................................................................................................................253
9.3.5.2 MISTRT.....................................................................................................................................................................253
9.3.5.3 MIVAL ......................................................................................................................................................................253
9.3.5.4 MDO[7::0].................................................................................................................................................................253
9.3.5.5 MOSTRT...................................................................................................................................................................253
9.3.5.6 MOVAL ....................................................................................................................................................................253
9.3.5.7 MCLKI.......................................................................................................................................................................253
9.3.5.8 MCLKO.....................................................................................................................................................................253
9.3.6 Functions..................................................................................................................................................................................254
9.3.7 Timing ......................................................................................................................................................................................254
© 1999 PCMCIA/JEIDA xiii

FIGURES
Figure 3Ð1 CCD[2::1]# and CVS[2::1] Connections.....................................................................10
Figure 5-1 CardBus PC Card Basic Read Operation ...................................................................83
Figure 5-2 CardBus PC Card Basic Write Operation...................................................................84
Figure 5-3 CardBus PC Card Master Initiated Termination........................................................85
Figure 5-4 CardBus PC Card Master-abort Termination.............................................................87
Figure 5-5 Target Initiated Termination .......................................................................................90
Figure 5-6 CardBus PC Card Basic Arbitration ...........................................................................92
Figure 5-7 Arbitration for Back-to-Back Access...........................................................................94
Figure 5-8 Components of Access Latency ..................................................................................95
Figure 5-9 CardBus PC Card Starting an Exclusive Access ......................................................100
Figure 5-10 CardBus PC Card Continuing an Exclusive Access...............................................101
Figure 5-11 CardBus PC Card Accessing a Locked Agent........................................................102
Figure 5-12 CDEVSEL# Assertion..............................................................................................103
Figure 5-13 Address Stepping ....................................................................................................106
Figure 5-14 Type 0 and Type 1 Configuration Accesses ...........................................................107
Figure 5-15 Layout of CONFIG_ADDRESS Register ................................................................108
Figure 5-16 Bridge Translation for Type 0 Configuration Cycles..............................................109
Figure 5-17 Parity Operation ......................................................................................................111
Figure 5-18 CardBus PC Card Clock Stop or Slow Down.........................................................117
Figure 5-19 CardBus PC Card Clock Start or Speed up............................................................118
Figure 5-20 Maintaining CardBus PC Card Clock.....................................................................119
Figure 5-21: CardBus PC Card Function Event Register ...........................................................122
Figure 5-22: Function Event Mask Register ................................................................................123
Figure 5-23: Function Present State Register ..............................................................................125
Figure 5-24: Function Force Event Register.................................................................................127
Figure 5-25 V/I Curves for 3.3 V Signaling................................................................................133
Figure 5-26 Test Waveform for 3.3 V Signaling (CCLK) ...........................................................134
Figure 5-27 CardBus PC Card Clock Waveform .......................................................................135
Figure 5-28 Output Timing Measurement Conditions ..............................................................137
Figure 5-29 Input Timing Measurement Conditions..................................................................137
Figure 5-30 Clock Skew Diagram ...............................................................................................139
Figure 5-31 Reset Timing.............................................................................................................140
© 1999 PCMCIA/JEIDA xv
FIGURES
Figure 5-32 Card with Memory and I/O Space in Host System with no Separate I/O Space149
Figure 5-33 Memory-only Card in Host System.........................................................................150
Figure 5-34 I/O Space-only Card in a Host System with a Separate I/O Space.....................151
Figure 5-35 Card and Host with All Spaces Described .............................................................152
Figure 5-36 CardBus PC Card Configuration Space .................................................................154
Figure 5-37 COMMAND Register Layout..................................................................................155
Figure 5-38: STATUS Register Layout .......................................................................................157
Figure 5-39 BIST Register............................................................................................................159
Figure 5-40 Base Address Register Mapping for Memory Space ..............................................160
Figure 5-41 Base Address Register Mapping for I/O Space .....................................................161
Figure 5-42 CIS POINTER Layout .............................................................................................161
Figure 5-43 Expansion ROM Base Address Register Layout ....................................................163
Figure 5-44 Socket EVENT Register............................................................................................176
Figure 5-45 Socket MASK Register .............................................................................................177
Figure 5-46 Socket PRESENT STATE Register...........................................................................179
Figure 5-47 Socket FORCE Register............................................................................................181
Figure 5-48 Socket CONTROL Register......................................................................................183
Figure 6-1: Operating System Directed Power Management System Architecture ..................191
Figure 6-2: Example "Originating Devices" ................................................................................192
Figure 6-3: Standard PCI Configuration Space Header Type 0 ................................................197
Figure 6-4: Capabilities Linked List............................................................................................199
Figure 6-5: Power Management Register Block ..........................................................................200
Figure 6-6: PCI Bus PM State Transitions ..................................................................................209
Figure 6-7: PCI Function Power Management State Transitions...............................................214
Figure 6-8: Non-Bridge CardBus Function Power Management Diagram................................216
Figure 6-9: CardBus Card Power Management Diagram..........................................................220
Figure 6-10: Vcc to VAUX Transitioning .......................................................................................225
Figure 8Ð1 Host-side Test Board Layout ...................................................................................233
Figure 8Ð2 Card-side Test Board Layout ...................................................................................234
Figure 9-1 Example ZV Port Implementation ............................................................................239
Figure 9-2 ZV Port Signals on PC Card Socket ..........................................................................242
Figure 9-3: 1A I2S Format - MCLK = 256fs................................................................................244
Figure 9-4: 1B I2S Format - MCLK = 384fs ................................................................................244
Figure 9-5 Video Interface Timing ..............................................................................................245
xvi ©1999 PCMCIA/JEIDA
Figure 9-6 Audio Interface Timing .............................................................................................246

Figure 9-7 Host-side Test Board Layout....................................................................................248
Figure 9-8: Example DVB CI Port Implementation ...................................................................249
Figure 9-9: Transport Stream Interface Chaining between Modules .........................................250
Figure 9-10: DVB CI Port Signals on PC Card Socket ...............................................................252
Figure 9-11: Transport Data Stream Interface Timing...............................................................255
© 1999 PCMCIA/JEIDA xvii

TABLES
Table 3Ð1 Card Detect and Voltage Sense Connections.................................................................8
Table 5Ð1 CardBus PC Card List of Signals ................................................................................68
Table 5Ð2 PC Card Pin 1 to Pin 34 Assignments.........................................................................70
Table 5Ð3 PC Card Pin 35 to Pin 68 Assignments.......................................................................71
Table 5Ð4 CardBus PC Card Commands ....................................................................................75
Table 5Ð5 Address Bus Encoding.................................................................................................80
Table 5Ð6 Common Access Field Definitions.............................................................................107
Table 5Ð7 DC Specification for 3.3 V Signaling..........................................................................131
Table 5Ð8 AC Specifications for 3.3 V Signaling ........................................................................132
Table 5Ð9 AC Specification for 3.3 V Signaling (CCLK)............................................................133
Table 5Ð10 CardBus PC Card Clock Specifications...................................................................135
Table 5Ð11 3.3 V Timing Parameters..........................................................................................136
Table 5Ð12 Measurement and Test Condition Parameters........................................................137
Table 5Ð13 Clock Skew Parameters............................................................................................138
Table 5Ð14 Minimum and Maximum Pull-up Resistor Values (3.3 V signaling).....................141
Table 5Ð15 Pull-up/Pull-down Resistor Requirements .............................................................143
Table 5Ð16 Pull-up/Pull-down Resistor Requirements .............................................................144
Table 5Ð17 COMMAND Register Field Definitions ...................................................................156
Table 5Ð18 STATUS Register Field Definition............................................................................158
Table 5Ð19 BIST Register Fields..................................................................................................159
Table 5Ð20 Meaning of the Type Fields for a Memory Base Address Register .........................160
Table 5Ð21 Address Space Indicator Values..............................................................................162
Table 5Ð22 Address Space Offset Values ..................................................................................162
Table 5Ð23 Configuration Space Register Usage Summary ......................................................165
Table 5Ð24 Expansion ROM Image Header ...............................................................................166
Table 5Ð25 CardBus PC Card Data Structure Fields ................................................................167
Table 5Ð26 Code Type Descriptions ...........................................................................................168
Table 5Ð27 Socket EVENT Register Fields..................................................................................177
Table 5Ð28 Socket MASK Register Fields ...................................................................................178
Table 5Ð29 Socket PRESENT STATE Register Fields.................................................................180
Table 5Ð30 Socket FORCE Register Fields..................................................................................182
Table 5Ð31 Socket CONTROL Register Fields............................................................................183
© 1999 PCMCIA/JEIDA xix
TABLES
Table 6-1: PCI Status Register ....................................................................................................198

Table 6-2: Capabilities Pointer - Cap_Ptr...................................................................................198
Table 6-3: PCI Configuration Space Header Type / Cap_Ptr mappings.................................199
Table 6-4: Capability Identifier - Cap_ID ..................................................................................200
Table 6-5: Next Item Pointer - Next_Item_Ptr...........................................................................201
Table 6-6: Power Management Capabilities Ð PMC for CardBus Cards ..................................202
Table 6-7: Power Management Control/Status - PMCSR .........................................................204
Table 6-8: PMCSR Bridge Support Extensions - PMCSR_BSE..................................................205
Table 6-9: Data Register..............................................................................................................205
Table 6-10: Power Consumption/Dissipation Reporting..........................................................206
Table 6-11: CardBus Bus Power Management States................................................................207
Table 6-12: PCI Bus Power and Clock Control ..........................................................................210
Table 6-13: State Diagram Summary.........................................................................................215
Table 6-14: D0 CardBus Card Power Management Policies .....................................................217
Table 6-17: D3hot CardBus Card Power Management Policies..................................................218
Table 6-18: D3cold CardBus Card Power Management Policies.................................................218
Table 6-19: CardBus Function State Transition Delays.............................................................219
Table 6-20: CardBus Card Power Management Policies ...........................................................221
Table 6-21: PME_En / PME_Status Summary in a CardBus Card..........................................223
Table 9-1 ZV Port Interface Pin Assignments ............................................................................241
Table 9-2 AC Parameters for Video Signals ...............................................................................246
Table 9-3 AC Parameters for Audio Signals..............................................................................246
Table 9-4 ZV Port Electrical Interface.........................................................................................247
Table 9-5: DVB CI Port Interface Pin Assignments ...................................................................251
Table 9-6: Timing Relationship Limits........................................................................................255
xx ©1999 PCMCIA/JEIDA
1. O V E R V IE W
The Electrical Specification describes the connector pinout, interface protocol, signaling
environment, interface timings, programming model, and specifics of card insertion, removal,
power up, and configuration. It is organized in three sub-sections dealing with items common to all
interfaces, 16Ðbit PC Card interface specifics, and CardBus PC Card interface specifics.
The PC Card Standard continues an evolutionary process by providing additional capabilities
thereby expanding the variety of PC Cards that can be supported. This release enables many types
of PC Cards ranging from 16Ðbit slave cards to 32Ðbit bus master cards, including multiple points in
between such as 16Ðbit slave DMA and 32Ðbit slave cards. These capabilities provide higher
performance levels than previously available as well as new features such as card-to-card transfers
without intervention by the host CPU.
As a result, the spectrum of applications which can be supported by PC Cards has again been
broadened. Just as PCMCIA 2.0 / JEIDA 4.1 evolved the PCMCIA 1.0 / JEIDA 4.0 memory only
interface by adding I/O capability, this new release evolves to include the capabilities outlined
below.
The capabilities of 16Ðbit PC Cards have been expanded and now provide:
• 16 bit data / 26 bit addressing.
• 20 MBytes/sec peak bandwidth at 100 ns cycle rate.
• support of 8Ðbit and 16Ðbit Slave DMA.
• compatibility with PCMCIA 2.1 / JEIDA 4.2 and earlier releases and CardBus PC Card Sockets.
• hardware detection of card voltage requirements (5 V, 3.3 V, X.X1 V).
• operation at 5 V, 3.3 V and X.X V voltage levels.
• support of multiple function cards.
• a Card Information Structure (CIS) with expanded capabilities to identify functions and data
formats. (See the Metaformat Specification.)
• a specification for current draw and time to READY.
There is an emerging class of applications which require higher performance - either 32Ðbit
bandwidth, reduced latency via bus master capability, or both. However, there still exists a class of
applications which remain better suited for the 16Ðbit environment because it already offers
sufficient performance. This new release of the PC Card Standard has resolved this dilemma by
developing the CardBus PC Card interface which enables these new functions and still accepts
cards developed to the 16Ðbit PC Card interface.
The CardBus PC Cards provide:
• 32Ðbit multiplexed address/data with parity.
• 132 MBytes/sec peak bandwidth at 33 MHz clock frequency.
• support for Bus Masters on PC Cards.
• synchronous interface.
• 3.3 V and lower voltage operation.
1 X.X V is less than 3.3 V
© 1999 PCMCIA/JEIDA 1
OVERVIEW
• support for remote system and/or interface wake up even when the interface is powered down.
• interface power management.
• compatibility with existing (PCMCIA 2.x/JEIDA 4.x) and new 16-bit PC Cards.
• the same PC Card mechanical form factors defined for all PC Cards.
• an enhanced 68-pin connector which provides improved signal grounding/noise reduction -- in
addition to CardBus PC Cards, the socket connector accepts all 16Ðbit PC Cards.
• ability to mix CardBus PC Cards and 16Ðbit PC Cards in sockets controlled by the same
CardBus PC Card adapter.
• hardware detection of the card type installed (CardBus PC Card vs. 16Ðbit PC Card).
• hardware detection of card voltage requirements (5 V, 3.3 V, X.X V2, Y.Y V3)
1.1 Summary of Electrical Specification Changes
1.1.1 PCMCIA 2.0/JEIDA 4.1 (September 1991)

• added the I/O and Memory interface.
• defined the RESET signal.
• defined the WAIT# signal.
1.1.2 PCMCIA 2.1/JEIDA 4.2 (July 1993)

The electrical section of the PCMCIA 2.1/JEIDA 4.2 release provided corrections to PCMCIA
2.0/JEIDA 4.1.
1.1.3 PC Card Standard February 1995 Release (Release 5.0)

• added the CardBus PC Card interface.
• changed the signal naming convention to denote an active-low signal with a Ò#Ó, (-REG is now
REG#).
• renamed the RDY/-BSY signal READY (with no change in function).
• redefined RFSH as voltage sense one (VS1#).
• defined the only RFU pin in the I/O and Memory interface as voltage sense two (VS2#).
• changed the I/O read (input) timing Ñ data delay from WAIT# rising, td(WT), from 35 ns to 0
ns.
• defined DMA transfer cycles and use of signals for cards and sockets capable of DMA
operations.
• defined multiple voltage operation with initial operation at voltages other than 5 V.
• defined Multiple Function 16-bit PC Cards Ñ more than one set of configuration registers.
• defined the signal OFF states (use of pull-ups and switched VCC).
2 X.X V is less than 3.3 V

3 Y.Y V is less than X.X V
2 ©1999 PCMCIA/JEIDA
• specified the Card Configuration Register initialization sequence.
1.1.4 PC Card Standard March 1995 Update (Release 5.01)

• general editorial corrections
1.1.5 PC Card Standard May 1995 Update (Release 5.02)

• clarification of Power Waveforms at Power-on
1.1.6 PC Card Standard November 1995 Update (Release 5.1)

• addition of Custom Interfaces for PC Cards
• addition of Indirect CIS Addressing for PC Cards
• clarifications for Multifunction PC Cards
1.1.7 PC Card Standard May 1996 Update (Release 5.2)

• addition of the Zoomed Video (ZV) Port PC Card Custom Interface
1.1.8 PC Card Standard 6.0 Release (March 1997)

• addition of the Thermal Ratings system for PC Cards
1.1.9 PC Card Standard 6.1 Release (April 1998)

• The addition of the Small PC Card form factor, which adheres to the PC Card Standard
Electrical Specification except that the CardBus interface is not supported.
• addition of a Power Management interface for CardBus cards
1.1.10 PC Card Standard 7.0 Release (February 1999)

• addition of the Digital Video Broadcasting (DVB) Port PC Card Custom Interface
• addition of the PC Card Memory Paging mechanism to extend the size of PC Card common
memory space beyond 64 Mbytes
• corrections to the Power Management interface for CardBus cards
1.2 Conventions
This section is intended to give general descriptions of notation conventions used in this document.
(See also the Overview and Glossary.)
1.2.1 Signal Naming

All signals are named with respect to their asserted state as follows:
a) Each signal which is not a logic signal, such as VCC, has a name which does not end with a "#"
character.
OVERVIEW
b) Each logic signal whose name does not end with a "#" character has logic high as the asserted
state and logic low as the negated state.
c) Each logic signal whose name ends with a "#" character has logic low as the asserted state and
logic high as the negated state.
1.2.2 Numeric Representation

Numbers are expressed as follows:
a) Individual bits are expressed as "0" for zero, "1" for one, or "X" for "any value".
b) Groups of bits (fields) are expressed in hexadecimal number which begin with one or more
digits and are followed by an "H". Each digit represents 4 bits and is indicted by the characters
"0" through "9" and "A" through "F" giving each digit a value of 0 to 15 (decimal). An "X" is
used to indicate a digit of "any value". The number of bits in the field determines how many
bits in the hexadecimal number are significant.
1.2.3 Bit Action Representation

Bits of a register are said to be set when they are made equal to "1" and to be reset when they are
made equal to "0" .
1.2.4 Signal Summary

Signal Types:
in Input is a standard input-only signal.
out Totem Pole Output is a standard active driver.
i/o Input/Output is a bi-directional signal.
h/z High-Z is an output or I/O pin driver which is in the high impedance state when it is disabled.
s/h/z Sustained High-Z is an active low High-Z signal owned and driven by one and only one agent at a time.
The agent that drives an s/h/z pin low must drive it high for at least one clock before letting it float. A new
agent cannot start driving a s/h/z signal any sooner than one clock after the previous owner places it in a
High-Z state. A pull-up is required to sustain the inactive state until another agent drives it, and must be
provided by the central resource.
o/d Open Drain allows multiple devices to share a signal as a wire-OR.
DC DC refers to power or ground pins which are not used for any information transfer.
2. COMMON PIN DE S C R IP T ION

A number of pins have the same function for all three interfaces specified in this release: VCC,
VPP[2::1], and GND. Several other pins are used for the same purpose in all three interfaces and
have similar function in terms of providing information about card presence, card type, and VCC
requirements. Signals whose function is specific to an interface are described in their respective
sections.
2.1 Power and Ground Pins

Power and ground for all PC Card interfaces must be provided by the host system. PC Cards may
not apply any voltage to VCC, VPP[2::1], or GND. Refer to the Metaformat Specification for
information on describing the cardÕs VCC and VPP[2::1] requirements in the Card Information
Structure.
2.1.1 VCC and GND Pins

The two 16Ðbit PC Card interfaces support 5 V, 3.3 V and X.X V VCC voltages while the CardBus
PC Card interface supports 3.3 V, X.X V and Y.Y V VCC voltages. Deciding whether the socket
hardware must support 5 V is a function of the interfaces being supported, the availability of 5 V in
the system, and which cards need to be enabled. Sockets are not required to support 5V VCC
operation. The connector places the two VCC pins (17 and 51) and four GND pins (1, 34, 35 and 68)
at symmetrical positions on the connector.
The voltage level on VCC cannot be changed until the Card Information Structure (CIS) of the card
has been read and other permissible values have been determined. If the CIS indicates the card
could be operated at a different voltage level, the host can change to the new voltage level.
To change VCC, the host shall direct the socket to discharge the PC Card connectorÕs VCC and
VPP[2::1] to ground, then power-up the card at the new voltage. Further, care should be taken
when dynamically changing the voltage applied to VCC or VPP[2::1] so that power supply shorts do
not occur. The host must recognize that the card will retain no knowledge of the power-up at the
previous VCC and all configuration and other initialization must be done following the second
power-up. If any Card Detect pin is negated at any time, the host system must recognize that the
card may have been replaced and repeat the entire power-up sequence.
2.1.2 VPP1 and VPP2 Pins

The VPP[2::1] (pins 18 and 52) supply signals are used optionally on the card for PC Card operation.
VPP[2::1] must be initially powered up at the voltage indicated by the voltage sense pins which
means systems are required to be able to supply the VCC level on the VPP[2::1] pins. The voltage
level on VPP[2::1] cannot be changed until the Card Information Structure (CIS) of the card has been
read and other permissible values have been determined. The voltage applied to the VPP[2::1] pins
of a card must never be greater than the VPP[2::1] level appropriate for the card. If the appropriate
VPP[2::1] voltage for a card cannot be determined, the voltage applied to the VPP[2::1] pins must not
exceed VCC.
Regardless of how PC Cards use VPP[2::1], the respective planes on the card must never be shorted
together or shorted to VCC. The host is not required to account for shorted power planes in the
design of its power supplies or power delivery schemes.
COMMON PIN DESCRIPTION
When the VPP[2::1] value required by a card is unavailable in a system, the system may reject the
card.
2.2 Interface Configuration Pins

The Card Detect pins, CD[2::1]# or CCD[2::1]# and Voltage Sense pins, VS[2::1]# or CVS[2::1] are
used by the host system to establish the presence/absence of a PC Card in a socket and the voltage
requirements of the card. For CardBus PC Cards, these pins are also used to distinguish between
16Ðbit PC Card and CardBus PC Cards. Careful attention should be given to the following
discussions since subtle, but very important, differences in the usage of these pins exist between the
16Ðbit PC Card and CardBus PC Card interfaces.
2.2.1 Card Detect Pins (CD[2::1]# and CCD[2::1]#)

The Card Detect pins provide a means for sockets to detect PC Card insertion and removal events.
These pins are at opposite ends of the connector to ensure a valid insertion (i.e. guarantees both
sides of the card are firmly seated).
From the socketÕs perspective, the Card Detect pins function the same for all three interfaces (16-bit
PC Card Memory-only, 16-bit PC Card I/O and Memory, and CardBus PC Card) - they are inputs
pulled high through a resistor. The host socket interface circuitry shall provide a 10 K Ω or larger
pull-up resistor to VCC on each of these signal pins. Host sockets shall only report valid insertions
when both Card Detect pins are detected low (CD[2::1]# or CCD[2::1]#). Failure to do so may cause
electrical damage to PC Cards.
Cards implementing the 16Ðbit PC Card interface must connect CD1# and CD2# to ground
internally on the PC Card causing the socketÕs inputs to be pulled low whenever a card is inserted.
CardBus PC Cards also cause the socketÕs CCD[2::1]# inputs to be pulled low upon insertion. (See
3.4 Determining Card Type in CardBus PC Card Capable Sockets.) However, CardBus PC Cards also
use the CCD[2::1]# pins in conjunction with CVS[2::1] to encode card type information. (See also
Figure 3Ð1 CCD[2::1]# and CVS[2::1] Connections.)
2.2.2 Voltage Sense Pins (VS[2::1]# and CVS[2::1])

The Voltage Sense signals notify the socket of the cardÕs VCC requirements for initial power up and
configuration. (See also 3.3 Graceful Rejection in 16-bit PC Card Only Sockets.) CardBus PC Cards
also use the CVS[2::1] pins in conjunction with CCD[2::1]# to encode card type information. (See also
3.4 Determining Card Type in CardBus PC Card Capable Sockets.)
3 . CAR D T YP E DE T E C T ION M E C H AN IS M
The card interface (16Ðbit PC Card vs. CardBus PC Card) must be detected before the socket notifies
Card Services of an insertion event. To initially power up a PC Card and determine its
characteristics, VCC and VPP[2::1] must be at a voltage indicated by the Voltage Sense pins. This
section describes how sockets determine the card interface and initial voltage requirements.
If the Card Information Structure (CIS) indicates that the card can operate at voltages other than the
voltage at which it was initially powered up, the host system may change the card's VCC, and
VPP[2::1] accordingly.
3.1 PC Card Encodings

This specification provides the ability to support VCC values of 5 V, 3.3 V, X.X V (where X.X V < 3.3
V), Y.Y V (where Y.Y V < X.X V), and various combinations of each. PC Cards must indicate the
voltage(s) at which their CIS can be read by connecting the Card Detect and Voltage Sense pins.
(See 2. Common Pin Description.) The CIS on a card shall be capable of being read at the VCC level
indicated by the Voltage Sense pins. Any voltage combinations not listed in Table 3Ð1 are not
supported (i.e., the 16Ðbit PC Card interface does not support Y.Y V operation and the CardBus PC
Card interface does not support 5 V CardBus PC Card operation; a CardBus PC Card socket may
support 5 V 16-bit PC Card operation..)
PC Cards must implement one of two physical keys shown, 5 V or Low Voltage (LV) key. (See the
Physical Specification.) Any card capable of having its CIS read at 5 V shall be keyed with the 5 V
key. Any card not capable of having its CIS read at 5 V shall be keyed with the LV key.
CARD TYPE DETECTION MECHANISM
Table 3Ð1 Card Detect and Voltage Sense Connections

CD2#/CCD2# CD1#/CCD1# VS2#/CVS2 VS1#/CVS1 Card Type
(pin 67) (pin 36) (pin 57) (pin 43) Key Interface Voltage
ground ground open open 5V 16Ðbit PC Card 5V
ground ground open ground 5V 16Ðbit PC Card 5 V and 3.3 V
ground ground ground ground 5V 16Ðbit PC Card 5 V, 3.3 V and
X.X V
ground ground open ground LV 16Ðbit PC Card 3.3 V

ground connect to CVS1 open connect to CCD1# LV CardBus PC Card 3.3 V
ground ground ground ground LV 16Ðbit PC Card 3.3 V and
X.X V
connect to CVS2 ground connect to CCD2# ground LV CardBus PC Card 3.3 V and
X.X V
connect to CVS1 ground ground connect to CCD2# LV CardBus PC Card 3.3 V, X.X V
and Y.Y V
ground ground ground open LV 16Ðbit PC Card X.X V

connect to CVS2 ground connect to CCD2# open LV CardBus PC Card X.X V
ground connect to CVS2 connect to CCD1# open LV CardBus PC Card X.X V and
Y.Y V
connect to CVS1 ground open connect to CCD2# LV CardBus PC Card Y.Y V
ground connect to CVS1 ground connect to CCD1# reserved

ground connect to CVS2 connect to CCD1# ground reserved
3.2 Socket Key Selection

A 5 V only socket shall be keyed with the 5 V key which allows only cards with the 5 V key to be
inserted. Such a socket shall always apply initial VCC at 5 V and need not sense the VS[2::1]#
signals. Note that this type of socket is restricted to the 16Ðbit PC Card interface since 5 V only
CardBus PC Cards are not supported.
Sockets which provide 3.3 V or lower voltage VCC levels must implement the Low Voltage (LV)
socket. (See the Physical Specification.) This key allows the insertion of both 5 V keyed and Low
Voltage keyed cards. A socket capable of accepting a card with a Low Voltage key must implement
cold insertion (i.e., ensure that VCC and VPP[2::1] are removed from the socket and signals are
placed in the High-Z state, without software intervention, before the next PC Card is inserted). Low
voltage sockets must only treat the Voltage Sense pins as valid when both Card Detect pins are
asserted low. Failure to require both Card Detect pins to be low may result in falsely decoding a
cardÕs VCC requirements.
If the Voltage Sense pins indicate a VCC value the socket is capable of providing, the socket shall
allow the application of that VCC level to the card. If Voltage Sense pins indicate values of VCC the
socket is not capable of providing, the card inputs shall not be driven, the card shall not be
powered, and the user may be notified.
3.3 Graceful Rejection in 16Ðbit PC Card Only Sockets

Sockets which do not support the CardBus PC Card interface must tie their VS1# and VS2# inputs
high through a pull-up resistor. These sockets may assume that all valid insertions (i.e., both Card
Detect pins low) are 16Ðbit PC Card interface cards and ignore the interrogation protocol required
for the CardBus PC Card interface. This is because a CardBus PC Card always ties one Card Detect
pin to a Voltage Sense pin instead of to ground causing it to only pull one of the Card Detect inputs
low. If a 16Ðbit PC Card only socket senses only one Card Detect input low, the user may be
notified that one of the following conditions exists:
1. A card has not been inserted correctly or completely, or
2. The card inserted is of a type not supported by this socket (i.e., CardBus PC Card).
3.4 Determining Card Type in CardBus PC Card Capable

Sockets
Since a valid CardBus PC Card insertion (i.e., CCD[2::1]# pins are sampled low at the same time
after having been debounced) can only be detected when both CVS[2::1] pins are low, sockets must
always drive their CVS[2::1] outputs low when PC Card removal occurs.
Once a valid insertion is detected and before power is applied, the socket must interrogate the PC
Card to determine if it is a CardBus PC Card or 16Ðbit PC Card. This interrogation consists of
determining which CCD[2::1]# and CVS[2::1] pins are shorted to ground or each other and which
are not connected by alternately driving each CVS[2::1] output high and monitoring what happens
to the CCD[2::1]# and CVS[2::1] inputs. At the completion of this interrogation, the socket must
again drive the CVS[2::1] pins low. This means the socket must drive the CVS[2::1] pins low at all
times except when determining the card type and VCC requirements.
An example of how the socketÕs state machine, CCD[2::1]# and CVS[2::1] pins, and the connector
might be connected is provided. (See Figure 3Ð1 CCD[2::1]# and CVS[2::1] Connections.) Note that
the CVS[2::1] resistors could be integrated into their drivers so that each only consumes a single pin
on the socket controller.
RCD
CCD1#
RVS
CVS1 CVS1_DRV
SOCKET
STATE
MACHINE
CVS2 RVS
CVS2_DRV
PC CARD SIDE
RCD
CCD2#
CONNECTOR
DEBOUNCE
Figure 3Ð1 CCD[2::1]# and CVS[2::1] Connections

A series of steps is required to identify and configure a card upon insertion into a CardBus PC Card
capable socket. (See 5.5.4.6.1 Card Insertion.)
CARD TYPE DETECTION MECHANISM
4 . 1 6 - B IT PC CAR D EL E C T R IC AL I N T E R F AC E
4.1 Compatibility Issues
4.1.1 RESET and WAIT# Support

The PCMCIA 1.0 / JEIDA 4.0 Standard defined the Memory Only interface without the Card Reset
(RESET) input and Extended Bus Cycle (WAIT#) output signals. Host systems built to the PCMCIA
1.0 / JEIDA 4.0 interface have the RESET and WAIT# pins as no connects. When a PCMCIA 2.0 /
JEIDA 4.1 Memory Card is inserted into the socket of a PCMCIA 1.0 / JEIDA 4.0 host system, the
RESET signal will appear asserted continuously. In order to be backward compatible a PCMCIA 2.1
/ JEIDA 4.2 Memory Card inserted into the socket of a PCMCIA 1.0 / JEIDA 4.0 host system must
appear to the host system on Power-on, after the 20 ms VCC settling time, as a PCMCIA 1.0 / JEIDA
4.0 compliant card in its initial default power-on state.
PC Cards which are not intended for operation in PCMCIA 1.0 / JEIDA 4.0 host system sockets (e.g.
I/O cards or mixed I/O and Memory cards) need not present a valid CIS while RESET is asserted,
and shall not reply to read commands or act on write commands while RESET is asserted.
PCMCIA 2.0 / JEIDA 4.1 and later host system sockets, upon recognizing a PCMCIA 2.0 / JEIDA
4.1 or later PC Card, can subsequently take advantage of the RESET and WAIT# signals employed
on the card.
4.1.2 VS1# replaces RFSH (pin 43)

PCMCIA 2.1 / JEIDA 4.1 and earlier releases of the Standard named pin 43 RFSH. This pin is now
redefined as VS1#.
Note: Any PC Card that implemented the previously incompletely defined function on pin 43 (as an
input) may now be inserted into a socket that implements VS1#, which may falsely detect the
power-up voltage. Powering up such cards to the proper voltage is not defined by this Standard.
4.2 Pin Assignments

For 16-bit PC Card interface sockets, CE[2::1]#, VPP[2::1], WP, CD[2::1]#, WAIT#, VS[2::1]#, and
BVD[2::1] shall not be connected between PC Cards. These signals that are outputs from the card
must not be directly connected to any other signal source within the host. Further, card outputs
must not be wire-ORÕd or wire-ANDÕd with any host signals. Sockets supporting both 16-bit PC
Card and CardBus PC Card interfaces shall further observe CardBus PC Card constraints. (See 5.1.1
Pin Assignments and also 5.3 CardBus PC Card Electrical Specification.)
The READY signal shall not be connected between cards when the 16-bit PC Card interface socket
supports both I/O and Memory interfaces. READY shall not be wire-ORÕd or wire-ANDÕd with any
host signals.
In systems which switch VCC individually to cards, no signal shall be directly connected between
cards other than ground.
16-BIT PC CARD ELECTRICAL INTERFACE
Table 4Ð1 16-bit PC Card Pin 1 To Pin 34 Assignments

Memory Only Card Interface I/O and Memory Card Interface
(Always available at card insertion) (Available only after card and socket are configured)
Pin Signal I/O 2 Function Pin Signal I/O 2 Function
1 GND DC Ground 1 GND DC Ground
2 D3 I/O Data bit 3 2 D3 I/O Data bit 3
7 CE1# I Card Enable 7 CE1# I Card Enable
8 A10 I Address bit 10 8 A10 I Address bit 10
9 OE# I Output Enable 9 OE# I Output Enable
15 WE# I Write Enable 15 WE# I Write Enable
1 1
16 READY O Ready 16 IREQ# O Interrupt Request
17 VCC DC in Supply Voltage 17 VCC DC in Supply Voltage
1 1
18 VPP1 DC in Programming Supply 18 VPP1 DC in Programming and
Voltage 1 Peripheral Supply 1
33 1 WP O Write Protect 33 1 IOIS16# O I/O Port Is 16-bit
1. Use of pin changes between the Memory Only and the I/O and Memory interface.
2. "I" indicates signal is input to PC Card, "O" indicates signal is output from PC Card.
Table 4Ð2 16-bit PC Card Pin 35 To Pin 68 Assignments

Memory Only Card Interface I/O and Memory Card Interface
(Always available at card insertion) (Available only after card and socket are configured)
Pin Signal I/O 2 Function Pin Signal I/O 2 Function
36 CD1# O Card Detect 36 CD1# O Card Detect
42 CE2# I Card Enable 42 CE2# I Card Enable
43 4 VS1# O Voltage Sense 1 43 4 VS1# O Voltage Sense 1
1 1
44 RFU Reserved 44 IORD# I I/O Read
45 1 RFU Reserved 45 1 IOWR# I I/O Write
51 VCC DC in Supply Voltage 51 VCC DC in Supply Voltage
1 1
52 VPP2 DC in Programming Supply 52 VPP2 DC in Programming and
Voltage 2 Peripheral Supply 2
575 VS2# O Voltage Sense 2 57 VS2# O Voltage Sense 2
3
58 RESET I Card Reset 58 RESET I Card Reset
59 3 WAIT# O Extend bus cycle 59 WAIT# O Extend bus cycle
1 1
60 RFU Reserved 60 INPACK# O Input Port Acknowledge
61 1 REG# I Register select 61 1 REG# I Register select & I/O
Enable
62 1 BVD2 O Battery Voltage Detect 2 62 1 SPKR# O Audio Digital Waveform
1 1
63 BVD1 O Battery Voltage Detect 1 63 STSCHG# O Card Status Changed
67 CD2# O Card Detect 67 CD2# O Card Detect
1. Use of pin changes between the Memory Only and the I/O and Memory interface.
2. ÒIÓ indicates signal is input to PC Card, ÒOÓ indicates signal is output from PC Card.
3. RESET and WAIT# are RFU in PCMCIA 1.0 / JEIDA 4.0 version of the Standard. These signals are
required in PCMCIA 2.0 / JEIDA 4.1 and all later versions of the Standard.
4. VS1# was named RFSH in PCMCIA 2.1 / JEIDA 4.2 and earlier versions of the Standard.
5. VS2# was RFU in PCMCIA 2.1 / JEIDA 4.2 and earlier versions of the Standard.
4.3 16-bit PC Card Features

Table 4Ð3 Features of 16-bit PC Card Asynchronous Interface
Item Feature
Access Random access
Data Bus Bus 16 bits/8 bits
Memory Types MaskROM, OTPROM, EPROM, EEPROM, Flash-Memory, SRAM
Memory Capacity1 Without Address Extension Registers: 64 MBytes A[25::0] maximum
With 8-bit Address Extension Registers: 234 bytes with 1 Address Extension Register, 233
bytes with 2 Address Extension Registers, 232 bytes with 4 Address Extension Registers;
With 16-bit Address Extension Registers: 242 bytes with 1 Address Extension Register, 241
bytes with 2 Address Extension Registers and 240 bytes with 4 Address Extension Registers;
With the ÒCommon Memory Address ExtensionÓ field of the Configuration Option Register: 232
bytes
REG# function Attribute Memory for storing card identification

I/O Address Space 64 MBytes A[25::0] maximum (64 KBytes for PC compatible architectures)
I/O Space Decoding Overlapping I/O Address Window: card performs partial selection decoding
Independent I/O Address Window: system performs entire selection decoding
I/O Interrupts One Interrupt Request signal per card. Routed to specific interrupt level by the host system
1. Even though the Address Extension Registers provide for addressing beyond 4 Gbytes of Common
Memory, the Card Services Specification as of the PC Card Standard Release 6.1 supports a maximum
Common Memory size of 4 Gbytes.
4.3.1 Memory Address Space

A Common Memory space as large as 242 bytes can be supported by a PC Card. The exact size of
the memory space depends on the number of registers on the card which support address
extension. A separate memory address space is permitted for each memory card installed in a
system.
When the card neither contains an Address Extension Register nor uses the Configuration Option
Register (COR) for address extension, the cardÕs memory size is limited to 64 Mbytes (using
signals A[25::0]).
With a memory paging architecture based on one or more registers providing an address
extension, the card can support more than 64 Mbytes of memory. When a single 8-bit Address
Extension Register is present on the card, 234 bytes of Common Memory can be addressed. With
two and four 8-bit Address Extension Registers present on the card, the system can address 233
and 232 bytes, respectively, of Common Memory. When a single 16-bit Address Extension
Register is present on the card, 242 bytes of Common Memory can be addressed. With two and
four 16-bit Address Extension Registers present on the card, the system can address 241 and 240
bytes, respectively, of Common Memory. The COR can be used to address up to 232 Common
Memory bytes.
The Common Memory may be accessed by a host system for memory read and write operations.
A host Direct-Memory Access controller may access data using Common Memory read or write
cycles when Common Memory is mapped into the host Direct-Memory Access controllerÕs address
space.
There is an additional 64 MB address space for Attribute Memory which is selected by the REG#
signal at the interface. This memory space is inappropriate for DMA operations because only
even-byte addresses are populated.
The Attribute Memory space may be divided into areas for:
1. Card Information Structure Ñ a description of the card's capabilities and specifications and
(optionally) its use. (See also the Metaformat Specification.)
2. Configuration Registers Ñ an optional set of registers which allow the card to be configured
by the system.
3. Reserved Area Ñ the portion of the Attribute Memory space which has not yet been
specified.
The size of each of these areas is determined by the card vendor. The Card Information Structure
must begin at address 0 but need not be a single, contiguous region. It is recommended that the
Card Information Structure and the Function Configuration registers be located at relatively low
addresses to ensure their accessibility by all hosts.
4.3.2 Memory Only Interface

The Memory Only interface supports memory cards, but does not include signals which support
I/O Cards. The signals READY, WP, and BVD[2::1] are present on the Memory Only interface
but replaced by other signals when the I/O interface is selected. PC Cards and systems which are
designed to the PCMCIA 1.0 / JEIDA 4.0 version of the Standard do not support the RESET or
WAIT# signals.
The Memory Only interface is the default selected in both the socket and the card whenever a
card is inserted into a socket, and immediately following the application of VCC or the RESET
signal to a card. This interface is required in all PCMCIA 2.0 / JEIDA 4.0 release or later compliant
systems.
After a PC Card's Card Information Structure has been interpreted, the card and the socket may
be configured, if appropriate, to use the I/O interface. (See 4.3.4 I/O Interface.)
4.3.3 I/O Address Space

The hardware interface supports a single I/O address space of 64 MB (signals A[25::0]) for
peripheral device access. The I/O address space is shared and divided among all the cards installed
in the system. However, many system architectures (such as the x86 architectures found in many
Personal Computers) support only a 64 KByte I/O address space.
I/O registers (ports) may be 8 or 16 bits wide. An IOIS16# signal is activated by each I/O card
when the address at the interface corresponds to a 16-bit I/O register. This permits hardware in a
system to adjust the access width (8 or 16 bits) to match the size of I/O port being addressed. When
a 16-bit operation is attempted to an 8-bit I/O port, the system hardware may divide the operation
into two consecutive 8-bit operations as is done in Personal Computer systems (PCÕs) that support
the ISA bus structure.
Peripheral cards may be designed such that the host system alone determines when the card is
selected. Alternatively, both the host and card may play a role in determining when the latter is
selected. The card includes information in the Card Information Structure which tells the host the
address decoding the card may be configured to perform. The host then programs the card to
perform a particular decoding using the card's Configuration registers.
To ensure compatibility in peripheral cards which completely emulate existing fixed address
peripherals, the cards may decode a portion of the address space. For example, a card might decode
only A[9::0] and respond only when a range of addresses corresponding to the peripheral's registers
are selected. Correspondingly, the system could decode address lines A[9::8] and simultaneously
select all the appropriately configured peripheral cards only when A[9::8] is asserted. A peripheral
card drives the Input Port Acknowledge signal (INPACK#) low when an input port on the card is
being accessed. This allows any data buffers in the host between the card and the host's internal bus
to be activated during the access.
Peripheral cards must be configured by the system before their I/O address space becomes
accessible. It is recommended that new devices which do not require software compatibility with
existing drivers decode only enough address lines to address the number of I/O ports
implemented. Furthermore, they should allow the system to locate them arbitrarily in the I/O
address space, thereby eliminating conflicts with other I/O devices.
4.3.4 I/O Interface

The I/O interface requires that the Memory Only interface also be implemented within the same
socket, and that the Memory Only interface be selected in the socket when no card is inserted and
immediately following card reset and the application of VCC to the card. The I/O interface contains
all the signals in the Memory Only interface with the exception of the READY, WP, and BVD[2::1]
signals.
The I/O interface also supports the following additional signals, some of which replace Memory
Only signals not supported by the I/O interface: Interrupt Request (IREQ#), I/O Port is 16 bits
(IOIS16#), I/O Read strobe (IORD#), I/O Write strobe (IOWR#), Input Port Acknowledge
(INPACK#), audio digital wave form intended for a speaker (SPKR#), and a card Status Changed
(STSCHG#) signal.
The Extend Bus Cycle (WAIT#) and Card Reset (RESET) signals, which are not required in a
PCMCIA 1.0 / JEIDA 4.0 release Memory Only interface, are required for both the Memory Only
and the I/O and Memory interfaces in all systems supporting the PCMCIA 2.0 / JEIDA 4.1 release
or later, including this version of the PC Card Standard.
Peripheral cards must be configured by the system before their I/O interface becomes active. Before
configuring a card, the system must examine the card's Card Information Structure to determine the
I/O address space, interrupt request, and other requirements of the possible card configurations.
The system uses this information to select the best configuration from those available in the card, as
determined by the system's hardware and software capabilities, as well as the requirements of other
cards installed concurrently. If no card configuration is suitable for the system, because the card
requires resources which are not available in the system, or which have already been assigned by
the system to other cards, the system may reject the card without configuring it.
Unless otherwise specified, all signals must be implemented by the system to be compliant with the
I/O portion of the Standard. Since systems with 8-bit data buses are not required to implement
16-bit data buses or 16-bit operations, such 8-bit systems must keep the CE2# signal in the negated
state at all times.
4.3.5 Custom Interfaces

Systems may provide custom interfaces through a standard socket. Custom interfaces are expected to
support enhanced features, such as internal bus extensions, or customized signals not applicable
across architectures. A card or a socket may support more than one custom interface.
A custom interface is handled by the system and the card in a manner similar to an I/O and
Memory interface. Both the socket and the card must use a Memory Only interface when a card is
inserted, or when power is removed from a card. After a card is powered up, the system reads the
card's Card Information Structure. If the card is found to support a custom interface also supported
by the host socket, the card and the socket may be configured to the custom interface mode. The
card is configured using the Configuration Index field of the Configuration Option register. (See 4.15
Card Configuration and see also TPCE_IF: Interface Description Field in the Metaformat
Specification for the configuration entry tuple [CISTPL_CFTABLE_ENTRY].)
4.3.6 Configurable Cards

Certain memory and all peripheral cards may be configured by the system. This is to ensure that
cards incompatible with the system, or with other cards installed in the system, are either
compatibly reconfigured, or rejected, if a compatible configuration is not available on the card.
The system adjusts the card using the Function Configuration registers. These are located in the
card's Attribute Memory space, at the location indicated in the card's Card Information Structure.
(See 4.15 Card Configuration.)
4.4 Signal Description

Signal names followed by a pound sign, (#), are asserted when the line is low, VOL max or below,
and negated when the line is high, V OH min or above. All other signals are asserted when high,
VOH min or above, and negated when low, VOL max or below. (See Table 4Ð18 PC Card Logic
Levels.)
All signals are grouped under four classifications: I (Input), O (Output), I/O (Bi-directional), and R
(Reserved). Input signals are those driven by the host and output signals are those driven by the
PC Card.
All pins identified as ground shall be connected to signal ground at the host. Signal pins identified
as RFU in all interface modes supported by a host system or PC Card shall have no connection at
the host system or the card, respectively.
4.4.1 Address BUS (A[25::0])

Signals A[25::0] are address bus input lines which enable direct address of up to 64 MB of memory
on the card. Signal A0 is not used in memory word access mode. During I/O word access cycles A0
must be negated. Signal A25 is the most significant bit; bit number (and significance) decrease to
A0.
4.4.2 Data BUS (D[15::0])

Signals D[15::0] constitute the bi-directional data bus. The most significant bit is D15. Bit number
(and significance) decrease downward to D0. The data path to memory space is 16 bits. The data
path to I/O space is 8 or 16 bits.
4.4.3 Card Enable (CE[2::1]#)

The CE[2::1]# lines are active low, Card Enable, input signals. The CE1# input enables even
numbered address bytes and CE2# enables odd numbered address bytes. A multiplexing scheme
based on A0 and CE1# allows 8-bit hosts to access all data on D[7::0] if desired. (See Table 4Ð7
Common Memory Write Function.)
To ensure data retention on battery backed-up SRAM cards, and permit power-up initialization of
peripheral cards, a minimum of 20 ms must elapse after:
1. the application of VCC to the card, or
2. RESET signal negated (in systems which support the RESET signal), whichever event occurs
latest.
The Card Enables are used to access both Common and Attribute Memory, and to access I/O. (See
also 4.6.1.1 Common Memory Read Function and 4.13 I/O Function.)
4.4.4 Output Enable (OE#)

The OE# line is an active low, input signal used to gate Memory Read data from a memory card.
Hosts must negate the OE# signal during write operations.
4.4.5 Write Enable (WE#)

The WE# input signal is used for strobing Memory Write data into the memory card. This line is
also used for memory cards employing programmable memory technologies. (See also the
Metaformat Specification.)
4.4.6 Ready (READY)

The Ready function is provided by the READY signal when the card and the host socket are
configured as a Memory Only interface. When a host socket and the card inserted into it are both
configured for the I/O interface, the READY function is provided by the RREADY status bit in the
card's Pin Replacement register. When the Pin Replacement register is not implemented on a card
configured for the I/O interface, the Ready function is continuously in the ready condition. The
following descriptions of the READY signal apply equally to both the READY signal of the Memory
Only interface and to the RREADY bit in the Pin Replacement register of a card configured for the
I/O interface. (See also 4.15.3 Pin Replacement Register.)
The READY signal is a status signal polled by the host, or used by the socket to generate an
interrupt on the Busy-to-Ready transition or on both transitions. It is intended to indicate the
completion of potentially lengthy operations within a PC Card. It is not intended to delay the
completion of a machine cycle at the PC Card interface or on the host's internal bus, the WAIT#
signal is available for that purpose.
The READY line is negated by the PC Card to indicate that the PC Card circuits are busy and
unable to accept some data transfer operations. The READY signal is negated while the card is busy
processing a previous command or performing initialization. The signal READY is asserted when
the PC Card is ready to accept a new data transfer command.
When independent, unrelated sources for the READY signal are present on a PC Card, READY
signal shall be negated while any of the unrelated sources of the READY on the card require the
blocking of certain host accesses and are indicating busy. A group of related devices on the card and
managed by the same host software shall be treated collectively as a single independent source of
READY.
A PC Card is permitted to process subsequent operations from the host while the READY signal is
negated if its internal circuits allow proper operation. It is the responsibility of the card or device
vendor to communicate (through CIS descriptions or other means) those operations which are
permitted to a card while the READY signal is negated . In the absence of any such knowledge, the
host shall not attempt any access to the card while the READY signal is negated.
The host must not access a card until a minimum of 20 ms has passed after VCC is stable, and, for
PCMCIA 2.0 / JEIDA 4.1 release and later systems, after the RESET signal is negated. In addition,
the card's READY line must be asserted before the initial access. If the card will not be initialized
and ready for operations at the end of the 20 ms waiting period, the READY signal will be negated
within 10 µs of RESET or application of VCC to the card. A card that requires more than 20 ms for
internal initialization before access shall negate READY until it is ready for initial access, a period of
time which is not to exceed five seconds following the time at which the RESET signal is negated (or
if no RESET is implemented, VCC is stable).
The PCMCIA 1.0 / JEIDA 4.0 release required that cards containing battery backed-up SRAM not
be accessed before 20 ms after stable power is applied. However, some systems otherwise
conforming to the PCMCIA 1.0 / JEIDA 4.0 release may access a card before the end of the
initialization period. Therefore, it is recommended that during the initialization period the PC
Card's Card Information Structure contain the correct card description. If that is not possible, then it
should contain a valid CIS description of a null or ROM device. This will prevent the PCMCIA 1.0 /
JEIDA 4.0 release system from presuming that the card is an uninitialized SRAM card.
Note: a PCMCIA 1.0 / JEIDA 4.0 release system will never remove the reset
condition (as RESET is not connected in such a system).
If the card will require more than 10 µs to enter the sleep mode, or to return to operating condition
following card wakeup, the READY signal will be negated within 10 µs after the power down bit in
the Configuration and Status register is changed. Following card wakeup the host must not access
the card until a minimum of 10 µs has passed and the card's READY line is asserted. If a card
requires more than 10 µs following wakeup, and before the card is ready for operation, the card
shall negate READY until the card is ready for operation.
When a card and its socket have been configured for the I/O interface, the READY status may be
available in the Pin Replacement register and the signal is replaced on interface pin 16 with the
IREQ# (Interrupt Request) signal. (See also 4.4.7 Interrupt Request (IREQ#) [I/O and Memory
Interface].)
4.4.7 Interrupt Request (IREQ#) [I/O and Memory Interface]

Interrupt Request is asserted by an I/O Card to indicate to the host system that a PC Card device
requires host software service. The interrupt signal at the interface is routed by the system to one of
the interrupt request signals on the system's internal bus. The signal is negated when no interrupt
is requested.
The Interrupt Request signal is available only when the card and the interface are configured for
the I/O and Memory interface. (See also the Metaformat Specification.)
4.4.7.1 Interrupt Request Routing

A general purpose host system should be able to route each card's interrupt request to any of the
interrupt request levels used for installable devices within the system. A host system which has
dedicated hardware and software may support only a subset of interrupt request levels necessary
for the application. Driver software customization will be necessary to support I/O cards in a
dedicated system environment.
Note: For PC compatible computers it is recommended that IREQ# from the card
be able to be routed to at least the interrupt signals shown in Table 4Ð4 and
Figure 4-1.
Table 4Ð4 IREQ# Interrupt Signals

Function AT IRQ XT IRQ
Communications 2 (COM2) IRQ3 IRQ3
Communications 1 (COM1) IRQ4 IRQ4
Fixed Disk IRQ14 IRQ5
Floppy Disk IRQ6 IRQ6
Parallel Port (LPT1) IRQ7 IRQ7
Network/Other IRQ10 Not Available
COM2 IRQ
Interrupt
from Card COM1 IRQ
Personal
Computer Fixed Disk IRQ
Interrupt Block Floppy Disk IRQ
Select from Diagram Parallel IRQ
System Network IRQ
Figure 4-1 Recommended PC Compatible Interrupt Request Signals
4.4.7.2 Level and Pulsed Mode Interrupt Support

The Interrupt Request may be either a pulse or a level mode dependent upon the needs of the
system.
I/O cards designed to operate in a variety of machines should support both level and pulse mode
interrupts. Therefore, it is recommended that I/O cards support both of these modes.
The host system selects the mode of interrupt, level or pulsed, through the Function Configuration
registers. Refer to Section 4.15, Card Configuration, for further information.
4.4.7.2.1 Level Mode Interrupt Signal

A level mode interrupt is asserted by placing the Interrupt Request signal in the asserted state until
the interrupt has been serviced by the system. The interrupt request signal is then held in the
negated state. The level mode interrupt is standard in PC-compatible systems using the Micro
Channel Architecture, as well as in many non-PC-compatible systems.
PC Cards must support the level interrupt request mode.
4.4.7.2.2 Pulsed Mode Interrupt Signal

A pulsed mode interrupt is asserted by placing a pulse on the interrupt line. Pulsed mode
interrupts are generally utilized by systems using the "ISA" Personal Computer bus architecture in
which interrupts are edge sensitive. The pulse width must be at least 0.5 µs.
Note: The pulsed mode interrupt may be lost when more than one interrupting
device shares an interrupt request signal at the system bus, and standard
system and application software is used. Interrupt requests may be lost if
they arrive at the system before a prior request on the shared interrupt
request signal has been fully serviced.
4.4.8 Card Detect (CD[2::1]#)

The CD[2::1]# signals provide for proper detection of PC Card insertion. The signal pins are at
opposite ends of the connector to ensure a valid detection (i.e., ensuring both sides of the card are
firmly inserted). The CD[2::1]# signals are connected to ground internally on the PC Card and will
be forced low whenever a card is placed in a host socket. The host socket interface circuitry shall
provide 10 KΩ or larger pull-up resistors to VCC on each of these signal pins.
Host sockets shall decode both CD[2::1]# pins when detecting PC Card presence. Failure to do so
may cause electrical damage to PC Cards.
4.4.9 Write Protect (WP) [Memory Only Interface]

The WP output signal is used to reflect the status of the PC Card's Write Protect switch. If the Write
Protect switch is present, the WP signal will be asserted by the card when the switch is enabled,
and negated when the switch is disabled. If the memory card has no Write Protect switch, the card
will connect this line to GND or VCC depending on the condition of the card memory. For example,
if the card can always be written to, the pin will be connected to GND, and if the card is
permanently Write Protected, the pin will be connected to VCC.
When a card or socket is configured for the I/O interface, the Write Protect status may be available
in the Pin Replacement register, and the signal is replaced in the interface by the I/O Port is 16 bits
(IOIS16#) signal. (See 4.4.10 I/O Is 16 Bit Port (IOIS16#) [I/O and Memory Interface].)
4.4.10 I/O Is 16 Bit Port (IOIS16#) [I/O and Memory Interface]

The IOIS16# output signal is asserted when the address at the socket corresponds to an I/O address
to which the card responds, and the I/O port addressed is capable of 16-bit access.
When this signal is not asserted during a 16-bit I/O access, the system will generate 8-bit references
to the even and odd byte of the 16-bit port being accessed.
4.4.11 Attribute Memory Select (REG#)

When the REG# signal is asserted, access is limited to Attribute Memory (OE# or WE# active) and
to the I/O space (IORD# or IOWR# active). Attribute Memory is a separately accessed section of
card memory and is generally used to record card capacity and other configuration and attribute
information. Attribute Memory is also used to access standardized Function Configuration registers.
The REG# signal is kept negated for all Common Memory accesses.
The timing of Attribute Memory may be different than that of Common Memory. When Attribute
Memory is accessed, only data signals D[7::0] are valid and signals D[15::8] shall be ignored.
Signals CE[2::1]# and A0 are still valid, but it is only possible to select even numbered addresses. A
combination of signals CE[2::1]# and A0 that requests an odd numbered byte will result in invalid
data on the bus. (See Table 4Ð8 Attribute Memory Read Function.)
I/O space is used to access peripheral devices via the IORD# and IOWR# strobe signals. Systems
which generate the IORD# and IOWR# strobe signals during DMA operations must keep REG# in
a negated state during 16-bit PC Card DMA transfers to prevent spurious I/O accesses while a
memory address is present on the address lines.
The host system will use REG# as DMA acknowledge when the socket and PC Card are configured
for 16-bit PC Card DMA I/O operations. (See 4.5 DMA Signals Replacing I/O Interface Signals.)
4.4.12 Battery Voltage Detect (BVD[2::1]) [Memory Only Interface]

The signals BVD[2::1] are generated by the PC Card as an indication of the condition of its battery.
Both signals are asserted while the battery is in good condition. A replacement warning condition is
signaled by BVD1 asserted and BVD2 negated. If BVD1 is negated, with BVD2 either asserted or
negated, the battery is no longer providing operational voltage. (See Table 4Ð20 Battery Voltage
Detect.)
When the I/O and Memory interface is selected, the BVD[2::1] signals are replaced at the interface
by the card Status Changed (STSCHG#) and the Audio Digital Waveform (SPKR#) signals,
respectively. The battery voltage status information may be available in the card's Pin Replacement
register while the I/O interface is configured.(See also 4.4.13 Status Changed (STSCHG#) [I/O and
Memory Interface] and 4.4.14 Audio Digital Waveform (SPKR#) [I/O and Memory Interface].)
4.4.13 Status Changed (STSCHG#) [I/O and Memory Interface]

Status Changed (STSCHG#) is an optional signal used to alert the system to changes in the Ready
(READY), Write Protect (WP), or Battery Voltage (BVD[2::1]) conditions or a change to a Ò1Ó state of
bits [7::4] (when enabled by the respective Enable bit [3::0]) in the Extended Status register of the
card while the I/O and Memory interface is configured.
STSCHG# is held negated if the function is not supported by the card or when the SigChg bit in the
Configuration and Status register is false (reset to 0). When the SigChg bit is true (set to 1), the
Status Changed signal is asserted when the Changed bit in the Function Configuration and Status
register is true (set to 1), and the signal is negated when the Changed bit is false (reset to 0). The
Changed bit is the logical OR result of the individual changed bits Ñ CBVD1, CBVD2, CWProt, and
CREADY Ñ in the Pin Replacement register and the upper four bits [7::4] in the optional Extended
Status register. The Extended Status register upper four bits [7::4] are only included when the
corresponding Extended Status register enable bits, the lower four bits [3::0] have been set high
(logic 1).
The system mechanism used for BVD1 fail detection may be used to detect a change of status
signals. Therefore, cards which are configured for I/O operation may continue to notify the system
of changes of these status signals although the status signals no longer appear as independent
signals on the card interface.
While the card and socket are configured for the Memory Only interface, the BVD1 signal is
available on this pin. (See 4.15.3 Pin Replacement Register.)
4.4.14 Audio Digital Waveform (SPKR#) [I/O and Memory Interface]

This Binary Audio signal is an optional signal which may be available only when the card and the
socket have been configured for the I/O interface. It provides a single amplitude, on-off, (binary)
audio wave form intended to drive the host's loudspeaker. The signal to the speaker should be
generated by taking the exclusive-OR function of the SPKR# signals from all those cards providing
Binary Audio, and from the system speaker source. When no audio signal is present, or if the card
does not support the Binary Audio function, the SPKR# signal shall be held negated.
PC Cards which supply the Binary Audio function are also required to support the Audio Enable bit
in the Function Configuration and Status register. This allows the system to selectively enable or
disable the audio function. (See 4.15.2 Configuration and Status Register.)
It is recommended that systems support the Binary Audio function.
While the card and socket are configured for the Memory Only interface, the BVD2 signal is
available on this pin. (See 4.15.3 Pin Replacement Register.)
4.4.15 Program and Peripheral Voltages (VPP[2::1])

The VPP[2::1] signals supply programming voltages for programmable memory operation, or
additional supply voltages for peripheral cards. These pins are to be connected to the VCC voltage
level until the Card Information Structure (CIS) of the card has been read and other permissible
values for VPP[2::1] have been determined. VPP[2::1] voltages are used on the card for Peripheral
Card operation and for altering programmable memory on the card. The voltage applied to the
VPP[2::1] pins of a card must never be greater than the program and peripheral voltage level
appropriate for the card. If the appropriate program and peripheral voltage level voltage for a card
cannot be determined, the voltage applied to the VPP[2::1] pins must not exceed VCC. (See also the
Metaformat Specification, the Card Services Specification, and the Socket Services Specification.)
Systems are required to be able to supply the VCC level on the VPP[2::1] pins. It is recommended
that systems be able to supply at least the program and peripheral voltage level voltage of +12 V
±5% in addition to the VCC level. For low power applications it is recommended that the system be
able to apply a low logic level to VPP[2::1]. When the program and peripheral voltage level
required by a card is unavailable in a system, the system may reject the card.
4.4.16 Voltage and Ground (VCC & GND)

The VCC and GND input pins have been placed at symmetrical positions on the memory card. Two
power pins (17 and 51) and four ground pins (1, 34, 35 and 68) are employed to reduce the
impedance between the memory card and the system.
4.4.16.1 Socket VCC for CIS Read

A 5 V only socket shall be keyed with the 5 V key. This key will only allow the insertion of cards
with the 5 V key. Such a socket shall always apply initial VCC at 5 V and need not sense the
VS[2::1]# signals.
A socket may be keyed with the Low Voltage key. Power to the card must be off and the card
inputs not driven before the card is inserted. This key will allow the insertion of both 5 V keyed
and Low Voltage keyed cards. A socket capable of accepting a card with a Low Voltage key shall
implement cold insertion (i.e., turn VCC off and switch signals to high impedance or 0 V to empty
sockets), and treat the VS[2::1]# pins as valid when CD[2::1]# are both asserted. Failure to require
both CD[2::1]# pins to be asserted may result in falsely decoding a cardÕs VCC requirements.
If only one of CD[2::1]# pins is asserted, the user may be notified that one of the following
conditions exists:
• PC Card is of a type not supported by this socket, or
• card is not inserted correctly or completely.
All Low Voltage keyed socket hardware shall ensure that voltages on VCC and VPP[2::1] are
removed from the socket, without software intervention, before the next PC Card is inserted into the
socket. If the socket hardware automatically applies power to a PC Card after insertion, it shall not
apply a voltage other than indicated by the Voltage Sense pins (VS[2::1]#).
If VS[2::1]# indicate a VCC value the socket is capable of providing, the socket shall apply that VCC
level to the PC Card. If VS[2::1]# indicate no value of VCC the socket is capable of providing, the
card inputs shall not be driven, the card shall not be powered and the user may be notified. (See
Table 4Ð5 Vcc at Initial Power-Up and CIS Read.)
4.4.16.2 PC Card VCC for CIS Read

Any PC Card capable of having CIS read at 5 V shall be keyed with the 5 V key. VS[2::1]# shall be
implemented in the PC Card to indicate the values of VCC at which the PC Card CIS can be read.
(See Table 4Ð5 Vcc at Initial Power-Up and CIS Read.)
Any PC Card not capable of having CIS read at 5 V shall be keyed with the Low Voltage key.
VS[2::1]# shall be implemented in the PC Card to indicate the values of VCC at which the PC Card
CIS can be read.
Having applied the proper VCC, the host system shall read the PC CardÕs Card Information
Structure to determine the cardÕs characteristics. For example, if the host system can provide both 5
V and 3.3 V VCC, the card is powered at 3.3 V, and the cardÕs CIS indicates that the card can also
operate at 5 V , the host system can change the card VCC to 5 V.
The CIS on a PC Card shall be readable at all VCC levels indicated by the CIS and voltage sense
pins.
4.4.16.3 Changing PC Card VCC

To change VCC, the host shall direct the socket to discharge the PC Card connectorÕs VCC and
VPP[2::1] to ground, then power-up the card at the new voltage. Further, care should be taken
when dynamically changing the voltage applied to VCC or VPP[2::1] so that power supply shorts do
not occur. The host must recognize that the card will retain no knowledge of the power-up at the
previous VCC and all configuration and other initialization must be done following the second
power-up. If any Card Detect pin is negated at any time, the host system must recognize that the
card may have been replaced and repeat the entire power-up sequence.
4.4.17 Voltage Sense (VS[2::1]#)

The Voltage Sense signals are intended to notify the socket of the PC CardÕs CIS VCC requirement.
(See Table 4Ð5 Vcc at Initial Power-Up and CIS Read and see also Table 4Ð19 Electrical Interface.)
WA R N IN G
The socket must not actively drive VS1# or VS2# when determining a valid
card insertion (i.e., both CD1# and CD2# pins low). If a socket chooses to
drive VS1# or VS2#, it must set both of them at high-impedance before final
determination of a valid card insertion. Failure to do so can lead to falsely
decoding the VCC requirements and signal protocol of PC Cards.
Table 4Ð5 VCC at Initial Power-Up and CIS Read

Card Type VS1# VS2# Socket Type VCC at initial power-up and CIS read
1 1
5 V key NC NC 5 V key 5V
5 V only CIS Low Voltage key - 5 V available 5V
Low Voltage key - no 5 V available Shall not be powered-up - user may be notified
1
Low Voltage key ground NC 5 V key Shall not fit into socket
3.3 V only CIS Low Voltage key - 3.3 V available 3.3 V
Low Voltage key - no 3.3 V available Shall not be powered-up - user may be notified
1
5 V key ground NC 5 V key 5V
3.3 V and 5 V CIS Low Voltage key - only 3.3 V available 3.3 V
Low Voltage key - 3.3 V and 5 V 3.3 V
available
Low Voltage key - no 3.3 V or 5 V Shall not be powered-up - user may be notified
available
Low Voltage key NC 1 ground 5 V key Shall not fit into socket
1
X.X V only CIS Low Voltage key - X.X V available X.X 1 V
Low Voltage key - no X.X V available Shall not be powered-up - user may be notified
Low Voltage key ground ground 5 V key Shall not fit into socket
X.X 1 and 3.3 V CIS Low Voltage key - Only X.X V available X.X 1 V
Low Voltage key - Only 3.3 V available 3.3 V
Low Voltage key - 3.3 V and X.X V X.X 1 V or 3.3 V
available
5 V key ground ground 5 V key 5V

1
X.X V, 3.3 V and Low Voltage key - Only X.X V available X.X 1 V
5 V CIS
Low Voltage key - X.X V, 3.3 V, 5 V X.X 1 V or 3.3 V
available
Low Voltage key - 3.3 V and 5 V 3.3 V
available
X.X V is less than 3.3 V.
1. NC indicates no connection in the card.
4.4.18 I/O Read (IORD#) [I/O and Memory Interface]

The IORD# signal is made active to read data from the card's I/O space. The REG# signal and at
least one of CE[2::1]# must also be active for the I/O transfer to take place. A PC Card will not
respond to the IORD# signal until it has been configured for I/O operation by the system.
4.4.19 I/O Write (IOWR#) [I/O and Memory Interface]

The IOWR# signal is made active to write data to the card's I/O space. The REG# signal and at
least one of CE[2::1]# must also be active for the I/O transfer to take place. A PC Card will not
respond to the IOWR# signal until it has been configured for I/O operation by the system.
4.4.20 Card Reset (RESET)

The RESET signal clears the Configuration Option register thus placing a card in an unconfigured
(Memory Only interface) state. It also signals the beginning of any additional card initialization. The
system must place the RESET signal in a High-Z state during card power-up (including both VCC
turn-on and hot insertion). The signal must remain high impedance for at least 1 ms after VCC
becomes valid. All configurable cards (including all I/O Cards) must monitor RESET and return to
the unconfigured state when RESET is active. A card remains in the unconfigured state until the
Configuration Option register has been written with a valid configuration.
PC Cards requiring RESET must enter the unconfigured state each time power is applied. For
example:
1. the card may generate a power-on RESET internally, or
2. the RESET signal may be pulled up to VCC through a ≥100 Kê resistor on cards requiring reset.
This ensures that when a card is inserted into a socket it is reset before the signal pins make contact
with the socket, and the card is reset (continuously) when placed into a PCMCIA 1.0 / JEIDA 4.0
release compatible socket.
RESET must not be connected between PC Cards unless all PC Cards are reset when any card has
VCC power removed.
4.4.21 Extend Bus Cycle (WAIT#)

The WAIT# signal is asserted by a PC Card to delay completion of the memory access or I/O access
cycle then in progress.
4.4.22 Input Port Acknowledge (INPACK#) [I/O and Memory Interface]

The Input Acknowledge output signal is asserted when the PC Card is selected and can respond to
an I/O read cycle at the address on the address bus. This signal is used by the host to control the
enable of any input data buffer between the card and the host system data bus. This signal must be
inactive until the card is configured.
Note: In cases where a card is configured to respond to I/O read cycles at all
addresses, the INPACK# signal may be asserted whenever the Card
Enable (CE[2::1]#) inputs are asserted.
4.5 DMA Signals Replacing I/O Interface Signals
4.5.1 DMA Request (DREQ#)

The DMA Request signal is only available when a PC Card and socket are configured for DMA
operations. A PC Card asserts DREQ# to indicate to the host that it is requesting service. The PC
Card asserts DREQ# until the host responds by asserting DACK.
A PC Card may use any one of the following three pins for DREQ#: SPKR#, INPACK# or
IOIS16#. A PC Card indicates the pin used for DREQ# in the Miscellaneous Features Field of the
selected card configuration. (See also the Metaformat Specification and the Card Services
Specification.)
PC Cards and sockets are not required to support DMA operations. However, to be compliant with
this specification, a PC Card socket supporting DMA operations must be able to receive DREQ#
from a PC Card on any of the following three pins: SPKR#, INPACK# or IOIS16#. Socket
implementations which do not support all three pins for DREQ# are not compliant with this
specification's requirements for DMA operations.
4.5.2 DMA Acknowledge (DACK) [replaces REG#]

A DMA operation is indicated when DACK is active and either IORD# or IOWR# is active. The
host asserts DACK during all DMA operations. The host uses REG# for DACK. DACK is not
asserted for non-DMA I/O operations.
The DMA Acknowledge signal is only available when the PC Card and the socket are configured
for DMA operations.
4.5.3 DMA Read (IOWR#)

The host asserts IOWR# to write data to a PC Card's I/O space. During DMA read operations the
host asserts DACK and IOWR# to transfer data from system memory to a PC Card.
To respond to DMA read requests, the PC Card must be configured for I/O and DMA operations.
4.5.4 DMA Write (IORD#)

The host asserts IORD# to read data from a PC Card's I/O space. During DMA write operations the
host asserts DACK and IORD# to transfer data from a PC Card to system memory.
To respond to DMA write requests, the PC Card must be configured for I/O and DMA operations.
4.5.5 Terminal Count (TC#)

The host signals terminal count for DMA read operations by asserting WE#. The host signals
terminal count for DMA write operations by asserting OE#.
4.6 Memory Function
4.6.1 Common Memory Function

This section describes the functions of the Common Memory area.
4.6.1.1 Common Memory Read Function for PC Cards

A memory card can be configured with different types of memory devices (such as SRAM,
MaskROM, etc.), however, the Read function shares common signal state sequencing.
To access Common Memory, the signal REG# shall be kept inactive, and the signal OE# shall be
active during the Read cycle. Signals CE[2::1]# control the activation of the Memory Card and A0
control byte ordering on the data bus lines D[15::0]. (See Table 4Ð6 Common Memory Read
Function.)
When both CE[2::1]# are inactive, the card is in standby mode. When either CE[2::1]# become
asserted, the memory card is activated and ready for data transfers. When CE1# is active and CE2#
is not active, Byte Access mode is enabled (8-bit transfers). Both the even byte data and odd byte
data outputs will be valid in data bus lines D[7::0]. The selection of an even byte or an odd byte is
controlled by A0.
When using word access (16-bit transfers), both CE1# and CE2# are asserted, and the even-byte
data and odd-byte data outputs are valid in data bus lines D[15::0]. During Word mode, A0 is
ignored.
Odd-Byte-Only access is enabled when CE1# is negated and CE2# asserted. During Odd-Byte-Only
access, only data lines D[15::8] contain valid data, and A0 is ignored.
Table 4Ð6 Common Memory Read Function

Function Mode REG# CE2# CE1# A0 OE# WE# VPP2 VPP1 D[15::8] D[7::0]
Standby Mode X H H X X X VCC 1 VCC 1 High-Z High-Z
1 1
Byte Access (8 bits) H H L L L H VCC VCC High-Z Even-Byte
H H L H L H VCC 1 VCC 1 High-Z Odd-Byte
1 1
Word Access (16 bits) H L L X L H VCC VCC Odd-Byte Even-Byte
Odd-Byte-Only Access H L H X L H VCC 1 VCC 1 Odd-Byte High-Z
X indicates any value.
1. Additional VPP[2::1] values for Read Function are permitted when cards use VPP[2::1] voltages as
additional power supply levels rather than only for programmable memory. However, no voltage level
other than VCC may be applied to the VPP[2::1] pins until a card has been identified as supporting
alternate program and peripheral voltage levels by reading its Card Information Structure. (See 4.4.15
Program and Peripheral Voltages (Vpp[2::1]).)
4.6.1.2 Common Memory Write Function for PC Cards

During Write mode, the function of signals REG#, CE[2::1]# and A0 are the same as in the Read
mode.
During Write mode, signal OE# must be negated, and signal WE# is asserted. A memory card can
perform Write operations in three modes: Byte access, Word access, and Odd-Byte-Only access.
Table 4Ð7 Common Memory Write Function

Standby Mode X H H X X X VCC 1 VCC 1 X X
1 1
Byte Access (8 bits) H H L L H L VCC VCC X Even-Byte
H H L H H L VCC 1 VCC 1 X Odd-Byte
Word Access (16 bits) H L L X H L VCC 1 VCC 1 Odd-Byte Even-Byte
Odd Byte Only Access H L H X H L VCC 1 VCC 1 Odd-Byte X
1. Additional VPP[2::1] values for Write Function are permitted when cards use VPP[2::1] voltages as
4.6.1.3 Common Memory Write Function for OTPROM, EPROM and Flash Memory
OTPROM, EPROM and Flash Memory devices may have additional requirements. Refer to the
JEDIC ID information for CIS information.
4.6.2 Attribute Memory Function

Attribute Memory is an optional space intended for storing PC Card identification and configuration
information, and does not require a large address space. Attribute Memory is limited to 8-bit wide
access for economic reasons.
4.6.2.1 Attribute Memory Read Function

For the Attribute Memory Read function, signals REG# and OE# must be active during the read
cycle. As in the Common Memory Read function, the signals CE[2::1]# control the even byte and
odd byte address, but only even byte data is valid during the Attribute Memory Read function.
Table 4Ð8 Attribute Memory Read Function

Standby Mode X H H X X X VCC 1 VCC 1 High-Z High-Z
1 1
Byte Access (8 bits) L H L L L H VCC VCC High-Z Even-Byte
L H L H L H VCC 1 VCC 1 High-Z Not Valid
1 1
Word Access (16 bits) L L L X L H VCC VCC Not Valid Even-Byte
Odd Byte Only Access L L H X L H VCC 1 VCC 1 Not Valid High-Z
1. Additional VPP[2::1] values for Read Function are permitted when cards use VPP[2::1] voltages as
4.6.2.2 Attribute Memory Write Function

While writing to Attribute Memory, signals REG# and WE# must be kept asserted for the entire
cycle while the signal OE# is negated for the entire cycle.
Table 4Ð9 Attribute Memory Write Function

Standby Mode X H H X X X VCC 1 VCC 1 X X
1 1
Byte Access (8 bits) L H L L H L VCC VCC X Even-Byte
L H L H H L VCC 1 VCC 1 X X
Word Access (16 bits) L L L X H L VCC 1 VCC 1 X Even-Byte
Odd Byte Only Access L L H X H L VCC 1 VCC 1 X X
1. Additional VPP[2::1] values for Write Function are permitted when cards use VPP[2::1] voltages as
4.6.2.3 Attribute Memory Write Function for Dual Supply OTPROM, EPROM and
Flash Memory
OTPROM, EPROM and Flash Memory devices may have additional requirements. Refer to the
JEDIC ID information for CIS information.
4.6.3 Write Protect Function

The following table describes the Write Protection options and corresponding Write Protect (WP)
switch and signal states. (See also the Metaformat Specification.)
Table 4Ð10 Write Protect Function

Memory Write Protect WP Switch WP Signal Minimum Card Information Contents Related to Write
Combinations on Card Protect
Always Write Enabled None Low No WP Information Needed - Memory follows WP signal
which is always negated (Disabled). Optionally the CIS may
specify all devices as always write enabled.
Never Write Enabled None High No WP Information Needed - Memory follows WP signal
which is always High (Enabled). Optionally the CIS may
specify all devices as never write enabled.
Switch Controlled Enabled High No WP Information Needed - Memory folllows WP signal.
Disabled Low
Always/Never None Low CIS must specify devices (addresses) which ignore the WP
signal and are never write enabled. The remaining devices
follow the WP signal and are therefore always write enabled.
Always/Switch Enabled High CIS must specify devices (addresses) which ignore the WP
signal and are always write enabled. The remaining devices
follow the WP signal.
Disabled Low
Never/Switch Enabled High CIS must specify devices (addresses) which ignore the WP
signal and are never write enabled. The remaining devices
follow the WP signal.
Disabled Low
Always/Never/Switch Enabled High CIS must specify both devices (addresses) which ignore the
WP signal and are always write enabled as well as the
devices which ignore the WP signal and are never write
enabled. The remaining devices follow the WP signal.
Diabled Low
4.7 Timing Functions

This section describes Common and Attribute Memory Access Timing.
4.7.1 Common Memory Read Timing

There are several types of memory cards, SRAM, OTPROM, etc., and within a memory card,
several types of memory devices may be mounted. To maintain compatibility among several types
of memory devices, read timing specifications are common.
Table 4Ð11 Common Memory Read Timing Specification for all Types of Memory
Speed Version 600 ns 1,2 250 ns 3 200 ns 150 ns 100 ns
Item Symbol IEEE Min Max Min Max Min Max Min Max Min Max
Symbol
Read Cycle Time tcR t AVAV 600 2 250 5 200 150 100
4 2 3
Address Access Time ta(A) t AVQV 600 250 200 150 100
2 3
Card Enable Access Time ta (CE) t ELQV 600 250 200 150 100
2 3
Output Enable Access ta(OE) t GLQV 300 125 100 75 50
Time
Output Disable Time from tdis(OE) t GHQZ 150 100 90 75 50
OE#
Output Enable Time from ten(CE) t ELQNZ 5 5 5 5 5
CE#
Data Valid from Add tv(A) t AXQX 0 0 0 0 0
Change 4
Address Setup Time 5 tsu(A) t AVGL 100 30 20 20 10
5
Address Hold Time th(A) t GHAX 35 20 20 20 15
5
Card Enable Setup Time tsu(CE) t ELGL 0 0 0 0 0
5
Card Enable Hold Time th(CE) t GHEH 35 20 20 20 15
5
WAIT# Valid from OE# tv(WT-OE) t GLWTV 100 35 35 35 35
12 µs 12 µs 12 µs 12 µs 12 µs
6
WAIT# Pulse Width tw (WT) t
WTLWTH
Data Setup for WAIT# tv WT) t QVWTH 0 0 0 0 0
Released 6
1. 600 ns cycle times apply for 3.3 V operating voltage.
2. 3.3 V timing for cycles >600 ns are equal to value given + (cycle time-600). All other parameters are
identical.
3. 5 V timing for cycles >250 ns are equal to value given + (cycle time-250). All other parameters are
identical.
4. The REG# signal timing is identical to address signal timing.
5. These timings are specified for hosts and cards which support the WAIT# signal.
6. These timings specified only when WAIT# is asserted within the cycle.
7. All timings measured at the PC Card. Skews and delays from the system driver/receiver to the PC
Card must be accounted for by the system.
4.7.2 Common and Attribute Memory Write Timing

The write timing specifications for Common and Attribute memory are the same.
Table 4Ð12 Common and Attribute Memory Write Timing Specifications

Speed Version 600 ns 1,2 250 ns 3 200 ns 150 ns 100 ns
Item Symbol IEEE Min Max Min Max Min Max Min Max Min Max
Symbol
Write Cycle Time tc W t AVAV 600 2 250 3 200 150 100
2 3
Write Pulse Width tw(WE) t WLWH 300 150 120 80 60
4
Address Setup Time tsu(A) t AVWL 50 30 20 20 10
2 3
Address Setup Time tsu(A-WEH) t AVWH 350 180 140 100 70
for WE# 4
Card Enable Setup tsu(CE-WEH) t ELWH 300 2 180 3 140 100 70
Time for WE#
Data Setup Time for t(D-WEH) t DVWH 150 2 80 3 60 50 40
WE#
Data Hold Time th(D) t WMDX 70 30 30 20 15
Write Recover Time trec(WE) t WMAX 70 30 30 20 15
Output Disable Time tdis(WE) t WLQZ 150 100 90 75 50

from WE#
Output Disable Time tdis(OE) t GHQZ 150 100 90 75 50
from OE#
Output Enable Time ten(WE) t WHQNZ 5 5 5 5 5
from WE#
Output Enable Time ten(OE) t GLQNZ 5 5 5 5 5
from OE#
Output Enable Setup tsu(OE-WE) t GHWL 35 10 10 10 10
from WE#
Output Enable Hold th(OE-WE) t WHGL 35 10 10 10 10
from WE#
Card Enable Setup tsu(CE) t ELWL 0 0 0 0 0
Time 5
Card Enable Hold th(CE) t GHEH 35 20 20 20 15
Time 5
WAIT# Valid from tv(WT-WE) t WLWTV 100 35 35 35 35
WE# 5
WAIT# Pulse Width 6 tw (WT) t WTLWTH 12 µs 12 µs 12 µs 12 µs 12 µs
WE# High from tv(WT) t WTHWH 0 0 0 0 0

WAIT# Released 6
1. 600 ns cycle times apply for 3.3 V operating voltage.
2. 3.3 V timing for cycles >600 ns are equal to value given + (cycle time-600). All other parameters are
identical.
3. 5 V timing for cycles >250 ns are equal to value given + (cycle time-250). All other parameters are
identical.
4. The REG# signal timing is identical to address signal timing.
5. These timings are specified for hosts and cards which support the WAIT# signal.
7. All timings measured at the PC Card. Skews and delays from the system driver/receiver to the PC
Card must be accounted for by the system.
4.7.2.1 Common Memory Write Timing

The programming specification of various memory devices are not standardized. Moreover,
programming specifications may vary among different generations of the same device.
Consequently, it is not practical to set standardized programming specifications for these memory
devices.
4.7.3 Attribute Memory Read Timing Specification

The Attribute MemoryÕs access time is defined as 300 ns at 5 V VCC or 600 ns at 3.3 V VCC.
Detailing timing specifications are shown below.
Table 4Ð13 Attribute Memory Read Timing Specification for all types of Memory
Speed Version 300 ns 600 ns
Item Symbol IEEE Symbol Min Max Min Max
Read Cycle Time tcR t AVAV 300 600
Address Access Time ta (A) t AVQV 300 600
Card Enable Access Time ta (CE) t ELQV 300 600
Output Enable Access Time ta (OE) t GLQV 150 300
Output Disable Time from OE# tdis (OE) t GHQZ 100 150
Output Enable Time from OE# ten (OE) t GLQNZ 5 5
Data Valid from Add Change tv (A) t AXQX 0 0

1
Address Setup Time tsu (A) t AVGL 30 100
1
Address Hold Time th (A) t GHAX 20 35
1
Card Enable Setup Time tsu (CE) t ELGL 0 0
1
Card Enable Hold Time th (CE) t GHEH 20 35
1
WAIT# Valid from OE tv (WT-OE) t GLWTV 35 100
2
WAIT# Pulse Width tw (WT) t WTLWTH 12 us 12 us
2
Data Setup for WAIT# Released tv (WT) t QVWTH 0 0
1. These timing are specified for hosts and PC Cards which support the WAIT# signal.
4.7.4 Attribute Memory Write Timing Specification

In the absence of other information, Attribute Memory Write timing shall be 250 ns SRAM timing
for 5 V operation and 600 ns timing for 3.3 V operation.
4.7.5 Memory Timing Diagrams
tc(R)
(t (A) 2)
a th(A)
1. Shaded areas may be high or low.

2. Applies to card only when WAIT# is negated by card. However, the host shall always provide at least
this access time before sampling data.
3. Applies only when WAIT# is asserted by card.
Figure 4-2 Read Timing Diagram
tcW
A[25::0], REG#
tsu(CE-WEH)
CE# NOTE 1 tsu(CE) NOTE 1
tsu(A-WEH) th(CE)
OE# NOTE 4 NOTE 4
tsu(A) tw(WE) trec(WE)
WE# NOTE 3
tv(WT-WE) tv(WT)
tw(WT)
WAIT# th(OE-WE)
tsu(OE-WE) tsu(D-WEH) th(D)

NOTE 2
D[15::0](Din) DATA INPUT ESTABLISHED
tdis(WE)
tdis(OE) ten(OE)
ten(WE)
D[15::0](Dout)
1. Shaded areas may be high or low.

2. When the data I/O pin is in the output state, no signals shall be applied to the data pins
(D[15::0] by the host system.
3. Minimum write pulse width must be met whether or not WAIT# is asserted by card.
4. May be high or low for write timing, but restrictions on OE# from previous figures apply.
Figure 4-3 Write Timing Diagram
4.8 DMA Function

This section describes DMA transfer cycles for PC Cards and sockets capable of DMA operations.
DMA operations are described with respect to system memory access. During a DMA write, data is
transferred from PC Card I/O space to system memory. During a DMA read, data is transferred
from system memory to PC Card I/O space.
Address lines to the PC Card are ignored during DMA operations.
The movement of one byte or word of data during a DMA operation, is termed a bus cycle. Several
bus cycles make up a DMA transaction.
When a PC Card and socket are configured for DMA operations, the DACK (REG#) signal is used
to distinguish between a DMA cycle and a normal I/O cycle. For a normal I/O cycle, the REG#
signal is asserted for the complete bus cycle. For a DMA transfer cycle, the REG# signal is negated
during the entire DMA bus cycle.
4.8.1 DMA Read Function (Memory Read - I/O Write)

A PC Card requests a DMA read operation by asserting DREQ#. The host responds by asserting
DACK. The host asserts DACK during the entire DMA bus cycle. The host asserts IOWR# to
transfer data. When the DMA transfer is complete, the host asserts TC#(WE#) during the last bus
cycle of the DMA transaction.
Table 4Ð14 DMA Read (Memory Read - I/O Write)

Function DACK DREQ# 1 CE2# CE1# A[25::0] OE# WE# IORD# IOWR# D[15::8] D[7::0]
Standby X X H H X X X X X X X
mode
Byte Access H L H L X H TC# H L X BYTE
DATA
(8-bit)
Word H L L L X H TC# H L HIGH LOW
Access BYTE BYTE
1. PC Cards signal DREQ# using one of the following three (3) pins: SPKR#, INPACK# or IOIS16#.
4.8.2 DMA Read Timing (Memory Read - I/O Write)

td DREQ (DACK)
th DREQ (DACK) td DREQ (IOWR)
DREQ#
tsu DA(IOWR) th DA (IOWR)
DACK (REG#)
tsu CE (IOWR) th CE (IOWR)
CE#
tw (IOWR)
IOWR#
td (IOWR) th (IOWR)
D[15::0]
tsu (TC) tw (TC) th (TC)
TC# (WE#)
Figure 4-4 DMA Read Timing Diagram
Table 4Ð15 DMA Read Timing Parameters

Item Symbol IEEE Min Max
DREQ# active to DACK active td DREQ (DACK) 10,000
DREQ# hold from DACK active th DREQ (DACK) 0
DREQ# inactive to IOWR# inactive td DREQ (IOWR) 0
Data setup to IOWR# inactive td(IOWR) 100
Data hold from IOWR# inactive th(IOWR) 30
IOWR# Width tw(IOWR) 165
DACK setup to IOWR# active tsu DA (IOWR) 5
DACK hold from IOWR# inactive th DA (IOWR) 5
CE# setup to IOWR# active tsu CE (IOWR) 5
CE# hold from IOWR# inactive th CE (IOWR) 20
IOWR# active to TC# active tsu (TC) 10
TC# Width tw (TC) 40
TC# inactive to IOWR# inactive th (TC) 10
All timing in ns.
4.8.3 DMA Write Function (I/O Read - Memory Write)

A PC Card requests a DMA cycle by asserting DREQ#. If the PC Card is granted the DMA request,
the host acknowledges the request by beginning the DMA cycle. DACK is held high by the host
during the entire DMA bus cycle. The host asserts IORD# to transfer data. When the DMA transfer
is complete, the host asserts TC#(OE#) during the last bus cycle of the DMA transaction.
Table 4Ð16 DMA Write (I/O Read - Memory Write)

Function DACK DREQ# 1 CE2# CE1# A[25::0] OE# WE# IORD# IOWR# D[15::8] D[7::0]
Standby X X H H X X X X X X X
mode
Byte Access H L H L X TC# H L H X BYTE
DATA
(8-bit)
Word H L L L X TC# H L H HIGH LOW
Access BYTE BYTE
1. PC Cards signal DREQ# using one of the following three (3) pins: SPKR#, INPACK# or IOIS16#.
4.8.4 DMA Write Timing (I/O Read - Memory Write)

td DREQ (DACK)
th DREQ (DACK) td DREQ (IORD)
DREQ#
tsu DA(IORD) th DA (IORD)
DACK (REG#)
tsu CE (IORD) th CE (IORD)
CE#
tw (IORD)
IORD#
td (IORD) th (IORD)
D[15::0]
tsu (TC) tw (TC) th (TC)
TC# (OE#)
Figure 4-5 DMA Write Timing Diagram
Table 4Ð17 DMA Write Timing Parameters

Item Symbol IEEE Min Max
DREQ# active to DACK active td DREQ (DACK) 10,000
DREQ# hold from DACK active th DREQ (DACK) 0
DREQ# inactive to IORD# inactive td DREQ (IORD) 0
Data Delay from IORD# active td(IORD) 100
Data hold from IORD# inactive th(IORD) 0
IORD# Width tw(IORD) 165
DACK setup to IORD# active tsu DA (IORD) 5
DACK hold from IORD# inactive th DA (IORD) 5
CE# setup to IORD# active tsu CE (IORD) 5
CE# hold from IORD# inactive th CE (IORD) 20
IORD# active to TC# active tsu (TC) 10
TC# Width tw (TC) 40
TC# inactive to IORD# inactive th (TC) 10
All timing in ns.
4.9 Electrical Interface
4.9.1 Signal Interface

Electrical specifications must be maintained to ensure data reliability.
The 5 V PC Card logic levels shall be per JEDEC 7. The 3.3 V PC Card logic levels shall be per
JEDEC 8-1A. (See Table 4Ð18 PC Card Logic Levels.)
Table 4Ð18 PC Card Logic Levels

DC Levels Host Card
Parameter Conditions Min Max
VIH VCC = 5 V ± 5% 2.4 V VCC + 0.25 V TTL or CMOS
VIL VCC = 5 V ± 5% 0.0 V 0.8 V TTL or CMOS
VCC = 5 V ± 5% 1
VOH 2.8 V (0.9 VCC) VCC TTL or CMOS
VCC = 5 V ± 5% 1
VOL 0.0 V 0.5 V (0.1 VCC) TTL or CMOS
VIH VCC = 3.3 V ± 0.3 V 2.0 V VCC + 0.3 V TTL or CMOS
VIL VCC = 3.3 V ± 0.3 V -0.3 V 0.8 V TTL or CMOS
VCC = 3.3 V ± 0.3 V 1

VOH 2.4 V (VCC - 0.2 V) TTL or CMOS
VCC = 3.3 V ± 0.3 V 1

VOL 0.4 V (0.2 V) TTL or CMOS
Note: All logic levels per JEDEC 7 and 8Ð1A. This table is for reference only.
1. For CMOS loads.
Table 4Ð19 Electrical Interface

Item Signal Card Host Card Output Format
Control Signal CE1# pull-up to VCC R _ 10 KΩ and must
CE2# be sufficient to keep inputs inactive
REG# when the pins are not connected at
IORD# the host. 3
IOWR#
OE# pull-up to VCC R _ 10 KΩ *3
WE#
RESET pull-up to VCC R _ 100 KΩ *3
Status Signal READY pull-up to VCC
INPACK# R _ 10 KΩ 4
WAIT#
WP
Address A[25::0] pull-down R _ 100 KΩ * 5
Data Bus D[15::0] pull-down R _ 100 KΩ * 2
Card Detect CD[2::1]# connected to GND in the card pull-up to VCC
R _ 10 KΩ
Voltage Sense VS1# See Table 4Ð5 Vcc at Initial pull-up to VCC
VS2# Power-Up and CIS Read. 10 KΩ ≤ R ≤ 100 KΩ
Battery/Detect BVD[2::1] pull-up 1 asserted or negated
* Resistor is optional.
1. BVD2 was not defined in the JEIDA 3.0 release. Systems fully supporting JEIDA release 3 SRAM
cards must pull-up pin 62 (BVD2) to avoid sensing their batteries as "Low".
2. Data Signals: The host and each card shall present a load no larger than 50 pF at a DC current 450 µA
low state and 150 µA high state. The host and each card shall be able to drive at least the following load
while meeting all AC timing requirements: 100 pF with DC current 1.6 mA low state and 300 µA high
state. This permits the host to wire two sockets in parallel without derating the card access speeds.
3. Control Signals: Each card shall present a load to the socket no larger than 50 pF at a DC current of 700
µA low state and 150 µA high state, including pull-up resistor. The socket shall be able to drive at least
the following load while meeting all AC timing requirements: (the number of sockets wired in parallel)
multiplied by (50 pF with DC current 700 µA low state and 150 µA high state per socket).
4. Status Signals: The socket shall present a load to the card no larger than 50 pF at a DC current of 400
µA low state and 100 µA high state, including pull-up resistor. The card shall be able to drive at least
the following load while meeting all AC timing requirements: 50 pF at a DC current of 400 µA low state
and 100 µA high state.
5. Address Signals: Each card shall present a load of no more than 100 pF at a DC current of 450A µA low
state and 150 µA high state. The host shall be able to drive at least the following load while meeting all
AC timing requirements: (the number of sockets wired in parallel) multiplied by ( 100 pF with DC
current 450 µA low state and 150 µA high state per socket).
4.9.2 Memory Address Decoding

The 26 address signals at the PC Card connector can directly address only 64 MBytes of memory.
However, a set of Function Configuration Registers (consisting of four 16-bit Address Extension
Registers or the Configuration Option Register) provides the means for an extended PC Card
memory space containing as many as 242 PC Card Common Memory locations.
The PC Card's external address bus is comprised of A[25::0] with A0 being the LSB and A25 the
MSB. Address bit A0 is ignored when the card is asserted in word access mode.
In the case of SRAM without Attribute Memory, address decoding is required as follows:
1. Minimum memory unit is 16 KBytes
2. Memory address starts from 00H
3. Memory units exist continuously.
4.9.2.1 Function Configuration Registers Address Decoding

PC Cards that can be configured by the system, including cards which support I/O and those which
exceed nominal system requirements, contain Function Configuration registers located in the
Attribute Memory space. The Function Configuration registers are a set of numbered, standardized,
8-bit registers. These registers are addressed at consecutive even-byte addresses starting at the Base
Address indicated in the Configuration Tuple. Whether a Function Configuration register number
N is present on the card or not, the location of the register is always given by: Base Address + 2 * N.
(See also 4.14 Function Configuration and 4.15 Card Configuration.)
4.9.3 I/O Address Space Decoding

During I/O operations, the I/O address spaces of each PC Card may be either Independent or
Overlapping. An Independent I/O address window is a portion of the system's I/O space which is
assigned solely to a single PC Card and not shared with any other system resource. Each system
must be able to allocate to each card an independent I/O address window of at least 8 bytes of
contiguous address space. The window must begin exactly on an 8-byte boundary. An Overlapping
I/O address window is a portion of the system's I/O space which is assigned to any combination of
PC Cards and other system resources. When the Overlapping window method is used by the card,
the card responds to only a limited number of the I/O addresses in the window. Also with this
method, the card may permit the system to choose from a selection of addresses to which the card
can respond.
During a card reset, and immediately following a card reset, a card will not respond to any I/O
read or I/O write cycles until it has been configured.
PC Cards which implement I/O functions may use either an Independent or Overlapping Window
or permit selecting between the two methods. The types of I/O address decoding performed by the
card, as well as the specific range of addresses to which the card will respond (in Overlapping I/O
Window mode), are described in the Card Configuration Table located within the Card Information
Structure. To select a particular card configuration, the system writes the index number of one table
entry into the Function Configuration Index field of the Configuration Option register. (See also 4.15
Card Configuration, the Card Services Specification and the Metaformat Specification.)
In order to be able to accommodate cards which require a higher number of I/O ports, such as
LAN, VGA, multi-function cards and game cards, it is recommended that the system reserve 128
contiguous bytes of its I/O space.
4.9.3.1 Independent I/O Address Window

Independent I/O Address windows for PC Cards provide a straightforward mechanism for I/O
space allocation among PC Cards and other system resources installed in the system. The method
can be applied to systems which permit I/O drivers to determine the card's I/O port assignment at
execution time.
For each PC Card socket, the system must reserve a minimum of 8 contiguous bytes of its I/O
address space starting at a Base Address with A0 through A2 all zero.
Note: This should not be interpreted as preventing a system from actually
allocating a smaller or discontiguous space to a particular I/O card whose
I/O space requires such configuration.
The location of the Independent I/O Address Window for each PC Card socket may be fixed
permanently, or may be allocated when an I/O card is detected in the socket. The system must
include a software method permitting driver software (or application software, if I/O is permitted
from applications) to determine a card's I/O space Base Address.
Cards which use the Independent I/O Address Window need decode only enough address lines to
distinguish among the I/O ports actually implemented on the card. When two identical cards are
installed in the system, they automatically reside at different addresses. They rely upon the system
to provide sufficient address decoding to prevent conflicts with other installed devices, and may be
located anywhere in the I/O space of the system.
An example of this concept is used in the EISA bus. Each EISA card slot is uniquely assigned
the first 256 bytes of a corresponding 1 KByte of I/O space.
4.9.3.2 Overlapping I/O Address Window

The Overlapping I/O Address Window is provided for those systems whose I/O drivers have their
I/O addresses bound before execution time. This includes both systems for which execution time
binding is not possible, and those having existing drivers which do not take advantage of execution
time binding of I/O addresses.
The system assigns the same block(s) of its I/O space to each PC Card using the Overlapping I/O
Address Window. Other resources in the system may also use portions of the block. Each card and
system resource is responsible for decoding addresses within the block and responding to I/O only
within a unique subset of those addresses. This mechanism relies on the cards and system resources
having non-overlapping subsets of addresses to which they respond.
When each PC Card is installed in a system that uses an Overlapping I/O Address Window, the
addresses used by the card must be compared with the addresses used by other installed PC Cards,
and the addresses used by other system resources. If the addresses conflict, the new card may be
gracefully rejected by the system.
A PC Card may allow operation at several alternative sets of addresses. The host selects the desired
alternative from the Card Configuration Table and informs the card by writing the configuration
entry of the selected entry to the Function Configuration registers. (See also 4.15 Card
Configuration.)
A desktop personal computer example of Overlapping I/O Address Windows occurs in both
ISA and EISA bus-based computers. In these systems all expansion slots are selected during I/O
accesses to the last 768 bytes of each 1 KByte of I/O space. The expansion cards individually
determine to which addresses within that range they will respond. The specific set of addresses
is often set by configuration switches, or jumpers, on the expansion card. A service technician is
responsible for ensuring, during installation, that no address conflicts will occur.
4.10 Card Detect

PC Cards provide a means of allowing the system to detect card insertion and removal. Signal lines
CD[2::1]# are connected to GND in the card. A pull-up resistor must be connected to CD[2::1]# on
the system side.
Vcc
R ≥ 10K Ω
CD1#
A
Vcc
R ≥ 10K Ω
CD2#
B
Host System PC Card
Figure 4-6 Card Detect
4.11 Battery Voltage Detect

It is critical for the system's data integrity to be able to determine the status of the on-card battery.
The card provides two status signals for this purpose: BVD[2::1]. A Memory card contains one or
two voltage comparators and one or two reference voltages. A Memory card compares the battery
voltage with the reference voltages. Battery status is expressed on 2 digital signal lines, BVD[2::1].
If signal BVD2 is not supported, it is held to VCC through a pull-up resistor on the card.
Table 4Ð20 Battery Voltage Detect

BVD1 BVD2 1 COMMENT
H H Battery Operational
H L Battery needs to be replaced.
L H Battery is not providing operational voltage.
L L Battery is not providing operational voltage.
1 If BVD2 is not supported, BVD2 is held to VCC and only one reference voltage is required.
4.12 Power-up and Power-down
4.12.1 Power-up/Power-down Timing

To retain data in an SRAM Card during power-up or power-down cycles, and to permit peripheral
cards to perform power-up initialization, a timing specification is defined as follows.
Table 4Ð21 Power-up/Power-down Timing

Value
Item Symbol Condition Min Max Unit
Card Enable signal level 1 Vi (CE) 0 V ≤ VCC < 2.0 V 0 ViMAX V
2.0 V ≤ VCC < VIH VCC-0.1 ViMAX
VIH ≤ VCC VIH ViMAX
Card Enable Setup Time tsu (VCC) 20 ms
RESET Setup Time tsu (RESET) 20 ms
Card Enable Recover Time trec (VCC) 0.001 ms

2
VCC Rising Time tpr 10% Ñ> 90% of VCC 0.1 100 ms
2
VCC Falling Time tpf 90% of VCC Ñ> 10% 3.0 300 ms
RESET Width tw (RESET) 10 us
th (Hi-z RESET) 1 ms
ts (Hi-z RESET) 0 ms
Off time when changing VCC toff 100 ms

level
Off level when changing VCC Voff 0.8 V
level
1. ViMAX means Absolute Maximum Voltage for Input in the period of 0 V ≤ VCC < 2.0 V, Vi (CE) is only 0
V ~ ViMAX
2. The tpr and tpf are defined as "linear waveform" in the period of 10% to 90% or vice-versa, Even if the
wave form is not "linear waveform", its rising and falling time must be meet this specification.
Peak current at start-up (in-rush current) is determined by ramp time and card capacitance. Since
peak current is host platform design specific, the design can be optimized within the range defined
in Table 4Ð21 Power-up/Power-down Timing for the capability of the platform. Host platforms that
support the full range of PC Cards shall assume a 150 µF maximum capacitance before host access
(see Section 4.12.2 Average Current During Card Configuration).
tsu (Vcc)
Vcc
tpr
Vcc @ 90%
tsu (RESET) tsu (RESET)
VIH
2V
Vcc@10%
CE1#, CE2#
th (Hi-z RESET) tw (RESET)
Hi-z
RESET
tw(RESET)
Vcc tpf
Vcc@90%
trec (Vcc)
VIH
2V
Vcc@10%
CE1#, CE2#
ts (Hi-z RESET)
RESET Hi-z
Figure 4-7 Power-Up/Down Timing
Vcc tpf
Vcc@90%
tpr
Vcc@90%
Voff
Vcc@10%
GND
toff
Figure 4-8: Power-Down/Power-Up Timing When Changing Vcc
4.12.2 Average Current During Card Configuration

A host has no method for determining the current a PC Card will draw before powering up the
card. Therefore, regardless of the current draw required by a card to operate, a card shall not draw
more than 70 mA average current at 3.3 V VCC or 100 mA average current at 5 V VCC. (See
average current in the Overview and Glossary and see also 4.15 Card Configuration.)
When the host system asserts RESET other than at power-up, via either the RESET line or the
SRESET bit in the Configuration Option register of a single function card, a card shall return to the
power-up state. Each individual function of a Multiple Function PC Card shall return to power-up
state when the host system asserts the SRESET bit in the functionÕs Configuration Option register. If
the card requires more than this initial average current to operate, the card shall not draw its
required operational current until after the Configuration Option register has been written by the
host system or the first access by the host system requiring operational current occurs.
4.12.3 Data Retention

This specification does not guarantee data retention in memory cards that conform to it. The
conditions in the preceding tables indicate the minimum requirements to ensure data retention. PC
Card and system vendors may have to negotiate with each other to determine the detailed method
of guaranteeing data retention for specific memory card models.
4.12.4 Supplement
During card insertion or removal, with power active, the PC Card data retention capability will
depend on the individual memory card model, the manufacturer's environmental specifications,
and other conditions. Therefore, data retention during card insertion or removal when under power
is implementation dependent.
To prevent the situation wherein the PC Card is inadvertently powered while the socket power is
OFF, the following requirements shall be fulfilled:
1. When a socketÕs VCC power is switched OFF while a card is in the socket, all socket to card
signals for that socket shall be less than the voltage presented on the VCC pins on the socket
plus +0.3 V at all times.
2. All pull-up resisters on the socket signals except VS[2::1]#, and CD[2::1]# shall be connected to
switched VCC and shall not be active when the socket is powered OFF.
3. The PC Card shall not drive any signals from any other, non-VCC, voltage source (e.g. backup
battery) when the PC Card is powered OFF. (This is a concern primarily in the case of
BVD[2::1] signals tied directly to an SRAM backup battery.)
4.13 I/O Function

This section describes the operation and configuration of I/O cards inserted into a PC Card socket.
4.13.1 I/O Transfer Function

This section describes the operation of I/O transfer cycles (Input and Output Instructions) on I/O
cards.
4.13.2 I/O Input Function for I/O Cards

I/O input transfers from I/O cards may be either 8-bit or 16-bit.
When a 16-bit transfer is attempted from a 16-bit port, the signal IOIS16# must be asserted by the
I/O card. Otherwise, the IOIS16# signal must be negated. When a 16-bit transfer is attempted, and
the IOIS16# signal is not asserted by the card, the system generates a pair of 8-bit references to
access the word's even byte and odd byte.
An I/O card may extend the length of an input cycle by asserting the WAIT# signal at the start of
the cycle.
Table 4Ð22 I/O Input Function for All Cards

Function Mode REG# CE2# CE1# A0 IORD# IOWR# D[15::8] D[7::0]
Standby Mode X H H X X X High-Z High-Z
Byte Input (8 bits) L H L L L H High-Z Even-Byte
L H L H L H High-Z Odd-Byte
Word Access (16 bits) L L L L L H Odd-Byte Even-Byte
I/O Inhibit H X X X L H High-Z High-Z
(e.g. during DMA)
High Byte Only L L H X L H Odd-Byte High-Z
Note: The VPP[2::1] signals to the I/O card are not required to be other than VCC specifically for input
transfers. However, they may be required to be at other voltage levels for proper card operation as
indicated in the Card Information Structure. If the required voltage levels on VPP[2::1] cannot be
provided by the system, the card may be gracefully rejected.
4.13.3 I/O Output Function for I/O Cards

I/O output transfers to I/O cards may be either 8-bit or 16-bit.
When a 16-bit transfer is attempted to a 16-bit port, the signal IOIS16# must be asserted by the I/O
Card. Otherwise, the IOIS16# signal must be negated. When a 16-bit transfer is attempted, and the
IOIS16# signal is not asserted by the card, the system generates a pair of 8-bit references to access
the word's even byte and odd byte.
An I/O card may extend the length of an output cycle by asserting the WAIT# signal at the start of
the cycle.
Table 4Ð23 I/O Output Function for I/O Cards

Function Mode REG# CE2# CE1# A0 IORD# IOWR# D[15::8] D[7::0]
Standby Mode X H H X X X X X
Byte Output (8 bits) L H L L H L X Even-Byte
L H L H H L X Odd-Byte
Word Access (16 bits) L L L L H L Odd-Byte Even-Byte
I/O Inhibit (e.g. during DMA) H X X X H L X X
High Byte Only L L H X H L Odd-Byte X
Note: The VPP[2::1] signals to the I/O card are not required to be other than VCC specifically for output
transfers. However, they may be required to be at other voltage levels for proper card operation as
indicated in the Card Information Structure. If the required voltage levels on VPP[2::1] cannot be
provided by the system, the card may be gracefully rejected.
4.13.4 I/O Read (Input) Timing Specification
A[25::0]
th A (IORD)
REG# tsu REG (IORD) th REG (IORD)
tsu CE (IORD)
CE# th CE(IORD)
tw (IORD)
IORD#
tsu A (IORD)
tdr INPACK(ADR)
INPACK#
tdf INPACK (IORD)

tdr IOIS16(ADR)
IOIS16#
tdf IOIS16 (ADR) td (IORD)
tdr(WT)
WAIT#
tdf WT (IORD) tw (WT) th (IORD)
D[15::0]
All timings are measured at the PC Card.

Skews and delays from the host system driver/receiver to the PC Card must be accounted for by the
system design.
Minimum time for WAIT# negated to IORD# negated is 0 ns, but minimum IORD# width must still be
met.
D[15::0] signifies data provided by the PC Card to the host system.
Figure 4-9 I/O Read Timing
Table 4Ð24 I/O Read(Input) Timing Specification for All I/O Cards
Item Symbol IEEE Symbol Min Max
Data Delay after IORD# td (IORD) t IGLQV 100
Data Hold following IORD# th (IORD) t IGHQX 0
IORD# Width Time tw IORD t IGLIGH 165
Address Setup before IORD# tsu A (IORD) t AVIGL 70
Address Hold following IORD# th A (IORD) t IGHAX 20
CE# Setup before IORD# tsu CE (IORD) t ELIGL 5
CE# Hold following IORD# th CE (IORD) t IGHEH 20
REG# Setup before IORD# tsu REG (IORD) t RGLIGL 5
REG# Hold following IORD# th REG (IORD) t IGHRGH 0
INPACK# Delay Falling from IORD# tdf INPACK (IORD) t IGLIAL 0 45
INPACK# Delay Rising from IORD# tdr INPACK (IORD) t IGHIAH 45
IOIS16# Delay Falling from Address tdf IOIS16 (ADR) t AVISL 35
IOIS16# Delay Rising from Address tdr IOIS16 (ADR) t AVISH 35
WAIT# Delay Falling from IORD# tdfWT (IORD) t IGLWTL 35
Data Delay from WAIT# Rising tdr(WT) t WTHQV 0
WAIT# Width Time tw (WT) t WTLWTH 12,000
All timing in ns.

The maximum load on WAIT#, INPACK# and IOIS16# are 1 LSTTL with 50 pF total load.
4.13.5 I/O Write (Output) Timing Specification
A[25::0]
th A (IOWR)
tsu REG (IOWR)

REG# th REG (IOWR)
tsu CE (IOWR)
CE# th CE(IOWR)
tw (IOWR)
IOWR#
tsu A (IOWR)
tdr IOIS16(ADR)
IOIS16#
tdf IOIS16 (ADR)
tdf WT (IOWR) tdr IOWR (WT)
WAIT#
tw (WT) th (IOWR)
D[15::0]
tsu (IOWR)
All timings are measured at the PC Card.

Skews and delays from the host system driver/receiver to the PC Card must be accounted for by the
system design.
Minimum time for WAIT# negated to IORD# negated is 0 ns, but minimum IOWR# timing must still be
met.
D[15::0] signifies data provided by the host system to the PC Card.
Figure 4-10 I/O Write Timing
Table 4Ð25 I/O Write(Output) Timing Specification for All I/O Cards
Item Symbol IEEE Symbol Min Max
Data Setup before IOWR# tsu (IOWR) t DVIWL 60
Data Hold following IOWR# th (IOWR) t IWHDX 30
IOWR# Width Time tw IOWR t IWLIWH 165
Address Setup before IOWR# tsu A (IOWR) t AVIWL 70
Address Hold following IOWR# th A (IOWR) t IWHAX 20
CE# Setup before IOWR# tsu CE (IOWR) t ELIWL 5
CE# Hold following IOWR# th CE (IOWR) t IWHEH 20
REG# Setup before IOWR# tsu REG (IOWR) t RGLIWL 5
REG# Hold following IOWR# th REG (IOWR) t IWHRGH 0
IOIS16# Delay Falling from Address tdf IOIS16 (ADR) t AVISL 35
IOIS16# Delay Rising from Address tdr IOIS16 (ADR) t AVISH 35
WAIT# Delay Falling from IOWR# tdf WT (IOWR) t IWLWTL 35
WAIT# Width Time tw (WT) t WTLWTH 12,000
IOWR# high from WAIT# High tdr IOWR (WT) t WTHIWH 0
All timing in ns.

The maximum load on WAIT#, INPACK# and IOIS16# are 1 LSTTL with 50 pF total load.
4.14 Function Configuration
4.14.1 Overview
The characteristics of some 16-bit PC Cards are configurable. Such PC Cards use Function
Configuration registers to control their characteristics and return status. All Function Configuration
registers shall be read/write and one byte wide. All such registers shall be located on even byte
addresses to ensure single cycle access by both eight (8) and sixteen (16) bit host systems.
4.14.2 Single Function PC Cards

Single Function PC Cards shall have a single configuration tuple describing a single set of Function
Configuration registers. (See the Metaformat Specification.) All PC Card configuration shall be
performed using this set of Function Configuration registers.
4.14.3 Multiple Function PC Cards

Multiple Function PC Cards shall have a separate set of Configuration registers for each function on
the card. Multiple Function PC Cards shall use a combination of a global CIS common to all
functions on the card and a separate function-specific CIS specific to each function on the card. The
global CIS describes features that are common to all functions on the card. Each function-specific CIS
describes features specific to a particular function on the PC Card. A CISTPL_LONGLINK_MFC
tuple in the global CIS describes the location of a function-specific CIS for each function on the PC
Card. (See the Metaformat Specification.)
Note: A CISTPL_FUNCID with a TPLFID_FUNCTION field reset to zero (0) shall

not be placed in the CIS of a Multiple Function PC Card. This tuple is
reserved for vendor-specific multiple function PC Cards that do not follow
the multiple function PC Card definitions in the Standard.
4.14.4 Function Configuration Registers (FCRs)

This section describes a PC Card's Function Configuration registers. These registers allow the host to
configure the function(s) provided by a PC Card. Configurable PC Cards shall implement a
Configuration Option register for each function on the card. Memory cards with more than 64
Mbytes of memory must implement either the Configuration Option register or a number of
Address Extension Registers, with the exact register(s) denoted by the configuration information
provided by the CISTPL_EXTDEVICE tuple (described in the Metaformat Specification). All other
Function Configuration registers are optional.
Table 4Ð26 Function Configuration Registers

Offset 7 6 5 4 3 2 1 0
0 Configuration Option Register
SRESET LevIREQ Function Configuration Index / Common Memory Address Extension
2 Configuration and Status Register
Changed SigChg IOIs8 RFU Audio PwrDwn Intr IntrAck
4 Pin Replacement Register
CBVD1 CBVD2 CREADY CWProt RBVD1 RBVD2 RREADY RWProt
6 Socket and Copy Register
RFU Copy Number Socket Number
8 Extended Status Register
Event3 Event2 Event1 Req Attn Enable3 Enable2 Enable1 Req Attn
Enable
10 I/O Base 0
12 I/O Base 1
14 I/O Base 2
16 I/O Base 3
18 I/O Limit
20 Power Management Support Register
RFU(0) RFU(0) RFU(0) RFU(0) State Begin/Done Save/ Stored State
Restored State Restore Exists
Operation State
22 Address Extension Register 0 Low

24 Address Extension Register 0 High
4.15 Card Configuration

Each configurable PC Card is identified by a Card Configuration Table in the card's Card
Information Structure. These cards must have one or more of a set of Function Configuration
registers which are used to control the configurable characteristics of the card. The configurable
characteristics include the electrical interface, I/O address space, interrupt request, and power
requirements of the card.
All of the Function Configuration registers shall be both readable and writable. The registers are
each one byte in size and located only on even-byte addresses to ensure their single cycle access by
both 8-bit and 16-bit systems.
These registers also provide a method for accessing some status information about a card. The
information may be used to arbitrate between multiple-interrupt sources on the same interrupt
request level. It may also be used to access status information which appears on pins 16, 33, 62 and
63 (READY, WP, and BVD[2::1]) in Memory Only cards.
At every moment, the effect of a particular combination of configuration values shall be dependent
only on the current values in the registers. Card function configuration shall be independent of the
manner in which the values were loaded into the registers.
With the exception of the transient states occurring during a socket/card configuration and the
potential initialization of a Socket and Copy register, the order of initializing the registers is not
restricted. (See 4.15.4 Socket and Copy Register.) Cards shall respond appropriately regardless of
the order in which their registers have been initialized.
Regardless of the current draw required by a card to operate, a card shall not draw more than 70
mA average current at 3.3 V VCC or 100 mA average current at 5 V VCC after being initially
powered-up. (See average current in the Overview and Glossary and see also 4.12.2 Average
Current During Card Configuration.) While in this Power-up state, the card shall allow CIS to be
read and Configuration registers to be accessed. If the card requires more than this initial average
current to operate, the card shall not draw its required operational current until after the
Configuration Option register has been written by the host or the first access to other than CIS or
Configuration registers by the host requiring operational current occurs.
Table 4Ð27 Card Memory Spaces

CE1# REG# OE# WE# Address Offset A0 Selected Register or Space
H X X X X X Standby
L H L H X X Common Memory Read
L H H L X X Common Memory Write
L L L H X L CIS or Configuration Register Read
L L H L X L CIS or Configuration Register Write
L L X X X H Invalid Access
Table 4Ð28 Function Configuration Registers

CE1# REG# OE# WE# Address Offset 1 A0 Selected Register Register
Num
L L L H NNNN0H L Configuration Option Register Read 0
L L H L NNNN0H L Configuration Option Register Write 0
L L L H NNNN2H L Configuration and Status Register Read 1
L L H L NNNN2H L Configuration and Status Register Write 1
L L L H NNNN4H L Pin Replacement Register Read 2
L L H L NNNN4H L Pin Replacement Register Write 2
L L L H NNNN6H L Socket and Copy Register Read 3
L L H L NNNN6H L Socket and Copy Register Write 3
L L L H NNNN8H L Extended Status Register Read 4
L L H L NNNN8H L Extended Status Register Write 4
L L L H NNNN0H + 14H L Power Management Register Read 10
L L H L NNNN0H + 14H L Power Management Register Write 10
L L L H NNNN0H + 16H L Address Extension Register 0 Low Read 11
L L H L NNNN0H + 16H L Address Extension Register 0 Low Write 11
L L L H NNNN0H + 18H L Address Extension Register 0 High Read 12
L L H L NNNN0H + 18H L Address Extension Register 0 High Write 12
L L L H NNNN0H + 1AH L Address Extension Register 1 Low Read 13
L L H L NNNN0H + 1AH L Address Extension Register 1 Low Write 13
L L L H NNNN0H + 1CH L Address Extension Register 1 High Read 14
L L H L NNNN0H + 1CH L Address Extension Register 1 High Write 14
L L L H NNNN0H + 1EH L Address Extension Register 2 Low Read 15
L L H L NNNN0H + 1EH L Address Extension Register 2 Low Write 15
L L L H NNNN0H + 22H L Address Extension Register 3 Low Read 17
L L H L NNNN0H + 22H L Address Extension Register 3 Low Write 17
1. NNNN0H is the Configuration registers Base Address specified in the TPCC_RADR field of the
Configuration Tuple. (See the Metaformat Specification.)
4.15.1 Configuration Option Register

The Configuration Option register is used to configure the card, provide an address extension to
select a 64 MByte page of Common Memory, and to issue a soft reset to the card. The register is a
read/write register which contains three fields. The Configuration Option register must be
implemented in all configurable cards.
The Configuration Option register is required on PC Cards using the I/O interface and is optional
on PC Cards using the memory interface. The register configures a function on a PC Card and may
be used to issue a soft reset to the function or set the interrupt mode (Level or Pulse) used by the
function.
For memory PC Cards where it is not necessary to configure a function on the PC Card, the
Configuration Option registerÕs Common Memory Address Extension field can serve to provide six
address extension bits. The six address extension bits when combined with the PC Cards 26 address
signals (A[25::0]), would allow for the addressing of as much as 4 Gigabytes of Common Memory
for PC Cards employing a 64 MByte paging architecture. The CORÕs Common Memory Address
Extension field would select the various 64 MByte pages while the A[25::0] signals would select a
specific memory location within a selected page.
The Configuration Option register is organized as follows:
Table 4Ð29 Configuration Option Register

D7 D6 D5 D4 D3 D2 D1 D0
SRESET LevIREQ Function Configuration Index / Common Memory Address Extension
Field Type Description

SRESET R/W If the host sets this field to one (1), the PC Card shall place the function in reset state. This is
equivalent to the host asserting RESET, except this field is not reset to zero (0) as it is when the host
asserts RESET. When the host returns this field to zero (0), the function shall enter the same
unconfigured, reset state as the card does following a power-up and hardware reset.
LevIREQ R/W If a PC card is using the I/O interface and this field is set to one (1), the PC Card shall generate Level
Mode interrupts.
If a PC card is using the I/O interface and this field is set to zero (0), the PC Card shall generate Pulse
Mode interrupts, if they are supported by the card. A PC Card indicates it supports Pulse Mode
interrupts in the Interrupt Request Description Structure of a Function Configuration Table Entry Tuple.
If a PC Card has multiple I/O functions, all functions using interrupts on the PC Card shall use the
same interrupt mode. This must be enforced by host software.
If a PC Card is not using the I/O interface, this field is undefined.
Function R/W When the host system sets this field to the value of the Configuration Entry Number field of a
Configuration Configuration Table Entry Tuple the function shall enter the configuration described by that tuple. This
Index field shall be reset to zero (0) by the PC Card when the host sets the SRESET field to one (1) or the
host asserts RESET.
If this field is set to zero (0) explicitly by the host or implicitly by SRESET or RESET, the PC Card
shall use the Memory Only interface and I/O cycles from the host shall be ignored by the card.
When a PC Card configuration requires an interface other than memory (including Custom
Interfaces), the socket controller must be programmed for that interface before the Configuration
Option Register is set. The Card Information Structure (CIS) must be readable as specified in the
Metaformat Specification no matter what interface is in use.
On multiple function PC Cards, bits in this field enable the following functionality:
Bit 0 Enable Function - If this bit is reset to zero (0), the function is disabled. If this bit is set to one
(1), the function is enabled.
Bit 1 Enable Base and Limit Registers - If this bit is reset to zero (0) and Bit 0 is set to one (1), all
I/O addresses on the host system are passed to the function. If this is set to one (1) and Bit 0
is set to one (1), only I/O addresses that are qualified by the Base and Limit registers are
passed to the function. If Bit 0 is reset to zero (0), this bit is undefined.
Bit 2 Enable IREQ# routing - If this bit is reset to zero (0) and Bit 0 is set to one (1), this function
shall not generate interrupt requests on the PC Card's IREQ# line. If this is set to one (1) and
Bit 0 is set to one (1), this function shall generate interrupt requests on the PC Card's IREQ#
line. If Bit 0 is reset to zero (0), this bit is undefined.
Bit 3 .. 5 are reserved for vendor implementation.
Common Memory R/W For a memory card with > 64 MBytes of Common Memory and using 64 MByte paging this field can
Address Extension be used to provide six address extension bits which select a 64 MByte page within a Common
Memory space as large as 4 Gigabytes. The selection of the Common Memory Address Extension
field option for use with 64 MByte paging as well as the exact size of Common Memory is specified by
the CISTPL_EXTDEVICE tuple.
The timing of the Soft Reset must meet the same constraints as the timing of hardware reset. To
clear the Soft Reset Bit (1->0) in the Configuration Option register, the host shall write a 00H to the
register. This procedure ensures that the proper final result will occur in the register regardless of
whether the card treats the write as occurring during the reset (and clears bits 6-0 regardless of the
values written) or treats the write as occurring at the end of the reset (and allows bits 6-0 to be set
according to the values written).
After clearing the Soft Reset bit, the host shall follow the same protocol as is used for hardware reset.
The host must observe the Ready condition of the READY signal before proceeding in the
re-initialization of the card. After the Socket and Copy register has been written, the host can write
the Configuration Option register with the desired configuration value.
4.15.2 Configuration and Status Register

The Configuration and Status register is an optional register. If present, the register allows
additional control over a function's configuration and reports status related to the function's
configuration.
Table 4Ð30 Configuration and Status Register

D7 D6 D5 D4 D3 D2 D1 D0
Changed SigChg IOIs8 RFU Audio PwrDwn Intr IntrAck

Changed R/O If a PC Card is using the I/O interface, the function's Pin Replacement register is present and one or
more of the state change signals in the Pin Replacement register are set to one (1), or one Event bits
in the Extended Status register are set (1) and the corresponding Enable bit is set (1), the function shall
set this field to one (1).
If a PC Card is not using the I/O interface or the function's Pin Replacement register is not present,
this field is undefined and should be ignored.
SigChg R/W This field serves as a gate for STSCHG#.
If a PC Card is using the I/O interface and both the Changed and SigChg fields are set to one (1), the
function shall assert STSCHG#.
If a PC Card is using the I/O interface and this field is reset to zero (0), the function shall not assert
STSCHG#.
If a PC Card is not using the I/O interface or the function's Pin Replacement register is not present,
this field is undefined and should be ignored.
IOIs8 R/W The host sets this field to one (1) when it can provide I/O cycles only with an 8-bit D[7::0] data path.
The card is guaranteed that accesses to 16-bit registers will occur as two byte accesses rather than
as a single 16-bit access.
RFU Reserved. Must be zero (0).
Audio R/W This bit is set to one (1) to enable audio information on SPKR# when the card is configured.
PwrDwn R/W When the host sets this field to one (1), the function shall enter a power-down state, if such a state
exists.
While this field is one (1), the host shall not access the function. The host shall return this field to zero
(0) before attempting to access the function.
The host shall set this field only if the PC Card is indicating it is ready.
If a PC Card function does not have a power-down state, the function shall ignore this field.
Intr R/O Interrupt Request/Acknowledge - This field reports whether the function is requesting interrupt
servicing and may be used to acknowledge the host system is ready to process another interrupt
or
request from the PC Card.
R/W
The function shall set this field to one (1) when it is requesting interrupt service. The function shall set
this field to zero (0) when it is not requesting interrupt service.
Writes to this field are ignored when the IntrAck field of all Configuration and Status Registers on the
PC Card are reset to zero (0).
If the host system writes a zero (0) to this field in any Configuration and Status Register on the PC
Card when the IntrAck field of any Configuration and Status Register is set to one (1) and any function
on the PC Card is requesting interrupt servicing, the PC Card must create an additional interrupt
notification to the host system.
IntrAck R/W Interrupt Acknowledge - This field changes the response characteristics of the Intr field on Multiple
Function PC Cards that have multiple sets of configuration registers. This field is used to enable a
hardware/software protocol that permits the PC CardÕs IREQ# signal to be shared by multiple
functions on the card. Single function PC Cards ignore this field on writes and always return zero (0).
If the IntrAck field of every Configuration and Status Register on a Multiple Function PC Card is reset
to zero (0), writes to the Intr field are ignored.
If the IntrAck field of any Configuration and Status Register on a Multiple Function PC Card is set to
one (1):
• the host system must acknowledge it is ready to receive additional interrupts from the PC Card
by writing a zero (0) to the Intr field of any Configuration and Status Register after the host
system has completed an entire interrupt processing cycle.
• the PC Card must create an additional interrupt notification to the host system when the host
system writes a zero (0) to the Intr field in any Configuration and Status Register on the PC Card
and any function on the PC Card enabled for interrupt reporting and sharing is requesting
interrupt service.
Host software must insure the IntrAck field is set to one (1) for all functions sharing the PC CardÕs
IREQ# signal using the above described protocol.
The Configuration and Status register must be implemented if the card generates audio, shares
interrupts or requires other status information available in the register.
4.15.3 Pin Replacement Register

The Pin Replacement register is used to provide the card status information which was provided on
pins 16, 33, 62 and 63 in the Memory Only interface.
The register may be read and written, however, when written the lower 4 bits act as mask bits for
changing the corresponding bit of the upper 4 bits.
The upper 4 bits are set when the corresponding bit in the lower 4 bits changes state.
Table 4Ð31 Pin Replacement Register

D7 D6 D5 D4 D3 D2 D1 D0
CBVD1 CBVD2 CREADY CWProt RBVD1 RBVD2 RREADY RWProt
Field Description
CBVD1 This bit is set (1) when the corresponding bit, RBVD1, changes state. This bit may also be written by the host.
CBVD2 This bit is set (1) when the corresponding bit, RBVD2, changes state. This bit may also be written by the host.
CREADY This bit is set to one when the bit RREADY changes state. This bit may also be written by the host.
CWProt This bit is set to one when the bit RWProt changes state. This bit may also be written by the host.
RBVD1 When read, this bit represents the internal state of the Battery Voltage Detect circuits which would be on the
BVD1 pin.
When this bit is written as 1 the corresponding CBVD1 bit is also written. When this bit is written as 0, the
CBVD1 bit is unaffected.
RBVD2 When read, this bit represents the internal state of the Battery Voltage Detect circuits which would be on the
BVD2 pin.
When this bit is written as 1 the corresponding CBVD2 bit is also written. When this bit is written as 0, the
CBVD2 bit is unaffected.
RREADY When read, this bit represents the internal state of the READY signal. This bit may be used to determine the state
of READY as that pin has been reallocated for use as Interrupt Request on IO Cards.
When this bit is written as 1 the corresponding "changed" bit is also written. When this bit is written as 0, the
corresponding changed bit is unaffected.
RWProt This bit represents the state of the WP signal. This signal may be used to determine the state of the Write Protect
switch when pin 33 is being used for IOIS16#.
When this bit is written as 1 the corresponding "changed" bit is also written. When this bit is written as 0, the
corresponding changed bit is unaffected.
The Pin Replacement register must be implemented if the card needs to provide information about
READY, WP or the BVD[2::1] status when implementing the I/O interface.
4.15.4 Socket and Copy Register

This is an optional read/write register which the PC Card may use to distinguish between similar
cards installed in a system. This register, if present, is always written by the system before writing
the card's Function Configuration Index field in the Configuration Option register.
Table 4Ð32 Socket and Copy Register Organization

D7 D6 D5 D4 D3 D2 D1 D0
Reserved Copy Number Socket Number
Field Description
Reserved This bit is reserved for future standardization. This bit must be set to zero (0) by software when the register is
written.
Copy Number PC Cards which indicate in their CIS that they support more than one copy of identically configured cards, should
have a copy number (0 to MAX twin cards, MAX = n-1) written back to the Socket and Copy register.
This field indicates to the card that it is the n'th copy of the card installed in the system which is identically
configured. The first card installed receives the value 0. This permits identical cards designed to do so to share a
common set of I/O ports while remaining uniquely identifiable. and consecutively ordered.
Socket Number This field indicates to the PC Card that it is located in the n'th socket. The first socket is numbered 0. This
permits any cards designed to do so to share a common set of I/O ports while remaining uniquely identifiable.
4.15.5 Extended Status Register

This is an optional register that will be located at offset 08H. The register will contain information
about the changes in the cards status. The Extended Status register bit assignments are defined
below:
Table 4Ð33 Extended Status Register Organization

D7 D6 D5 D4 D3 D2 D1 D0
Event3 Event2 Event1 Req Attn Enable3 Enable2 Enable1 Req Attn
Enable
Field Description
Event3 Reserved for future expansion/definition, must be reset (0)
Event2 Reserved for future expansion/definition, must be reset (0)
Event 1 Reserved for future expansion/definition, must be reset (0)
Req Attn This bit is latched within one(1) ms of an event occurring on the PC Card, (such as the start of each cycle of the
ring frequency to indicate the presence of ringing on the phone line in the case of a modem card). When this bit is
set to a one (1), and the Req Attn Enable bit is set to a one (1), the Changed bit in the Configuration and Status
register will also be set to a one (1), and if the SigChg bit in the Configuration and Status register has also been
set by the host, then the STSCHG# pin (63) will be asserted. The host writing a one (1) to this bit will reset it to
zero (0). Writing a zero (0) to this bit will not have any effect.
Enable3 Reserved for future expansion/definition, must be reset (0)
Req Attn Enable Setting this bit to a one (1) enables the setting of the Changed bit in the Configuration and Status register when the
Req Attn bit is set. When this bit is reset to a zero (0), this feature is disabled. The state of the Req Attn bit is not
affected by the Req Attn Enable bit.
The register may be read or written. The upper 4 bits are latched to a one (1) when the
corresponding event occurs on the PC Card (for example in the case of the Req Attn bit, when
ringing occurs on the phone line on a modem card). When one of these upper four bits is latched
and the corresponding enable bit in the lower nibble is also set, the Changed bit in the
Configuration and Status register will be set, and if the SigChg bit in the Configuration and Status
register is also set, (and the card is configured for I/O mode) then the STSCHG# pin (63) will be
asserted. The host writing a one (1) to one of the upper 4 bits will clear that bit. Writing a zero to
one of the upper 4 bits will have no effect. The lower four bits will return their current state when
they are read. All bits of this register are cleared to zero (0) at power-up(VCC), by RESET or
SRESET.
Setting one of the lower 4 bits enables the corresponding upper bit to be OR'ed into the Changed bit
in the Configuration and Status register. When these lower bits are cleared, the setting of the
Changed bit is disabled for the corresponding event. The state of the upper bits is not affected by the
value written to the lower bits.
The host will determine the presence of this register by reading the TPCC_RMSK Configuration
register Presence Mask of the Card Configuration Tuple. (See the Metaformat Specification.)
4.15.6 I/O Base Registers (0 .. 3)

The I/O Base registers are optional on single function PC Cards. They are required on multiple
function PC Cards. The I/O Base registers determine the base address of the I/O range used to
access function specific registers on the PC Card. These registers allow the PC Card's function
specific registers to be placed anywhere in the host system's I/O address space. The registers are
written in little-endian order with the least significant byte of the base I/O address written to I/O
Base 0.
The number of I/O Base Address registers implemented depends on the number of address lines
the PC Card decodes. For example, if the function on the PC Card only decodes sixteen (16) address
lines, only the first two registers need to be implemented.
Table 4Ð34 I/O Base Registers

Offset D7 D6 D5 D4 D3 D2 D1 D0
10 I/O Base 0
12 I/O Base 1
14 I/O Base 2
16 I/O Base 3

I/O Base (0 .. 3) R/W Base I/O address used by function on PC Card.
4.15.7 I/O Limit Register

The I/O Limit register is an optional register. It is only implemented on PC Cards that use I/O Base
Address registers. If the function on the PC Card always uses the same number of I/O registers in
all configurations, this register may be omitted (even on PC Cards with I/O Base Address registers).
This register specifies the number of address lines used by the function. Each bit in the register
represents an I/O address line. This allows two (2) to two hundred and fifty-six (256) I/O ports to be
used by a function. If a bit in the register is set to one (1), all bits of lesser significance in the register
must also be set to one (1).
Table 4Ð35 I/O Limit Register

18 I/O Limit

I/O Limit R/W Bit-mapped register indicating the number of I/O address lines decoded by the function on the PC
Card.
4.15.8 Power Management Support Register

The Power Management Support Register is used in conjunction with the CISTPL_PWR_MGMNT
tuple (see the Metaformat Specification) by host software to preserve the state of a PC Card function
when power is removed from a socket and then later power is restored. Before socket power is
removed, the host commands the PC Card function to perform a save state operation by first setting
the Save/Restore state field to one (1) and the Begin/Done State Operation field to one (1). The host shall
allow the PC Card function up to the period of time indicated by the PWR_TIME field in the
CISTPL_PWR_MGMNT tuple to complete the save state operation before power is removed from the
socket. The PC Card function indicates the operation is complete by clearing the Begin/Done State
Operation field to zero (0). After socket power is restored, the PC Card function restores a saved state
within the period of time indicated by the PWR_TIME field in the CISTPL_PWR_MGMNT tuple
when the host clears the Save/Restore state field to zero (0) and sets the Begin/Done State Operation
field to one (1).
Field Description
Stored State Exists When set, indicates the PC Card function has preserved a state within the card that can be restored.
This field is cleared to zero (0) by the PC Card function when the saved state is restored or the function is
configured.
Save/Restore When commanded by the host to begin a Save/Restore State operation, this field instructs the function to save
State state if set to one (1) or restore state if cleared to zero (0).
Begin/Done State When set to one (1) by the host, this field commands the function to begin a save or restore state operation. Upon
Operation completing the save or restore state operation and the function is ready for operation, this field is cleared to zero
(0) by the PC Card function.
If the PC Card function has not completed itÕs part of the operation within its specified save/restore time and
indicated successful completion by clearing this field, the host shall assume the operation has failed.
State Restored This field is set to one (1) by the PC Card function when a restore state operation is successfully completed.
This field is cleared to zero (0) by the PC Card function when a state is saved or the function is configured.
RFU(0) Reserved, cleared to zero

There are two methods of PC Card function state preservation defined: one method stores state
information within the card, the other relies on the host to store the functionÕs state information.
In the first method (when the CISTPL_PWR_MGMNT tuple PWR_METHOD field is 80H), the PC
Card function stores state information on the card and indicates that the function has stored a valid
state by setting the Stored State Exists field to one (1). The host responsibility is limited to indicating
when to save state and when to restore state. Whenever the PC Card function is configured by the
host or a saved configuration state is restored, the function shall clear the Stored State Exists field to
zero (0).
In the second method (when the CISTPL_PWR_MGMNT tuple PWR_METHOD field is 00H or 01H)
the PC Card function outputs state information to a buffer area on the card during a save state
operation and restores state information from the buffer area during a restore state operation. The
host is responsible for storing the contents of the buffer after the PC Card function indicates the save
state operation is complete and before the card is powered down. After re-powering the PC Card
and before starting the functionÕs restore state operation, the host reloads the saved buffer contents
into the buffer area.
For either method, the PC Card is responsible for restoring the state of the functionÕs internals
including the state of the functionÕs Configuration Registers. In a restore sequence, the hostÕs
responsibilities are to restore the state of the socket, verify that the PC Card in the socket has not
been removed from the socket since state was saved, reload the functionÕs state buffer (only when a
buffer method is used), and command the PC Card function to restore its state. When a restore state
operation is successfully completed the PC Card function shall set the State Restored field to one (1).
The last two host steps, reload the PC Card functionÕs state buffer and command the function to
restore its state, are repeated for each function on a Multiple Function PC Card.
The PC Card function shall save state when commanded to do so by the host regardless of having
previously saved state.
4.15.9 Address Extension Registers

This optional set of Function Configuration Registers provides a means for a system to access more
than 64 MBytes of Common Memory space on a PC Card. The 26 address signals at the PC Card
connector can directly address only 64 MBytes of memory. The Address Extension Registers provide
an address extension which allows the host system to address locations within an extended PC Card
memory space containing as many as 242 PC Card Common Memory locations with 8-bit registers.
(Additionally, as described in Section 4.15.1 Configuration Option Register, the Configuration
Option Register may be used to provide 6 address extension bits as an alternative to the Address
Extension Registers.)
Eight Function Configuration Register locations in attribute memory have been assigned to the
Address Extension Registers. The Address Extension Register locations are organized in pairs to
allow for 4 16-bit Address Extension Registers. However, either one, two or four Address Extension
Registers may appear on a PC Card and these registers may be either 8-bit or 16-bit. The highest
numbered (offset) register of a Function Configuration Register pair is the upper byte of the
Address Extension Register.
When four Address Extension Registers are present on the PC Card, the A[23::0] card address
signals select a byte or word location within a 16 MByte page of memory while one of the four
registers provides an address extension to select the 16 MByte page. The address extension for the
page is defined in terms of extended address signals, starting with MA24 as the least significant bit.
The extended address signals appear in the Address Extension Registers as follows:
Register Offset 7 6 5 4 3 2 1 0
22, 26, 30 & 34 Address Extension Register 0, 1, 2 & 3 Low

MA31 MA30 MA29 MA28 MA27 MA26 MA25 MA24
24, 28, 32 & 36 Address Extension Register 0, 1, 2 & 3 High
During a memory cycle the cardÕs A24 and A25 address input signals select which one of the four
Address Extension Registers provides the extended address signals to memory. The register
selection is defined as follows:
A25 A24 Selected Register
0 0 Address Extension Register 0

When two Address Extension Registers are present on the PC Card, the A[24::0] card address
signals select a byte or word location within a 32 MByte page of memory while one of the two
registers provides an address extension to select the 32 MByte page. The address extension for the
page is defined in terms of extended address signals, starting with MA25 as the least significant bit.
The extended address signals appear in the Address Extension Registers as follows:
22 & 26 Address Extension Register 0 & 1 Low

24 & 28 Address Extension Register 0 & 1 High
During a memory cycle the cardÕs A25 address input signal selects which one of the two Address
Extension Registers provides the extended address signals to memory. The register selection is
defined as follows:
A25 Selected Register
0 Address Extension Register 0

1 Address Extension Register 1
When only one Address Extension Register is present on the PC Card, the A[25::0] card address
signals select a byte or word location within a 64 MByte page of memory while the register provides
an address extension to select the 64 MByte page. The address extension for the page is defined in
terms of extended address bits, starting with MA26 as the least significant bit. The extended address
bits appear in the Address Extension Register 0 as follows:

The exact number of Function Configuration Registers supported by a PC Card is specified by the
TPCC_RMSK byte of the CISTPL_CONFIG tuple. Thus, a PC CardÕs Card Information Structure
(CIS) indicates which Address Extension Registers are present. However, software can also
determine used and unused register locations by writing the registers first with a pattern of all 1Õs
and then with a pattern of all 0Õs, each time reading the register locations to determine where
registers actually exist to store the pattern. Unused register bytes are reserved for unused extended
address signals and return either all '0' bits or all '1' bits when read. The Address Extension Register
High bytes need be present on a PC Card only for Common Memory spaces requiring more than
the eight address extension bits provided by a single 8-bit register.
When an Address Extension Register is provided by a PC Card, the associated Address Extension
Register Low byte is always present (as indicated by TPCC_RMSK). However, not all 8 bits of an
Address Extension Register are required to be implemented for address extension. Unused register
bits are reserved for unused extended address signals and return either all 0Õs or all 1Õs when read.
Even though the Address Extension Registers can provide an address extension which addresses
beyond 4 GBytes of Common Memory, the Card Services Specification as of the PC Card Standard
Release 6.1 supports a maximum Common Memory size of 4 GBytes.
Upon card power-up the PC Card initializes its Address Extension Registers to form a contiguous 64
MByte area in Common Memory. The contiguous 64 MByte area provides a single 64 MByte area of
memory which non-extended PC host software (without address extension knowledge) can address.
To form the contiguous 64 MByte area, each register is set to the registerÕs number, i.e., Address
Extension Register 0 is set to 0, Address Extension Register 1 is set to 1, Address Extension Register
2 is set to 2, and Address Extension Register 3 is set to 3. After the registers have been initialized,
the host processor can write a register with the address extension of any page in the cardÕs memory
array.
4.16 Indirect Access to PC Card Memory

This optional register set, located in common memory space, enables an indirect access mechanism
for 16-bit PC Cards. (See CISTPL_INDIRECT in the Metaformat Specification.) This mechanism
requires only four (4) address lines to provide access to spaces equivalent to the standard 16-bit PC
Card Attribute and Common Memory spaces. All registers may be read or written.
The actual size of any indirect access spaces is determined by the card vendor as it is for standard
Common Memory and Attribute Memory spaces.
Table 4Ð36 Indirect Access Registers

2 Control_lo
Reserved Byte Gran Auto Inc Space
3 Control_hi
Reserved
4 .. 7 Address
8 .. 9 Data
Field Description
Control_hi This sixteen (16) bit register controls read and write accesses through the Data register at the address present in
Control_lo the Address register.
Space 0 = Indirect Attribute Space
1 = Indirect Common Space
Auto Inc 0 = do not adjust Address when a read or write access is made to Data.
1 = adjust Address according to the Byte Gran setting on each Data access.
Byte Gran This field is ignored when the Auto Inc field is zero (0).
0 = add two (2) to Address following each Data access.
1 = add one (1) to Address following each Data access.
Reserved These register bits are reserved and must be set to zero.
Address This register indicates the current twenty-six (26) bit address that will be used on the next Data access.
Data Reading this sixteen (16) bit register will fetch the sixteen (16) bit value at the indirect address indicated by the
Space setting in the Control register using the current value of Address. If the Space setting indicates indirect
Attribute Space, only the even byte data is valid.
Writing a value to this register will present a write operation to card memory at the indirect address indicated by
the Space setting in the Control register and the current value of Address.
5 . CAR D BU S PC CAR D EL E C T R IC AL
I N T E R F AC E
The CardBus PC Card Interface provides a high performance 32-bit/bus master capability for full-
size PC Cards. As briefly discussed in the Overview section of this specification, CardBus PC Card
introduces many new features and functions. The specification text uses many terms which may be
new to prior PC Card Standard users. See the Overview and Glossary to aid in understanding
these terms. While every attempt has been made to explain functions and operations within
relevant sections of the specification, the following concepts apply and should be understood prior to
assimilation of the CardBus PC Card specification details:
• CardBus PC Cards may include, in any combination:
32-bit bus masters, also referred to as transaction initiators, and
32-bit bus slaves, also referred to as transaction targets (may be a memory slave, an I/O slave,
or both).
• CardBus PC Card sockets must be able to support operations with, or gracefully reject, any
CardBus PC Card and/or any 16-bit PC Card within the capabilities/limitations of the host
system (i.e., a system that is incapable of providing 5.0 volts cannot support 5 V 16-bit PC
Cards)
The user of this specification should read and understand section 5.5 Requirements For CardBus PC
Cards and Sockets and should also consider the following from the Guidelines Volume prior to any
implementation:
• Enabler Capabilities and Behavior
• Card-Application Interaction
• CardBus PC Card/PCI Common Silicon Requirements
• CardBus PC Card Operational Scenarios
Additionally, users should consider the following section:
• 8. CardBus PC Card Connector Test Methodology (Appendix B)
5.1 CardBus PC Card Signal Description

The CardBus PC Card interface requires a minimum of 46 signals for a target-only device and a
minimum of 49 signals for a master to handle data and addressing, interface control, arbitration,
and other functions. Also, there are several optional signals, depending on the functions supported
by CardBus PC Card agents. In addition, two Card Detect (CCD[2::1]#), two Voltage Sense
(CVS[2::1]) signals, and four ground (GND), two VCC, and two VPP[2::1] pins are defined. Refer to
the Required Signals section of this specification for the lists of required and optional signals/pins for
CardBus PC Cards and CardBus PC Card sockets.
All signals are organized in functional groups:
• System signals
• Address and Data signals
CARDBUS PC CARD ELECTRICAL INTERFACE
• Interface Control signals

• Arbitration signals
• Error Reporting signals
• Interrupt
• Additional signals
• Power and Ground
Table 5Ð1 CardBus PC Card List of Signals

Signal Name Number of Description Card Socket
Pins
CCLK 1 (CardBus PC Card) Clock in out
CCLKRUN# 1 (CardBus PC Card) Clock Request/Status i/o, o/d i/o, s/h/z
CRST# 1 (CardBus PC Card) Card Reset in out
CAD[31::00] 32 (CardBus PC Card) Multiplexed Address/Data lines i/o, h/z i/o, h/z
CCBE[3::0]# 4 (CardBus PC Card) Command and Byte Enables i/o, h/z i/o, h/z
CPAR 1 (CardBus PC Card) Parity i/o, h/z i/o, h/z
CFRAME# 1 (CardBus PC Card) Cycle Frame i/o, s/h/z i/o, s/h/z
CIRDY# 1 (CardBus PC Card) Initiator Ready i/o, s/h/z i/o, s/h/z
CTRDY# 1 (CardBus PC Card) Target Ready i/o, s/h/z i/o, s/h/z
CSTOP# 1 (CardBus PC Card) Stop transaction i/o, s/h/z i/o, s/h/z
CBLOCK# 1 (CardBus PC Card) Card Lock i/o, s/h/z i/o, s/h/z
CDEVSEL# 1 (CardBus PC Card) Device Select i/o, s/h/z i/o, s/h/z
CREQ# 1 (CardBus PC Card) Request out, h/z in
CGNT# 1 (CardBus PC Card) Grant in out, h/z
CPERR# 1 (CardBus PC Card) Parity Error i/o, s/h/z i/o, s/h/z
CSERR# 1 (CardBus PC Card) System Error out, o/d in
CINT# 1 (CardBus PC Card) Card Interrupt request out, o/d in
CSTSCHG 1 (CardBus PC Card) Card Status Changed out, h/z in
CAUDIO 1 (CardBus PC Card) Card Audio signal out in
CCD[2::1]# 2 (CardBus PC Card) Card Detect out in
CVS[2::1] 2 (CardBus PC Card) Voltage Sense i/o i/o
GND 4 Ground DC DC
VCC 2 Power DC in DC out
VPP1[2::1] 2 Programming (peripheral supply) Voltages DC in DC out
5.1.1 Pin Assignments

In 16-bit PC Card interface mode, the 16-bit PC Card signals, CE[2::1]#, VPP[2::1], WP, CD[2::1]#,
WAIT#, VS[2::1]#, and BVD[2::1] must not be connected between PC Cards. For these signals that
are outputs from the card, they must not be directly connected to any other signal source within the
host system. They must not be wire-ORÕd or wire-ANDÕd with any host system signals. All sockets
shall support both 16-bit PC Card and CardBus PC Card interfaces and cannot connect any signals
together.
The READY signal must not be connected between cards when the 16-bit PC Card interface socket
supports both I/O and Memory interfaces. It must not be wire-ORÕd or wire-ANDÕd with any host
system signals.
In systems which switch VCC individually to cards, no signal shall be directly connected between
cards other than ground.
Table 5Ð2 PC Card Pin 1 to Pin 34 Assignments

16-bit PC Card Interface CardBus PC Card Interface
Memory-Only I/O and Memory
Pin Signal I/O Notes Signal I/O Signal I/O Notes
1 GND DC GND DC GND DC
2 D3 I/O D3 I/O CAD0 I/O
7 CE1# I CE1# I CCBE0# I/O
8 A10 I A10 I CAD9 I/O
9 OE# I OE# I CAD11 I/O
10 A11 I A11 I CAD12 I/O
12 A8 I A8 I CCBE1# I/O
13 A13 I A13 I CPAR I/O
14 A14 I A14 I CPERR# I/O
15 WE# I WE# I CGNT# I
16 READY O 1 IREQ# O CINT# O
17 VCC DC in VCC DC in VCC DC in
18 VPP1 DC in VPP1 DC in VPP1 DC in
19 A16 I A16 I CCLK I
20 A15 I A15 I CIRDY# I/O
21 A12 I A12 I CCBE2# I/O
32 D2 I/O D2 I/O RFU 2
33 WP O 1 IOIS16# O CCLKRUN# I/O
"I" indicates signal is input to PC Card, "O" indicates signal is output from PC Card.
1. Use of pin changes between the 16-bit PC Card Memory-Only and the I/O and Memory interface.
2. Reserved for future use by the CardBus PC Card interface. CardBus PC Card sockets support both the
16-bit PC Card and CardBus PC Card interfaces therefore, the signals must be connected as defined
for the 16-bit PC Card interface when the CardBus PC Card adapter has detected a valid 16-bit PC
Card insertion event.
Table 5Ð3 PC Card Pin 35 to Pin 68 Assignments

16-bit PC Card Interface CardBus PC Card Interface
Pin Memory-Only I/O and Memory
Signal I/O Notes Signal I/O Signal I/O Notes
36 CD1# O CD1# O CCD1# O
40 D14 I/O D14 I/O RFU 2
42 CE2# I CE2# I CAD10 I/O
43 VS1# O 4 VS1# O CVS1 I/O
44 RFU 1 IORD# I CAD13 I/O
45 RFU 1 IOWR# I CAD15 I/O
46 A17 I A17 I CAD16 I/O
47 A18 I A18 I RFU 2
48 A19 I A19 I CBLOCK# I/O
49 A20 I A20 I CSTOP# I/O
50 A21 I A21 I CDEVSEL# I/O
51 VCC DC in VCC DC in VCC DC in
52 VPP2 DC in VPP2 VPP2 DC in
53 A22 I A22 I CTRDY# I/O
54 A23 I A23 I CFRAME# I/O
55 A24 I A24 I CAD17 I/O
56 A25 I A25 I CAD19 I/O
57 VS2# 5 VS2# CVS2 I/O
58 RESET I 3 RESET I CRST# I
59 WAIT# O 3 WAIT# O CSERR# O
60 RFU 1 INPACK# O CREQ# O
61 REG# I 1 REG# I CCBE3# I/O
62 BVD2 O 1 SPKR# O CAUDIO O
63 BVD1 O 1 STSCHG# O CSTSCHG O
66 D10 I/O D10 I/O CAD31 I/O
67 CD2# O CD2# O CCD2# O
3. RESET and WAIT# are RFU in PCMCIA 1.0 / JEIDA 4.0 version of the Standard. These signals are
required in PCMCIA 2.0 / JEIDA 4.1 and all later versions of the Standard.
4. VS1# was named RFSH in PCMCIA 2.1 / JEIDA 4.2 and earlier versions of the Standard.
5. VS2# was RFU in PCMCIA 2.1 / JEIDA 4.2 and earlier versions of the Standard.
5.1.2 Signal/Pin Description
5.1.2.1 System Pins

CCLK input to CardBus PC Card Clock provides timing for all transactions on the CardBus PC Card interface and is
card an input to every CardBus PC Card device. All other CardBus PC Card signals, except CRST# (upon
assertion), CCLKRUN#, CINT#, CSTSCHG, CAUDIO, CCD[2::1]#, and CVS[2::1], are sampled on
the rising edge of CCLK, and all timing parameters are defined with respect to this edge. CardBus PC
Card operates up to 33ÊMHz. Also, the clock can be stopped in the low state. (See 5.3.2.2.1 Clock
Specifications and see also 5.2.10 Clock Control.)
CCLKRUN# i/o, o/d CardBus PC Card Clock Run is a signal which is used by cards to request starting (or speeding up)
for card the CardBus PC Card clock, CCLK. CCLKRUN# also indicates the clock status. For PC Cards,
CCLKRUN# is an open drain output and also an input. For the host system, it is a Sustained High-Z
state I/O signal. A CardBus PC Card requests the host system to start, speed up or maintain the
interface clock by assertion of CCLKRUN#. The host system is responsible for maintaining
CCLKRUN# asserted, and for driving it high to the negated state.
CRST# input to CardBus PC Card Reset is used to bring CardBus PC Card specific registers, sequencers, and
card signals to a consistent state. What effect CRST# has on an agent beyond the CardBus PC Card
sequencer is beyond the scope of this specification, except for the reset states of required CardBus PC
Card configuration registers. Anytime CRST# is asserted, all CardBus PC Card output signals must
be driven to their benign state. In general, this means they must be in a High-Z state. CSERR#, CINT#,
and CCLKRUN# (open drain) are floated. CREQ# must be in a High-Z state (it cannot be driven low
or high during reset). CGNT# must be negated. To prevent CAD[31::00], CCBE[3::0]#, and CPAR
signals from floating during reset, the central resource may drive these lines during reset but only to a
low voltage level, they may not be driven high. CVS[2::1] must be driven low. The states of
CCD[2::1]#, and CSTSCHG are not affected by CRST#. The CSTSCHG signal may actually pulse
while CRST# is asserted.
CRST# may be asynchronous to CCLK when asserted. Negation of CRST# is synchronous to CCLK
5.1.2.2 Address and Data Pins

CAD[31::00] i/o, h/z CardBus PC Card Address and Data are multiplexed on the same CardBus PC Card pins. A bus
transaction consists of an address phase followed by one or more data phases. CardBus PC Card
supports both read and write bursts.
The address phase is the clock cycle in which CFRAME# is asserted. During the address phase,
CAD[31::00] contain a physical address (32 bits). For I/O, this is a byte address; for configuration and
memory it is a DWORD address. During data phases, CAD[07::00] contain the least significant byte
(LSB) and CAD[31::24] contain the most significant byte (MSB)4. Write data is stable and valid when
CIRDY# is asserted and read data is stable and valid when CTRDY# is asserted. Data is transferred
during those clocks where both CIRDY# and CTRDY# are asserted.
CCBE[3::0]# i/o, h/z CardBus PC Card Command and Byte Enables are multiplexed on the same CardBus PC Card pins.
During the address phase of a transaction, CCBE[3::0]# define the bus command (refer to the Bus
Commands section of this specification for bus command definitions). During the data phase,
CCBE[3::0]# are used as Byte Enables. The Byte Enables are valid for the entire data phase and
determine which byte lanes carry meaningful data. CCBE[0]# applies to byte 0 (LSB) and CCBE[3]#
applies to byte 3 (MSB).
CPAR i/o, h/z CardBus PC Card Parity is even5 parity across CAD[31::00] and CCBE[3::0]#. Parity generation is
required by all CardBus PC Card agents. CPAR is stable and valid one clock after the address phase.
For data phases CPAR is stable and valid one clock after either CIRDY# is asserted on a write
transaction or CTRDY# is asserted on a read transaction. Once CPAR is valid, it remains valid until
one clock after the completion of the current data phase. (CPAR has the same timing as CAD[31::00]
but delayed by one clock.) The master drives CPAR for address and write data phases; the target
drives CPAR for read data phases.
4Bit order follows the convention where: bit 0 is LSB and bit 31 is MSB.
5 The number of "1"s on CAD[31::00], CCBE[3::0]#, and CPAR equal an even number.
5.1.2.3 Interface Control Pins

CFRAME# i/o, s/h/z CardBus PC Card Cycle Frame is driven by the current master to indicate the beginning and duration
of a transaction. CFRAME# is asserted to indicate that a bus transaction is beginning. While
CFRAME# is asserted, data transfers continue. When CFRAME# is negated, the transaction is in the
final data phase.
CIRDY# i/o, s/h/z CardBus PC Card Initiator Ready indicates the initiating agent's (bus master's) ability to complete the
current data phase of the transaction. CIRDY# is used in conjunction with CTRDY#. A data phase is
completed on any clock both CIRDY# and CTRDY# are sampled asserted. During a write, CIRDY#
indicates that valid data is present on CAD[31::00]. During a read, it indicates the master is prepared
to accept data. Wait cycles are inserted until both CIRDY# and CTRDY# are asserted together.
CTRDY# i/o, s/h/z CardBus PC Card Target Ready indicates the agent's (selected target's) ability to complete the current
data phase of the transaction. CTRDY# is used in conjunction with CIRDY#. A data phase is completed
on any clock both CTRDY# and CIRDY# are sampled asserted. During a read, CTRDY# indicates that
valid data is present on CAD[31::00]. During a write, it indicates the target is prepared to accept data.
Wait cycles are inserted until both CIRDY# and CTRDY# are asserted together.
CSTOP# i/o, s/h/z CardBus PC Card Stop indicates the current target is requesting the master to stop the current
transaction.
CBLOCK# i/o, s/h/z CardBus PC Card Lock is an optional signal which indicates an atomic operation that may require
multiple transactions to complete. When CBLOCK# is asserted, non-exclusive transactions may
proceed to an address that is not currently locked. A grant to start a transaction on CardBus PC Card
does not guarantee control of CBLOCK#. Control of CBLOCK# is obtained under its own protocol in
conjunction with CGNT#. It is possible for different agents to use CardBus PC Card while a single
master retains ownership of CBLOCK#. If a CardBus PC Card implements shared memory, it must
also implement CBLOCK# and guarantee complete access exclusion in that memory. Host bridges
that have system memory behind them must also implement CBLOCK#.
CDEVSEL# i/o, s/h/z CardBus PC Card Device Select, when actively driven, indicates the driving device has decoded its
address as the target of the current access. As an input, CDEVSEL# indicates whether any device on
the bus has been selected.
5.1.2.4 Arbitration Pins (Bus Masters Only)

CREQ# out, h/z CardBus PC Card Request indicates to the arbiter that this agent desires use of the bus. Every master
for card has its own CREQ#.
CGNT# out, h/z CardBus PC Card Grant indicates to the agent that access to the bus has been granted. Every master
for has its own CGNT#.
socket
5.1.2.5 Error Reporting Pins

The error reporting pins are required by all devices.
CPERR# i/o, s/h/z CardBus PC Card Parity Error is only for the reporting of data parity errors during all CardBus PC
Card transactions except a Special Cycle. The CPERR# pin is sustained tri-state and must be driven
active by the agent receiving data two clocks following the data when a data parity error is detected.
The minimum duration of CPERR# is one clock for each data phase that a data parity error is detected.
If sequential data phases each have a data parity error, the CPERR# signal will be asserted for more
than a single clock. CPERR# must be driven high for one clock before being tri-stated as with all
sustained tri-state signals. There are no special conditions when a data parity error may be lost or
when reporting of an error may be delayed. An agent cannot report a CPERR# until it has claimed the
access by asserting CDEVSEL# and completed a data phase.
CSERR# out, o/d CardBus PC Card System Error is for reporting address parity errors, data parity errors on the Special
for card Cycle command, or any other system error where the result could be catastrophic. If an agent does not
want a non-maskable interrupt (NMI) to be generated, a different reporting mechanism is required.
CSERR# is pure open drain and is actively driven for a single CardBus PC Card clock by the agent
reporting the error. The assertion of CSERR# is synchronous to the clock and meets the setup and hold
times of all bused signals. However, the restoring of CSERR# to the negated state is accomplished by
a weak pull-up (same value as used for s/h/z) which is provided by the system designer and not by the
signaling agent or central resource. This pull-up may take two to three clock periods to fully restore
CSERR#. The agent that reports CSERR#s to the operating system does so anytime CSERR# is
sampled asserted.
5.1.2.6 Interrupt Request Pin

CINT# out, o/d Card Interrupt Request is an optional signal which is defined as level sensitive, and asserted low
for card (negative true), using an open drain output driver. The assertion and negation of CINT# is
asynchronous to CCLK. Single function and multi-function6 cards are supported. The system vendor is
free to combine the various CINT# signals from CardBus PC Card connectors in any way to connect
them to the interrupt controller. This means the device driver may not make any assumptions about
interrupt sharing. All CardBus PC Card device drivers must be able to share an interrupt (chaining)
with any other logical device, including functions on the same multi-function card.
CINT# is asserted while the INTR field of the Function Event Mask Register is set (1) and either or
both the INTR field of the Function Event Register is set (1) or the INTR field of the Function Present
State Register is set (1). (See 5.2.11.3 Register Descriptions)
5.1.2.7 Additional Signals

CSTSCHG out, h/z Card Status Changed is an optional signal used to alert the system to changes in the READY, WP, or
for card BVD[2::1] conditions of the card. It is also used for the system and/or CardBus PC Card interface
Wake up. CSTSCHG is asynchronous to CCLK.
CSTSCHG is asserted while any field in the Function Event Mask Register other than INTR is set (1)
and the field of the same name in the Function Event Register is set (1). (See 5.2.11.3 Register
Descriptions)
CAUDIO out Card Audio is an optional digital audio output signal from a PC Card to the system's speaker. CardBus
for card PC Card supports two types of audio signals: a single amplitude, binary waveform, and/or Pulse Width
Modulation (PWM) encoded signal. CAUDIO has no relationship to CCLK
CCD[2::1]#, (See 2. Common Pin Description.)
CVS[2::1]#,
VCC,
VPP[2::1]
GND
6 When several independent functions are integrated into a single PC Card, it is referred to as a multi-function card.
Each function on a multi-function card has its own configuration space.
5.1.3 Central Resource Functions

Throughout this specification the term central resource is used to describe CardBus PC Card support
functions supplied by the host system, typically in the host CardBus PC Card adapter or in a
CardBus PC Card compliant bridge. These functions may include, but are not limited to, the
following:
• Central Arbitration,
• Required signal pull-ups or "keepers" (See 5.3.3.3 Pull-ups.),
• Default ownership of the interface, and
• CardBus PC Card Clock control.
5.2 CardBus PC Card Operation

The CardBus PC Card specification requires strong ordering of all transactions and operands across
the interface.
5.2.1 Bus Commands

Bus Commands indicate to the target the type of transaction the master is requesting. Bus
Commands are encoded on the CCBE[3::0]# lines during the address phase.
5.2.1.1 Command Definition

CardBus PC Card Bus Command encodings and types are as listed below, followed by a brief
description of each. Note that the command encodings are as viewed on the bus where a "1"
indicates a high voltage and "0" is a low voltage. Byte Enables are asserted when 0.
Table 5Ð4 CardBus PC Card Commands

CCBE[3::0]# Command type
0000 Allocated
0001 Special Cycle
0010 I/O Read
0011 I/O Write
0100 Reserved
0101 Reserved
0110 Memory Read
0111 Memory Write
1000 Reserved
1001 Reserved
1010 Configuration Read
1011 Configuration Write
1100 Memory Read Multiple
1101 Allocated
1110 Memory Read Line
1111 Memory Write and Invalidate
Allocated indicates that the command encoding is not defined for CardBus PC Card, and must not be
defined as other environments use the encoding. The purpose of allocated command encodings is to
maintain compatibility between CardBus PC Card and other environments. CardBus PC Card
targets must not alias allocated commands with other commands. Targets must not respond to
allocated encodings. If an allocated encoding is used on the interface, the access typically will be
terminated with master-abort.
The Special Cycle command provides a simple message broadcast mechanism on CardBus PC Card.
It is designed to be used as an alternative to physical signals when sideband communication is
necessary. (See 5.2.7.2 Special Cycle.)
The I/O Read command is used to read data from an agent mapped in I/O address space.
CAD[31::00] provide a byte address. All 32 bits must be decoded. The Byte Enables indicate the
size of the transfer and must be consistent with the byte address.
The I/O Write command is used to write data to an agent mapped in I/O address space. All 32 bits
must be decoded. The Byte Enables indicate the size of the transfer and must be consistent with the
byte address.
Reserved command encodings are reserved for future use. CardBus PC Card targets must not alias
reserved commands with other commands. Targets must not respond to reserved encodings. If a
reserved encoding is used on the interface, the access typically will be terminated with master-
abort.
The Memory Read command is used to read data from an agent mapped in the memory address
space. The target is free to do an anticipatory read for this command only if it can guarantee that
such a read will have no side effects. Furthermore, the target must ensure the coherency (which
includes ordering) of any data retained in temporary buffers after this CardBus PC Card transaction
is completed. Such buffers must be invalidated before any synchronization events (e.g., updating
an I/O Status register or memory flag) are passed through this access path.
The Memory Write command is used to write data to an agent mapped in the memory address space.
When the target returns "ready," it has assumed responsibility for the coherency (which includes
ordering) of the subject data. This can be done either by implementing this command in a fully
synchronous manner, or by insuring any software transparent posting buffer will be flushed before
synchronization events (e.g., updating an I/O Status register or memory flag) are passed through
this access path. This implies that the master is free to create a synchronization event immediately
after using this command.
The Configuration Read command is used to read the configuration space of each agent. An agent is
selected when its CFRAME# signal is asserted and CAD[1::0] are 00. During the address phase of a
configuration cycle, CAD[7::2] address one of the 64 DWORD registers (where byte enables address
the byte(s) within each DWORD) in the configuration space of each device and CAD[31::11] are
logical don't cares. CAD[10::08] indicate which device of a multi-function agent is being addressed.
The Configuration Write command is used to transfer data to the configuration space of each agent.
An agent is selected when the CFRAME# signal is asserted and CAD[1::0] are 00. During the
address phase of a configuration cycle, the CAD[7::2] lines address the 64 DWORD (where byte
enables address the byte(s) within each DWORD) configuration space of each device and
CAD[31::11] are logical don't cares. CAD[10::08] indicate which device of a multi-function agent is
being addressed.
The Memory Read Multiple command is semantically identical to the Memory Read command except
that it additionally indicates that the master may intend to fetch more than one cache line before
disconnecting. The memory controller should continue pipelining memory requests as long as
CFRAME# is asserted. This command is intended to be used with bulk sequential data transfers
where the memory system (and the requesting master) might gain some performance advantage by
sequentially reading ahead an additional cache line when a software transparent buffer is available
for temporary storage.
The Memory Read Line command is semantically identical to the Memory Read command except that
it additionally indicates that the master intends to complete more than two 32-bit CardBus PC Card
data phases. This command is intended to be used with bulk sequential data transfers where the
memory system (and the requesting master) might gain some performance advantage by reading
up to a cache line boundary in response to the request rather than a single memory cycle. As with
the Memory Read command, pre-fetched buffers must be invalidated before any synchronization
events are passed through this access path.
The Memory Write and Invalidate command is semantically identical to the Memory Write command
except that it additionally guarantees a minimum transfer of one complete cache line; i.e., the
master intends to write all bytes within the addressed cache line in a single CardBus PC Card
transaction. The master may allow the transaction to cross a cache line boundary only if it also
intends to transfer the entire next line. This command requires implementation of a configuration
register in the master indicating the cache line size. A target containing memory which might be
cacheable by the host system is also required to implement the Cache Line Size register. (See 5.2.9
Cache Support and 5.4.2.1 Configuration Space.) The target containing cacheable memory must
accept a full cache line before disconnecting the transaction if it completes the first data phase. This
command allows a memory performance optimization by invalidating a dirty line in a write-back
cache without requiring the actual write-back cycle, thus shortening access time. (See also 5.2.3.3.1
Master Initiated Termination.)
5.2.1.2 Command Usage Rules

All CardBus PC Card agents are required to respond as a target to configuration (read and write)
commands. All other commands are optional. Command execution order on the CardBus PC Card is
guaranteed for I/O (read and write) commands. CardBus PC Card targets that contain relocatable
functions or registers are required to allow them to be mapped to memory space through the
configuration registers. This is to provide for the option of using the device in configurations where
I/O space is not available. When such mapping is done, command execution order will be
guaranteed by the system designer whether the device is used in I/O or memory space. Memory
reads and writes to a mapped device constitute "memory mapped I/O."
A master may implement the optional commands as needed. A target may also implement the
optional commands as needed, but if it implements basic memory commands, it must support all
the memory commands, including Memory Write and Invalidate, Memory Read Line, and Memory
Read Multiple. This means that, if the target intends to complete the first data phase, it must
translate the requested command to a memory command it has implemented. For example, a target
might not implement the Memory Read Line command; however, it must accept the request (if the
address is decoded for a memory access) and treat it as a Memory Read command. Similarly, a non-
cacheable target might not implement the Memory Write and Invalidate command, but must accept
the request (if the address is decoded for a memory access) and treat it as a Memory Write
command.
For block data transfer to/from system memory, Memory Write and Invalidate and Read Memory
Line are the recommended commands for masters capable of supporting them. The Memory Read
or Memory Write commands can be used if for some reason the master is not capable of using the
performance optimizing commands.
For masters using Memory Read commands, any length access will work for all commands,
however the preferred use is shown below. While Write and Invalidate is the only command that
requires implementation of the Cache Line Size register, it is strongly suggested the Memory Read
commands use it as well. In all cases, the bridge is responsible for the correctness of any latent data.
Preferred use is shown for both cases (with and without using the Cache Line Size register).
The preferred use when using the Cache Line Size register is:
Memory Read command use when bursting one half or less of a cache line
Memory Read Line command use when bursting more than one half of a cache line to three cache lines
Memory Read Multiple command use when bursting more than three cache lines
The preferred use when not using the Cache Line Size register is:
Memory Read command use when bursting two or less data transfers
Memory Read Line command use when bursting 3 to 12 data transfers
Memory Read Multiple command use when doing long bursts (13 or more data transfers)
5.2.2 CardBus PC Card Protocol Fundamentals

The basic bus transfer mechanism on CardBus PC Card is a burst. A burst is composed of an
address phase and one or more data phases. CardBus PC Card supports bursts in both memory and
I/O address spaces. The host bridge (that resides between the host processor and CardBus PC Card)
may merge (or assemble) memory write accesses into a single transaction when no side effects exist.
A device indicates no side effects (allow prefetching of read data and merging of write data in any
order) by setting the prefetch bit in the Base Address register (refer to the Base Address Register
section of this specification). A bridge may distinguish where merging is allowed and where it is
not by an address range which could be provided by configuration software during initialization.
Merging of data into that buffer must stop (and the buffer flushed) when a subsequent write occurs
that is not prefetchable or a read occurs to any range. Write transactions following either of these
two events may be merged with subsequent writes, but not to previously merged data, even if in
the prefetchable range.
The host bridge may always combine sequential DWORDs (memory write) generated by the
processor into bursts as long as the implied address ordering (associated with each DWORD) is the
same. For example, the bridge may create a burst when the processor write sequence is DWORD 0,
DWORD 2, and DWORD 3. The CardBus PC Card burst sequence could be DWORD 0, DWORD 1
(no byte enables), DWORD 2 and complete the burst with DWORD 3. Combining is allowed
anytime the next DWORD address is more significant than the previous one. The bridge may
convert single Processor (memory) read requests into a read burst (reading ahead of the processor)
when the read will not cause a side effect in the addressed target.
Since I/O accesses from the processor cannot be combined, they will normally only have a single
data phase. Currently, no known processor or bus master generates bursts in I/O space. However,
if in the future some new device is capable of generating meaningful I/O bursts (e.g., accessing a
FIFO port), it will not be precluded. There is no implied addressing on I/O bursts. When I/O
bursts are done, the target and master must understand the implied addressing. CardBus PC Card
devices that do not deal with multiple I/O data phases must disconnect the access after the first data
phase. To ensure that I/O devices will operate correctly, bridges may never merge or combine
sequential I/O accesses into a single CardBus PC Card access or burst. All I/O accesses must appear
on CardBus PC Card exactly as the processor generated them. (If a target of an I/O access is selected
by its address but the byte enables indicate a transfer larger than the device supports, the target
terminates with target-abort.)
All signals are sampled on the rising edge of the clock7. Each signal has a setup and hold aperture
with respect to the rising clock edge, in which transitions are not allowed. Outside this aperture,
signal values or transitions have no significance. This aperture occurs only on qualified rising clock
edges for CAD[31::00] and CPAR8 signals,9 and on every rising clock edge for CBLOCK#,
CIRDY#, CTRDY#, CFRAME#, CDEVSEL#, CSTOP#, CREQ#, CGNT#, CSERR# (only on
assertion), CRST# (only on negation), and CPERR#. CCBE[3::0]#, as bus commands, are qualified
on the clock edge that CFRAME# is first asserted. CCBE[3::0]#, as byte enables, are qualified on
7 The exceptions are CINT#, CSTSCHG#, CCLKRUN#, CAUDIO, CCD[2::1]#, and CVS[2::1] which are
discussed inthe Signal Definition Section.
8 CPAR is treated like a CAD line delayed by one clock.
9 The notion of qualifying CAD signals is fully defined in 5.2.7.3 Address/Data Stepping.
each rising clock edge following the completion of an address phase or data phase. CINT#,
CSTSCHG, CCLKRUN#, CAUDIO, CCD[2::1]#, and CVS[2::1] are not qualified or synchronous.
5.2.2.1 Basic Transfer Control

The fundamentals of all CardBus PC Card data transfers are controlled with three signals. (See
Figure 5-1 CardBus PC Card Basic Read Operation.)
CFRAME# is driven by the master to indicate the beginning and end of a transaction.
CIRDY# is driven by the master, allowing it to force wait cycles.
CTRDY# is driven by the target, allowing it to force wait cycles.
The interface is IDLE when both CFRAME# and CIRDY# are negated. The first clock edge on
which CFRAME# is asserted is the address phase, and the address and bus command code are
transferred on that clock edge. The next clock edge begins the first of one or more data phases,
during which data is transferred between master and target on each clock edge for which both
CIRDY# and CTRDY# are asserted. Wait cycles may be inserted in a data phase by either the
master or the target with CIRDY# and CTRDY# signals respectively.
The source of the data is required to assert its CXRDY# signal unconditionally when data is valid
(CIRDY# on a write transaction, CTRDY# on a read transaction). The receiving agent may assert its
CXRDY# as it chooses.
Once a master has asserted CIRDY# it cannot change CIRDY# or CFRAME# until the current data
phase completes regardless of the state of CTRDY#. Once a target has asserted CTRDY# or
CSTOP# it cannot change CDEVSEL#, CTRDY#, or CSTOP# until the current data phase
completes. Neither the master nor the target can change its mind once it has committed to the data
transfer.
At such time as the master intends to complete only one more data transfer (which could be
immediately after the address phase), CFRAME# is negated and CIRDY# is asserted indicating the
master is ready. After the target indicates the final data transfer (CTRDY# is asserted), the interface
returns to the IDLE state with both CFRAME# and CIRDY# negated.
5.2.2.2 Addressing
CardBus PC Card defines three physical address spaces. The memory and I/O address spaces are
customary. The configuration address space has been defined to support CardBus PC Card
hardware configuration. (See also 5.2.7.4.1 Generating Configuration Cycles.)
CardBus PC Card targets that contain relocatable functions or registers are required to allow them to
be mapped to memory space through the Base Address registers located in the CardBus PC Card
configuration space. This is to provide for the option of using the device in system configurations
where I/O space is not available.
Address decoding on CardBus PC Card is distributed, i.e., done on every device. This obviates the
need for central decode logic, or for device select signals. Each agent is responsible for its own
address decode. CardBus PC Card supports two styles of address decoding, positive and subtractive.
Positive decoding is faster since each device is looking for accesses in the address range(s) that it has
been assigned. Subtractive decoding can be implemented by only one device on the bus, since it
accepts all accesses not positively decoded by some other agent. This decode mechanism is slower
since it must give all other bus agents a "first right of refusal" on the access. However, it is very
useful for an agent that must respond to a highly fragmented address space. Targets that perform
either positive or negative decode must not respond (assert CDEVSEL#) to reserved or allocated bus
commands.
The information contained in the two low order address bits (CAD[1::0]) varies by address space. In
the I/O address space, all 32 CAD lines are used to provide a full byte address. This allows an
agent requiring byte level address resolution to complete address decode and claim the cycle10
without waiting an extra cycle for the byte enables (thus delaying all subtractive decode cycles by
an extra clock). CAD[1::0] are used for the generation of CDEVSEL# only and indicate the least
significant valid byte involved in the transfer. For example, if CCBE0# were asserted then
CAD[1::0] would be 00; if only CCBE3# were asserted, then CAD[1::0] would be 11. Once a target
has claimed an I/O access (using CAD[1::0]), it then determines if it can complete the entire access
as indicated in the byte enables. If all the selected bytes are not in the selected target's address
range, the entire access cannot be completed. In this case, the target does not transfer any data, but
terminates with a target-abort.
The table below summarizes the encoding of CAD[1::0].
Table 5Ð5 Address Bus Encoding

CAD1 CAD0 CCBE3# CCBE2# CCBE1# CCBE0#
0 0 X X X 0
0 1 X X 0 1
1 0 X 0 1 1
1 1 0 1 1 1
The above table is for decode purposes only and only applies to a device that does not control all
bytes within a single I/O DWORD. Such devices must terminate the cycle with target abort for any
byte enable/CAD[1::0] combination not in the above table. However, devices that "own" all bytes
in the I/O DWORD do not have to check for illegal byte enable/CAD[1::0] combinations. Instead,
they may ignore CAD1 and CAD0 (i.e., claim the cycle based on the DWORD address and perform
the operation described by the byte enables). Note that any combination of byte enables is valid,
including none. (A device may restrict which combination of byte enables its device driver may
use.)
All targets are required to check CAD[1::0] during a memory command transaction, and either
provide the requested burst order, or execute a target disconnect with or after the first data phase.
Implementation of linear burst ordering is required by all devices that can support bursting.
Implementing other burst order modes is not required. In the memory address space, accesses are
decoded to a DWORD address using CAD[31::02]. In linear incrementing mode, the address is
assumed to increment by one DWORD after each data phase until the transaction is terminated.
During Memory commands, CAD[1::0] have the following meaning:
CAD1 CAD0 Burst Order
0 0 Linear address incrementing
0 1 Reserved (disconnect after first data phase)
1 X Reserved (disconnect after first data phase)
In the configuration address spaces, accesses are decoded to a DWORD address using CAD[7::2]. An
agent determines that it is the target of the access (asserts CDEVSEL#) when a configuration
command is decoded and CAD[1::0] are 00. Otherwise, the agent ignores the current transaction. A
bridge determines that a configuration access is for a device behind it by decoding a configuration
10 Standard PC address assignments in the I/O space are such that separate physical devices may share the same
DWORD address. This means that in certain cases a full byte address is required for the device to claim the access
(assert CDEVSEL#).
command, its bridge number, and that CAD[1::0] are 01. For more details about configuration
accesses refer to the (See also 5.2.7.4.1 Generating Configuration Cycles.)
5.2.2.3 Byte Alignment

Byte lane swapping is not done on CardBus PC Card since all CardBus PC Card compliant devices
must connect to all 32 address/data bits for address decode purposes. This means that bytes will
always appear in their natural byte lane, based upon byte address.
Furthermore, CardBus PC Card does not support automatic bus sizing. In general, software is aware
of the characteristics of the target device and only issues appropriate length accesses.
The byte enables alone are used to determine which bytes carry meaningful data. The byte enables
are free to change between data phases but must be valid on the edge of the clock that starts each
data phase and must stay valid for the entire data phase. (See Figure 5-1 CardBus PC Card Basic
Read Operation) and note that data phases begin on clocks 3, 5, and 7. Changing byte enables
during a read burst transaction is generally not useful, but is permitted.) The master is free to
change the byte enables on each new data phase (although the read diagram does not show this). If
the master changes byte enables on a read transaction, it does so with the same timing as would be
used in a write transaction. If byte enables are important for the target on a read transaction, the
target must wait for the byte enables to be valid on each data phase before completing the transfer;
otherwise, it must return all bytes.
Targets are only required to return the bytes indicated by the byte enables. However, if a target
supports prefetching of data (see the Socket Service Specification) it must return all bytes regardless
of which byte enables are asserted. Prefetching should not be enabled if there are side effects, e.g.
data loss or a status change because of the access. A target should not return bytes not indicated by
the byte enables if reading those bytes has any side effects.
CardBus PC Card allows any contiguous or non-contiguous combination of byte enables. If no byte
enables are asserted, the target of the access must complete the transaction by asserting CTRDY#
and providing parity if a read request. The target of an access where no byte enables are asserted
must complete the current data phase without any permanent change. On a read transaction, this
means that data or status are not changed. If completing the access has no affect on the data or
status, then the target may complete the access by either providing data or not. The target (on a
read) must provide parity across CAD[31::0] and CCBE[3::0]# regardless of the state of the byte
enables. On a write transaction, the data is not stored but CPAR is valid.
However, some targets may not be able to properly interpret non-contiguous patterns (e.g. bridges
that interface to 8- and 16-bit slaves). If this occurs, a target (bus bridge) may optionally report an
illegal pattern as an asynchronous error (CSERR#) or, if capable, break the transaction into two 16-
bit transactions that are legal for the intended agent. On an I/O access, the target is required to
signal target-abort if unable to complete the entire access defined by the byte enables.
5.2.2.4 Bus Driving and Turnaround

A turnaround cycle is required on all signals that may be driven by more than one agent. The
turnaround cycle is required to avoid contention when one agent stops driving a signal and another
agent begins. This is indicated on the timing diagrams as two arrows pointing at each others' tail.
This turnaround cycle occurs at different times for different signals. For instance, CIRDY#,
CTRDY#, CDEVSEL#, and CSTOP# use the address phase as their turnaround cycle. CFRAME#,
CCBE[3::0]#, and CAD[31::00] use the IDLE cycle between transactions as their turnaround cycle.
The turnaround cycle for CBLOCK# occurs one clock after the current owner releases it. CPERR#
has a turnaround cycle on the fourth clock after the last data phase, which is three clocks after the
turnaround cycle for the CAD lines. An IDLE cycle is when both CFRAME# and CIRDY# are
negated (e.g., clock 9 in Figure 5-1).
All CAD lines must be driven to stable values during every address and data phase. Even byte
lanes not involved in the current data transfer must physically drive stable (albeit meaningless)
data onto the bus. The motivation is for parity calculations and to keep input buffers on byte lanes
not involved in the transfer from switching at the threshold level and more generally to facilitate
fast, metastability free latching. In power sensitive applications, it is recommended that, in the
interest of minimizing bus switching power consumption, byte lanes not being used in the current
bus phase should be driven with the same data as contained in the previous bus phase. In
applications that are not power sensitive, the agent driving the CAD lines may drive whatever it
desires on unused byte lanes. Parity must be calculated on all bytes regardless of the byte enables.
5.2.3 Bus Transactions

Timing diagrams show the relationship of significant signals involved in 32-bit transactions. When a
signal is drawn as a solid line, it is actively being driven by the current master or target. When a
signal is drawn as a dashed line, no agent is actively driving it. However, it may still be assumed
to contain a stable value if the dashed line is at the high rail. High-Z signals are indicated to have
indeterminate values when the dashed line is between the two rails (e.g., CAD or CCBE# lines).
When a solid line becomes a dotted line, it indicates the signal was actively driven and now is
High-Z. When a solid line makes a low to high transition and then becomes a dotted line, it
indicates the signal was actively driven high to precharge the bus, and then switched to the High-Z
state. The cycles before and after each transaction will be discussed in the arbitration section.
5.2.3.1 Read Transaction

Figure 5-1 illustrates a read transaction and starts with an address phase which occurs when
CFRAME# is asserted for the first time and occurs on clock 2. During the address phase
CAD[31::00] contain a valid address and CCBE[3::0]# contain a valid bus command.
CCLK
1 2 3 4 5 6 7 8 9
CFRAME#
CAD ADDRESS DATA-1 DATA-2 DATA-3
CCBE# BUS CMD BE#'s
DATA TRANSFER
DATA TRANSFER
DATA TRANSFER
CIRDY#
WAIT
WAIT
WAIT
CTRDY#
CDEVSEL#
ADDRESS DATA DATA DATA

PHASE PHASE PHASE PHASE
BUS TRANSACTION
Figure 5-1 CardBus PC Card Basic Read Operation
The first clock of the first data phase is clock 3. During the data phase CCBE# indicate which byte
lanes are involved in the current data phase. A data phase may consist of a data transfer and wait
cycles. The CCBE# output buffers must remain enabled (for both read and writes) from the first
clock of the data phase through the end of the transaction. This ensures CCBE# are not left floating
for long intervals.
The first data phase on a read transaction requires a turnaround-cycle (enforced by the target via
CTRDY#). In this case the address is valid on clock 2 and then the master stops driving CAD. The
earliest the target can provide valid data is clock 4. The target must drive the CAD lines following
the turnaround cycle when CDEVSEL# is asserted. Once enabled, the output buffers must stay
enabled through the end of the transaction. (This ensures CAD are not left floating for long
intervals.)
A data phase completes when data is transferred, which occurs when both CIRDY# and CTRDY#
are asserted on the same clock edge. (CTRDY# cannot be driven until CDEVSEL# is asserted.)
When either is negated a wait cycle is inserted and no data is transferred. As noted in the diagram,
data is successfully transferred on clocks 4, 6, and 8, and wait cycles are inserted on clocks 3, 5, and
7. The first data phase completes in the minimum time for a read transaction. The second data phase
is extended on clock 5 because CTRDY# is negated. The last data phase is extended because
CIRDY# was negated on clock 7.
The master knows at clock 7 that the next data phase is the last. However, because the master is not
ready to complete the last transfer (CIRDY# is negated on clock 7), CFRAME# stays asserted. Only
when CIRDY# is asserted can CFRAME# be negated, which occurs on clock 8.
5.2.3.2 Write Transaction

Figure 5-2 illustrates a write transaction. The transaction starts when CFRAME# is asserted for the
first time which occurs on clock 2. A write transaction is similar to a read transaction except no
turnaround cycle is required following the address phase because the master provides both address
and data. Data phases work the same for both read and write transactions.
CCLK
1 2 3 4 5 6 7 8 9
CFRAME#
CAD ADDRESS DATA-1 DATA-2 DATA-3
CCBE# BUS CMD BE#'s-1 BE#'s-2 BE#'s-3

DATA TRANSFER
DATA TRANSFER
DATA TRANSFER
CIRDY#
CTRDY#
WAIT
WAIT
WAIT
CDEVSEL#
ADDRESS DATA DATA DATA

PHASE PHASE PHASE PHASE
BUS TRANSACTION
Figure 5-2 CardBus PC Card Basic Write Operation
In Figure 5-2, the first and second data phases complete with zero wait cycles. However, the third
data phase has three wait cycles inserted by the target. Notice both agents insert a wait cycle on
clock 5. CIRDY# must be asserted when CFRAME# is negated indicating the last data phase.
The data transfer was delayed by the master on clock 5 because CIRDY# was negated. Although
this allowed the master to delay data, it did not allow the byte enables to be delayed. The last data
phase is signaled by the master on clock 6, but does not complete until clock 8.
5.2.3.3 Transaction Termination

Termination of a CardBus PC Card transaction may be initiated by either the master or the target.
While neither can actually stop the transaction unilaterally, the master remains in ultimate control,
bringing all transactions to an orderly and systematic conclusion regardless of what caused the
termination. All transactions are concluded when CFRAME# and CIRDY# are both negated,
indicating an IDLE cycle (e.g., clock 9 in Figure 5-2).
5.2.3.3.1 Master Initiated Termination

The mechanism used in master initiated termination is for CFRAME# to be negated when CIRDY#
is asserted. This signals the target that the final data phase is in progress. The final data transfer
occurs when both CIRDY# and CTRDY# are asserted. The transaction reaches completion when
both CFRAME# and CIRDY# are negated (IDLE bus condition).
The master may initiate termination using this mechanism for one of two reasons:
Completion refers to termination when the master has concluded its intended transaction. This is the most common
reason for termination.
Timeout refers to termination when the master's CGNT# line is negated and its internal Latency Timer has
expired. The intended transaction is not necessarily concluded. The timer may have expired because of
target induced access latency, or because the intended operation was very long. (See 5.2.5.3.1
Managing Latency on CardBus PC Card.)
A Memory Write and Invalidate transaction is not governed by the Latency Timer. A master that initiates
a transaction with the Memory Write and Invalidate command ignores the Latency Timer until a cache
line boundary. When the transaction reaches a cache line boundary and the Latency Timer has expired
(and CGNT# is negated), the master must terminate the transaction. If a Memory Write and Invalidate
transaction is terminated by the target, the master completes the transaction (the rest of the cache line)
as soon as possible (adhering to the CSTOP# protocol) using the Memory Write command (since the
conditions to issue Memory Write and Invalidate are no longer true).
A modified version of this termination mechanism allows the master to terminate the transaction
when no target responds. This abnormal termination is referred to as master-abort. Although it may
cause a fatal error for the application originally requesting the transaction, the transaction completes
gracefully, thus preserving normal CardBus PC Card operation for other agents.
Two examples of normal completion are shown in Figure 5-3.The final data transfer is indicated
when CFRAME# is negated and when both CIRDY# and CTRDY# are asserted which occurs at
clock 3. The bus reaches an IDLE condition when CIRDY# is negated which occurs on clock 4.
Because the transaction has completed, CTRDY# is negated on clock 4 also. Note that CTRDY# is
not required to be asserted on clock 3, but could have delayed the final data transfer (and
transaction termination) until it is ready by delaying the final assertion of CTRDY#. If the target
does that, the master is required to keep CIRDY# asserted until the final data transfer occurs.
CCLK
1 2 3 4 1 2 3 4
CGNT#
T/O
CFRAME#
T/O
CIRDY#
CTRDY#
Figure 5-3 CardBus PC Card Master Initiated Termination
Both sides of Figure 5-3 could have been caused by a timeout termination. On the left side,
CFRAME# is negated on clock 3 because the timer expires, CGNT# is negated, and the master is
ready (CIRDY# asserted) for the final transfer. Because CGNT# was negated when the timer
expired continued use of the bus is not allowed except when using the Memory Write and
Invalidate command, which must be stopped at the cache line boundary. Termination then proceeds
as normal. If CTRDY# is negated on clock 2, that data phase continues until CTRDY# is asserted.
CFRAME# and CIRDY# must remain asserted until the data phase completes.
The right-hand example shows a timer expiring on clock 1. Because the master is not ready to
transfer data (CIRDY# is negated on clock 2), CFRAME# is required to stay asserted. CFRAME# is
negated on clock 3 because the master is ready (CIRDY# is asserted) to complete the transaction on
clock 3. The master must be driving valid data (write) or be capable of receiving data (read)
whenever CIRDY# is asserted. This delay in termination should not be extended more than two or
three cycles. Also note that the Latency Timer has no meaning unless CGNT# is negated.
Master-abort termination, as shown in Figure 5-4, is an abnormal case (except for configuration or
Special Cycle commands) of master initiated termination. A master determines that there will be no
response to a transaction if CDEVSEL# remains negated on clock 6. (For a complete description of
CDEVSEL# operation, refer to the 5.2.7.1 Device Selection). The master must assume that the target
of the access is incapable of dealing with the requested transaction or that the address was bad.
Once the master has detected the missing CDEVSEL# (clock 6 in this example), CFRAME# is
negated on clock 7, and CIRDY# on clock 8. The earliest a master can terminate a transaction with
master-abort is five clocks after CFRAME# was first sampled asserted, which occurs when the
master attempts a single data transfer. However, the master may take longer to negate CFRAME#
and terminate the access. The master must support the CFRAME# − CIRDY# relationship on all
transactions which includes master-abort. CFRAME# cannot be negated before CIRDY# is asserted
and CIRDY# must remain asserted for at least one clock after CFRAME# is negated, even when the
transaction is terminated with master-abort.
Alternatively, CIRDY# could be negated on clock 7, if CFRAME# was negated as in the case of a
transaction with a single data phase. The master will normally not retry this access. (Refer to
5.2.8.2.2 Error Response and Reporting on CSERR#). Note that if CDEVSEL# had been asserted on
clocks 3, 4, 5, or 6 of this example, it would indicate the request had been acknowledged by an
agent, and master-abort termination would not be permissible.
The host bus bridge, in a PC compatible system, and any CardBus PC Card-to-CardBus PC Card
bridge must return all 1's on a read transaction and discard data on a write transaction when
terminated with master-abort. The bridge is required to set the master-abort detected field in its
status register. Other master devices may report this condition as an error by signaling CSERR#
when the master cannot report the error through its device driver. Prefetching of read data by a
bridge must be totally transparent to the system. This means that when a prefetched transaction is
terminated with master-abort, the bridge must simply stop the transaction and continue normal
operation without reporting. This occurs when a transaction is not claimed by a target.
CCLK
1 2 3 4 5 6 7 8
CFRAME#
CIRDY#
CTRDY#
NO RESPONSE
CDEVSEL# FAST MED SLOW SUB
ACKNOWLEDGE
Figure 5-4 CardBus PC Card Master-abort Termination
In summary, the following general rules govern CFRAME# and CIRDY# in all CardBus PC Card
transactions.
1. CFRAME# and its corresponding CIRDY# define the busy/IDLE state of the bus: when either
is asserted, the bus is busy; when both are negated, the bus is IDLE.
2. Once CFRAME# has been negated, it cannot be reasserted during the same transaction.
3. CFRAME# cannot be negated unless CIRDY# is asserted. (CIRDY# must always be asserted on
the first clock edge that CFRAME# is negated.)
4. Once a master has asserted CIRDY#, it cannot change CIRDY# or CFRAME# until the current
data phase completes.
5.2.3.3.2 Target Initiated Termination

The mechanism used in target initiated termination is the CSTOP# signal. The target asserts
CSTOP# to request that the master terminate the transaction. Once asserted, CSTOP# remains
asserted until CFRAME# is negated. The relationship between CIRDY# and CTRDY# is
independent of the relationship between CSTOP# and CFRAME#. That is, data may or may not be
transferred during the target's request for termination; this depends solely on the state of CIRDY#
and CTRDY#. However, when CSTOP# is asserted and CTRDY# is negated, it indicates the target
will not transfer any more data, and the master therefore does not wait for a final data transfer as it
would in a completion termination.
The target may initiate termination using this mechanism for one of two reasons:
Retry refers to termination requested because the target is currently in a state which makes it unable to process
the transaction. This may include the possibility of deadlock, some non-CardBus PC Card resource busy
condition, or an exclusive access locked condition. Retry means the target terminates the transaction and
no data was transferred.
Disconnect refers to termination requested because the target is unable to respond within the latency guidelines of
CardBus PC Card (which is four CardBus PC Card clocks). Note that this is not usually done on the first
data phase (refer to 5.2.5.3.1 Managing Latency on CardBus PC Card). Disconnect means the target
terminated the transaction with or after the data that was transferred.
Cacheable targets must not disconnect a Memory Write and Invalidate command except at cache line
boundaries, whether caching is currently enabled or not. Therefore, a snooping agent may always
assume a Memory Write and Invalidate command will complete without being disconnected when the
access is to a cacheable memory range.
A modified version of this mechanism allows the target to terminate a transaction in which a fatal
error has occurred, or to which the target will never be able to respond. This abnormal termination
is referred to as target-abort. Although it may cause a fatal error for the application originally
requesting the transaction, the transaction completes gracefully, thus preserving normal CardBus
PC Card operation for other agents.
Most targets will be required to implement at least retry capability, but any other versions of target
initiated termination are optional for targets. Masters must be capable of properly dealing with
them all. Retry is also optional to very simple targets that 1) do not support exclusive (locked)
accesses, 2) cannot detect possible deadlock or livelock conditions, and 3) cannot get into a state
where they may need to reject an access.
Three examples of disconnect are shown in Figure 5-5. Each example shows the same relationship
between CSTOP# and CFRAME#, namely that:
• Disconnect is signaled when CSTOP# is asserted and is held asserted until CFRAME#
is negated.
• CFRAME# is negated as soon as possible after CSTOP# is asserted. Example C shows
this taking an extra cycle because CIRDY# could not be asserted immediately after
CSTOP# was asserted.
• CSTOP# is negated the cycle immediately following CFRAME# being negated.
In addition, these three disconnect examples show that CDEVSEL# is always asserted when
CSTOP# is asserted; otherwise, a target-abort is indicated.
These three examples show three different possibilities for data transfer in association with a
disconnect. Notice that the target can determine whether or not data is transferred after CSTOP# is
asserted. Data transfer takes place on every cycle where both CIRDY# and CTRDY# are asserted,
independent of the state of CSTOP#. If the target wants to do one more data transfer and then stop,
it asserts CTRDY# and CSTOP# at the same time.
In Figure 5-5, examples A and B show two different disconnects where data is transferred after
CSTOP# is asserted. In both cases, the target declares its intent to do another data transfer by
having CTRDY# asserted at the time CSTOP# is asserted. In example A, the data is transferred
after CFRAME# is negated (on clock 3) because the master was not ready (CIRDY# negated on
clock 2).
In example B, the data is transferred before CFRAME# is negated (on clock 2). If CTRDY# was
asserted when CSTOP# was asserted, CTRDY# must be negated when the current data phase
completes. The target cannot negate CSTOP# and continue the transaction. A master restarts any
transaction terminated with retry or disconnect at a later time starting with the address of the next
untransferred data. The target, upon detecting that data was transferred, removes CTRDY# since it
intends to transfer no more data. Notice that this means no data is transferred in the final data
phase. If the target had kept CTRDY# asserted during clock 3, and delayed the assertion of
CSTOP# until clock 3, then data would have been transferred on both clock 2 and clock 3.
However, the target cannot complete more than one data transfer after CSTOP# is asserted, as is
demonstrated by example A.
Once CSTOP# is asserted, it must stay asserted until CFRAME# is negated. If the target requires a
wait cycle in the last data phase, it must delay the assertion of CSTOP# until it is ready to complete
the transaction.
Example C shows a case in which data is not transferred after CSTOP# is asserted because CTRDY#
is negated. Note that in this example, the negation of CFRAME# is delayed until CIRDY# could be
asserted. This is also an example of retry, which is actually a special case of disconnect where no
data transfer occurs at all. A common example of retry is when the target is currently locked for
exclusive access by another master. Another example is when the target needs to acquire access to
some other non-CardBus PC Card resource before allowing the transaction to proceed. (Care needs
to be taken in this case to ensure that there are no conditions where the retry itself could generate a
deadlock condition.) The master must negate its CREQ# signal when the current transaction is
terminated by the target. The master must negate CREQ# for a minimum of two CardBus PC Card
clocks, one being when the bus goes to the IDLE state (at the end of the transaction where CSTOP#
was asserted) and either the clock before or the clock after the IDLE state. If the master intends to
complete the transaction, it must reassert its CREQ# immediately following the two clocks it was
negated or a potential starvation condition may occur. If the master does not intend to complete the
transaction (because it was prefetching or a higher priority internal request needs to be serviced),
the agent only asserts CREQ# whenever it needs to use the interface again.
The lower right example in Figure 5-5 shows target-abort, which is when CSTOP# is asserted and
CDEVSEL# is negated. This indicates the target requires the transaction to be terminated and
doesn't want the transaction tried again. Additionally, if any data has already been transferred in
the current transaction, it may have been corrupted. (Refer to 5.2.8.2.2 Error Response and
Reporting on CSERR#). CDEVSEL# must be asserted for one or more clock cycles and CTRDY#
must be negated before target-abort can be signaled.
CCLK
1 2 3 4 1 2 3 4
CFRAME#
CIRDY#
CTRDY#
CSTOP#
CDEVSEL#
Disconnect - A Disconnect - B
CCLK
1 2 3 4 5 1 2 3 4
CFRAME#
CIRDY#
CTRDY#
CSTOP#
CDEVSEL#
Disconnect - C / Retry Target-Abort

Figure 5-5 Target Initiated Termination
In summary, the following general rules govern CFRAME#, CIRDY#, CTRDY#, and CSTOP# in
all CardBus PC Card transactions.
1. Whenever CSTOP# is asserted, CFRAME# must be negated as soon as possible pursuant to the
rules for the negation of CFRAME# (i.e., CIRDY# must be asserted). The negation of
CFRAME# should occur as soon after CSTOP# is asserted as possible, preferably within two or
three cycles. The target must not assume any timing relationship between CSTOP# assertion
and CFRAME# negation, but must keep CSTOP# asserted until CFRAME# is negated. When
the master samples CSTOP# asserted, it must negate CFRAME# on the first cycle thereafter in
which CIRDY# is asserted. This assertion of CIRDY# (and therefore CFRAME# negation) may
occur as a consequence of the normal CIRDY# behavior of the master (had the current
transaction not been target terminated), and be delayed zero or more cycles depending on
when the master is prepared to complete a data transfer. Alternatively, the master may assert
CIRDY# immediately (even without being prepared to complete a data transfer) if CTRDY# is
negated, thus indicating there will be no further data transfer.
2. Once asserted, CSTOP# must remain asserted until CFRAME# is negated, whereupon,
CSTOP# must be negated.
3. During the final data phase of a transaction (CFRAME# negated and CIRDY# asserted), any
clock edge on which either CSTOP# or CTRDY# is asserted becomes the last cycle of the
transaction, and CIRDY# is negated on the following clock edge. (This creates an IDLE cycle
and defines the end of the transaction.)
4. The master must retry an access that was target terminated (except target-abort) with the
address of the next untransferred data if it intends to complete the access. If the device was
prefetching, it may elect not to retry the access.
5. Once a target has asserted CTRDY# or CSTOP#, it cannot change CDEVSEL#, CTRDY#, or
CSTOP# until the current data phase completes.
5.2.4 Arbitration
In order to minimize access latency, the CardBus PC Card arbitration approach is access based
rather than time slot based. That is, a bus master must arbitrate for each access it performs on the
bus. CardBus PC Card uses a central arbitration scheme, where each master agent has unique
request (CREQ#) and grant (CGNT#) signals. A simple request-grant handshake is used to gain
access to the bus. Arbitration is "hidden", which means it occurs during the previous access so that
no CardBus PC Card bus cycles are consumed due to arbitration, except when the bus is IDLE.
A specific arbitration algorithm must be implemented by the central arbiter, e.g., rotating priority,
fair, etc. Since the arbitration algorithm is fundamentally not part of the bus specification, system
designers may elect to modify it, but must provide for the latency requirements of their selected
I/O controllers and for add-in cards. Refer to 5.2.5.3.2 Low Latency Design Guidelines for
information on latency guidelines. The bus allows back-to-back transactions by the same agent and
allows flexibility for the arbiter to prioritize and weight requests. An arbiter can implement any
scheme as long as only a single CGNT# is asserted on any clock.
5.2.5 Arbitration Signaling Protocol

An agent requests the bus by asserting its CREQ#. Agents must use CREQ# only to signal a true
need to use the bus. An agent must never use CREQ# to "park" itself on the bus. When the arbiter
determines an agent may use the bus, it asserts the agent's CGNT#.
The arbiter may negate an agent's CGNT# on any clock. An agent must ensure its CGNT# is
asserted on the clock edge it wants to start a transaction. If CGNT# is negated, the transaction must
not proceed. Once asserted, CGNT# may be negated according to the following rules.
1. If CGNT# is negated and CFRAME# is asserted, the bus transaction is valid and will continue.
2. One CGNT# can be negated coincident with another CGNT# being asserted if the bus is not in
the IDLE state. Otherwise, a one clock delay is required between the negation of a CGNT# and
the assertion of the next CGNT#, or else there may be contention on the CAD lines and CPAR.
(This refers to internal arbitration conditions in a CardBus PC Card adapter while requests are
present from the system bus and a card or from multiple cards.)
3. While CFRAME# is negated, CGNT# may be negated at any time in order to service a higher
priority11 master, or in response to the associated CREQ# being negated.
Figure 5-6 illustrates basic arbitration. Two agents (e.g., two cards supported by the same CardBus
PC Card adapter) are used to illustrate how an arbiter may alternate bus accesses.
CCLK
1 2 3 4 5 6 7
CREQ#-a
CREQ#-b
CGNT#-a
CGNT#-b
CFRAME#
CAD ADDRESS DATA ADDRESS DATA
access - A access - B
Figure 5-6 CardBus PC Card Basic Arbitration
CREQ#-a is asserted prior to or at clock 1 to request use of the interface. Agent A is granted access to
the bus because CGNT#-a is asserted at clock 2. Agent A may start a transaction at clock 2 because
CFRAME# and CIRDY# are negated and CGNT#-a is asserted. Agent A's transaction starts when
CFRAME# is asserted on clock 3. Since agent A desires to perform another transaction, it leaves
CREQ#-a asserted.
When CFRAME# is asserted on clock 3, the arbiter determines agent B should go next and asserts
CGNT#-b and negates CGNT#-a on clock 4.
When agent A completes its transaction on clock 4, it relinquishes the bus. CardBus PC Card agents
can determine the end of the current transaction when both CFRAME# and CIRDY# are negated.
Agent B becomes the owner on clock 5 (because CFRAME# and CIRDY# are negated) and
completes its transaction on clock 7.
Notice that CREQ#-b is negated and CFRAME# is asserted on clock 6 indicating agent B requires
only a single transaction. The arbiter grants the next transaction to agent A because its CREQ# is
still asserted.
The current owner of the bus keeps CREQ# asserted when it requires additional transactions. If no
other requests are asserted or the current master has highest priority, the arbiter continues to grant
the bus to the current master.
CGNT# gives an agent access to the bus for a single transaction. If an agent desires another access,
it should continue to assert CREQ#. An agent may negate CREQ# anytime, but the arbiter may
interpret this to mean the agent no longer requires use of the bus and may negate its CGNT#. An
agent should negate CREQ# in the same clock CFRAME# is asserted if it only wants to do a single
11 Higher priority here does not imply a fixed priority abitration, but refers to the agent that would win arbitration
at a given instant in time.
transaction. When a transaction is terminated by a target (CSTOP# asserted), the master must
negate its CREQ# for a minimum of two CardBus PC Card clocks, one being when the bus goes to
the IDLE state (at the end of the transaction where CSTOP# was asserted) and either the clock
before or the clock after the IDLE state. If the master intends to complete the transaction, it must
reassert its CREQ# following the negation of CREQ# or a potential starvation condition may occur. If
the master does not intend to continue (because it was prefetching or a higher priority internal
request needs to be serviced), the agent asserts CREQ# whenever it needs to use the interface
again. This allows another agent to use the interface while the previous target prepares for the next
access.
The arbiter can assume the current master is broken if it has not started an access after its CGNT#
has been asserted (its CREQ# is also asserted), and the bus is IDLE for eight CardBus PC Card
clocks. However, the arbiter may remove CGNT# at any time to service a higher priority agent.
5.2.5.1 Fast Back-to-Back Transactions

There are two types of fast back-to-back transactions that can be initiated by the same master, those
that access the same agent and those that do not. Fast back-to-back transactions are allowed on
CardBus PC Card when contention on CTRDY#, CDEVSEL#, or CSTOP# is avoided.
The first type of fast back-to-back support places the burden of avoiding contention on the master,
while the second places the burden on all potential targets. The master may remove the IDLE cycle
between transactions when it can guarantee that no contention occurs. This can be accomplished
when the master's second transaction is to the same target as the first and the first transaction is a
write. This type of fast back-to-back transaction requires the master to understand the address
boundaries of the potential target, otherwise contention may occur. This type of fast back-to-back is
optional for a master but must be decoded by a target.
The second type of fast back-to-back support places the burden of no contention on all potential
targets. The Fast Back-to-Back Capable field in the Status register may be hardwired to a logical one
(high) if and only if the device, while acting as a bus target, meets the following two requirements:
1. The target must not miss the beginning of a bus transaction, nor lose the address, when that
transaction is started without a bus IDLE state preceding the transaction. In other words, the
target is capable of following a bus state transition from a final data transfer (CFRAME# high,
CIRDY# low) directly to an address phase (CFRAME# low, CIRDY# high) on consecutive clock
cycles. Note that the target may or may not be selected on either or both of these transactions,
but must track bus states nonetheless.
2. The target must avoid signal conflicts on CDEVSEL#, CTRDY#, and CSTOP#. If the target does
not implement the fastest possible CDEVSEL# assertion time, this guarantee is already
provided. For those targets that do perform zero wait state decodes, the target must delay
assertion of these three signals for a single clock, except in either one of the following two
conditions:
a. The current bus transaction was immediately preceded by a bus IDLE state. That is, this is not a
back-to-back transaction, or,
b. The current target had driven CDEVSEL# on the previous bus transaction. That is, this is a back-
to-back transaction involving the same target as the previous transaction.
For masters that want to perform fast back-to-back transactions that are supported by the target
mechanism, the Fast Back-to-Back Enable field in the Command register is required. (This optional
field is only meaningful in devices that act as bus masters.) It is a read/write field when
implemented. When set to a one (high), the bus master may start a CardBus PC Card transaction
using fast back-to-back timing without regard to which target is being addressed, provided the
previous transaction was a write transaction issued by the current bus master. If this field is set to a
zero (low) or not implemented, the master may perform fast back-to-back only if it can guarantee
that the new transaction goes to the same target as the previous one (master based mechanism).
This field would presumably be set by the system configuration routine, after ensuring that all
targets on the same bus had the Fast Back-to-Back Capable field set.
Note that the master based fast back-to-back mechanism does not allow these fast cycles to occur
with separate targets, while the target based mechanism does.
If the target is unable to provide both of the guarantees specified above, it must not implement this
field and it will automatically be returned as a zero when the Status register is read. However, it is
recommended that all targets implement the target based fast back-to-back capability.
Under all other conditions, the master must insert a minimum of one IDLE bus state. (There is
always at least one IDLE bus state between transactions by different masters.) Note multi-ported
targets should only lock themselves when they are truly locked during fast back-to-back
transactions (refer to 5.2.6 Exclusive Access for more information).
During a fast back-to-back transaction, the master starts the next transaction immediately without an
IDLE bus state. The last data phase completes when CFRAME# is negated, and CIRDY# and
CTRDY# are asserted. The current master starts another transaction on the same clock the last data
is transferred for the previous transaction.
It's important to note that agents not involved in a fast back-to-back transaction sequence cannot
(and generally need not) distinguish intermediate transaction boundaries using only CFRAME#
and CIRDY# (there is no bus IDLE cycle). During fast back-to-backs only, the master and target
involved need to distinguish these boundaries. When the last transaction is over, all agents will see
an IDLE cycle. However, those that do support the target based mechanism must be able to
distinguish the completion of all CardBus PC Card transactions and be able to detect all address
phases.
In Figure 5-7, the master completes a write on clock 3 and the address phase of the next transaction
occurs on clock 4. The target must begin sampling CFRAME# on the clock following the completion
of the current data transaction. Targets must be able to decode back-to-back operations while a
master may optionally support this function. A target is free to retry the request after it has claimed
ownership by asserting CDEVSEL#.
CCLK
1 2 3 4 5 6 7
CREQ#
CGNT#
CFRAME#
CIRDY#
CTRDY#
Figure 5-7 Arbitration for Back-to-Back Access
5.2.5.2 CardBus PC Card Idle Condition

The CardBus PC Card central resource, typically embedded in the host CardBus PC Card adapter, is
the default owner of the interface. When no agent is using or requesting the bus, the central
resource ensures that the CardBus PC Card signals are in stable states and prevented from floating.
When the bus becomes IDLE and no CGNT# is asserted, the central resource must enable its
CAD[31::00], CCBE[3::0]#, and (one clock later) CPAR output buffers within eight CardBus PC Card
clocks, while two or three clocks is recommended. (Refer to parity discussion for description of
timing relationship of CPAR to CAD.) The central resource is not required to turn on all buffers in a
single clock. However, if the host system supports the Clock Control Protocol (refer to 5.2.10 Clock
Control), the central resource must enable its CAD[31::00], CCBE[3::0]#, and CPAR output buffers
before stopping the CardBus PC Card clock. Refer to 5.3 CardBus PC Card Electrical Specification
for a description of how to maintain valid levels on other CardBus PC Card signals.
The CardBus PC Card arbiter must not assert CGNT# to an agent located on a PC Card unless
CREQ# is asserted by the agent. Note that the default owner of the interface, the central resource or
the CardBus PC Card adapter, may start a transaction at any time while it owns the bus (provided
that the clock is not stopped).
Given the above, minimum arbitration latency achievable on CardBus PC Card from bus IDLE is as
follows:
• Driven by the adapter: zero clocks for adapter, two clocks for others
• Not driven: one clock
5.2.5.3 Latency
CardBus PC Card is a low latency, high throughput interface. This section describes the CardBus PC
Card mechanisms that help control worst case latency. Although latencies in a stand alone CardBus
PC Card environment can be predicted with relatively high precision, the inclusion of a standard
expansion bus (ISA, EISA, MC, or NuBus), and other system effects, make latency prediction
much more difficult.
5.2.5.3.1 Managing Latency on CardBus PC Card

Figure 5-8 depicts the different time components that a device sees as part of access latency. The first
portion, arbitration latency, is the time that the master waits after having asserted CREQ# until it
receives CGNT#. This time is a function of the arbitration algorithm, the priority of the requesting
device, and system utilization. For the highest priority device, this time, typically, will be two
CardBus PC Card clocks. The next component, bus acquisition latency, is how long the device has to
wait for the bus to become free. The last component, target latency, is the amount of time that the
target takes to assert CTRDY# for the first data transfer.
Master asserts Master receives Master asserts Target asserts

CREQ# CGNT# CFRAME# TRDY#
Arbitration Latency Bus Acquisition Latency Target Latency
Figure 5-8 Components of Access Latency
A CardBus PC Card master can burst indefinitely so long as the target can source/sink the data,
and no other agent requests the bus. However, CardBus PC Card specifies two mechanisms that cap
a master's tenure in the presence of other requests, so that predictable bus acquisition latency can be
achieved. These are defined as follows:
Master Latency Timer (LT): Each master's LT is cleared and suspended whenever it is not
asserting CFRAME#. When a master asserts CFRAME#, it enables its LT to count. If the master
negates CFRAME# prior to count expiration, LT is meaningless. Otherwise, once the count
expires (count = "T" clocks), the master must initiate transaction termination (refer to 5.2.3.3.1
Master Initiated Termination) as soon as its CGNT# is removed. In essence, "T" represents a
minimum guaranteed time slice (measured in CardBus PC Card clocks) allotted to the master,
after which it must surrender tenure as soon as its CGNT# is removed. (Actual termination does
not occur until the target is ready.)
Target Initiated Termination (Specifically Disconnect): A target must manipulate CTRDY# and
CSTOP# so as to end the transaction upon consummation of data phase "N" (where N=1, 2, 3,
...), if incremental latency to data phase "N+1" is greater than eight clocks. For example, assume
a CardBus PC Card master read from a target takes a minimum of eight clocks. Applying the
rule for N = 1, the latency to data phase 2 is eight clocks, thus the target must terminate upon
completion of data phase 1 (i.e., a target this slow must break attempted bursts on data phase
boundaries).
Note that neither mechanism restricts latency to the first data phase. (See also 5.2.5.3.2 Low Latency
Design Guidelines). For example, assume that in a particular system, there is no target so slow that it
delays CTRDY# by more than T+8 clocks for the first data phase to complete. Given this
assumption and the mechanisms above, it can be shown that the longest transaction the master will
execute is T+8 clocks (assuming its CGNT# is removed before its LT expires).
In effect, T represents a trade-off between throughput (relatively high values) and latency (low
values). For example, T = 40 accommodates a burst of 32 data phases (128 bytes in a 32-bit/clock
transaction) if both master and target are capable of 0 wait cycle bursts (assuming an eight clock
latency to first data). Reducing T to 20 would likely break the burst every 12 to 14 transfers, but
would constrain the maximum transaction to 28 clocks.
5.2.5.3.2 Low Latency Design Guidelines

CardBus PC Card accommodates both throughput and latency sensitive devices. On occasion,
unusually long accesses are tolerable as long as typical latency is short. CardBus PC Card features
such as unlimited length bursts (for high bandwidth block I/O) favor such high throughput
devices. On the other hand, a 10 Mbits/second LAN device consumes a small fraction of CardBus
PC Card bandwidth. To keep such a device economical (minimize data buffer requirements),
CardBus PC Card features like access-based arbitration and master Latency Timers help to bound
worst case latency. For example, a buffered FDDI device, otherwise capable of a 128-DWORD burst
in a single access, can be forced by its Latency Timer to break the transfer into several small pieces,
allowing shallow-buffer, latency sensitive devices access to the bus more often. High throughput
and low latency are often at odds with one another. Accordingly, it is important that CardBus PC
Card components and systems be intelligently designed to minimize risk of latency-related
interoperability problems, and to facilitate reasonable price/performance trade-offs.
To facilitate such designs, and, in general, to encourage good design practices, the guidelines listed
below are recommended for target interface design. In the following, "single layer" refers to a
CardBus PC Card target that provides immediate access to the selected resource, i.e., a single port
memory. "Multi-layer" refers to a target that must acquire an independently arbitrated resource to
provide access to the selected resource, i.e., CardBus PC Card-to-bus bridges (e.g., CardBus PC
Card-to-CardBus PC Card, CardBus PC Card-to-Host Memory, etc.) or dual port memory.
1. Single layer targets should constrain first data phase latency to sixteen clocks. If a temporary
internal state (e.g., DRAM refresh, full queue of previously posted writes) would otherwise
stretch the access beyond eight clocks, retry immediately.
2. Multi-layer targets should retry an access that collides with a busy resource. For example, an
access to a system bus slave while the system bus is owned by another master should be
immediately retried. (The cycle would likely have to be retried anyhow to avoid deadlock, so
why wait?) Likewise, an access to a DRAM frame buffer currently consumed by screen refresh
should be retried.
3. Multi-layer targets (especially bus-to-bus bridges) should exercise great care in write buffer
strategy. Write buffers make it difficult to bound latency, since strong ordering requirements
typically mandate that all writes queued to a bus be completed before an access going the other
way is allowed.
To facilitate making sound system level tradeoffs, component vendors should clearly document
device latency behavior. (A common tradeoff is to disallow specific ill-behaved standard bus
adapters in a real-time application.) Master devices should spell out both latency expectations and
the consequences of latency violation. Target devices should specify worst case response, as well as
all events that can cause a retry or disconnect. If a target's latency is paced by external factors (e.g.,
how long an ISA adapter stretches a cycle) this should be clearly stated.
5.2.6 Exclusive Access

CardBus PC Card provides a non-blocking exclusive access mechanism which allows non-exclusive
accesses to proceed in the face of exclusive accesses. This is referred to as a resource lock, and allows
an agent to hold a hardware lock across several accesses without interfering with non-exclusive,
real-time data transfer, such as video. The mechanism is based on locking only the CardBus PC
Card resource to which the original locked access was targeted. This mechanism is fully compatible
with existing software exclusion techniques used on devices implementing a bus lock. The CardBus
PC Card exclusive access model supports read-modify-write operations.
CBLOCK# is required on any device providing system memory. Specifically, if the device
implements shared memory, then it must also implement CBLOCK#, and guarantee complete
access exclusion in that memory, i.e., if there is a master local to that memory, it must also honor the
lock. Host CardBus PC Card bridges that have system memory behind them must also implement
CBLOCK#.
The CBLOCK# signal indicates an exclusive access is underway. The assertion of CGNT# does not
guarantee control of CBLOCK#. Control of CBLOCK# is obtained under its own protocol in
conjunction with CGNT#. When using a resource lock, agents performing non-exclusive accesses are
free to proceed even while another master retains ownership of CBLOCK#. However when
compatibility dictates, the arbiter can optionally convert a resource lock into a bus lock by granting
the agent that owns CBLOCK# exclusive access of the bus until CBLOCK# is released. Refer to
5.2.6.6 Complete Bus Lock for more details.
In a resource lock, exclusivity of an access is guaranteed by the target of the access, not by excluding
all other agents from accessing the bus. The granularity of the lock is defined to be the length of the
initial exclusive read transaction. The master cannot rely on any addresses outside the initial read
range to be locked. A target is required to lock as minimum the address range read by the master
in the initial exclusive read transaction and up to a maximum of the entire resource.
A target that supports CBLOCK# on CardBus PC Card must adhere to the following rules:
1. The target of an access locks itself when CBLOCK# is negated during the address phase.
2. Once lock is established, the target remains locked until it samples both CFRAME# and
CBLOCK# negated together or it signals target-abort.
3. The target guarantees exclusivity to the owner of CBLOCK# (once lock is established) of at least
the number of bytes read in the initial exclusive access.12 This includes accesses that do not
originate on CardBus PC Card for multiport devices.
All CardBus PC Card targets that support exclusive accesses must sample CBLOCK# with address.
If the target of the access performs medium or slow decode, it must latch CBLOCK# during the
address phase to determine if the access is a lock operation when decode completes. The target of a
transaction marks itself locked if CBLOCK# is negated during the address phase. If a target waits to
sample CBLOCK# until it asserts CDEVSEL#, it cannot distinguish if the current access is a locked
transaction or one that occurs concurrently with a locked access. An agent may store "state" to
determine if the access is locked but this requires latching CBLOCK# on consecutive clocks and
comparing to determine if the access is locked. The simpler way is for the target to mark itself
locked on any access it claims where CBLOCK# is negated during the address phase. A locked
target remains in the locked state until both CFRAME# and CBLOCK# are negated. To allow other
accesses to a multiport device, the target may sample CBLOCK# the clock following the address
phase to determine if the device is really locked. When CBLOCK# is negated during the address
phase and is asserted the clock following the address phase, the multiport device is locked and must
ensure exclusivity to the CardBus PC Card master. When CBLOCK# is negated during the address
phase and the clock following the address phase, the target is not locked, and is free to respond to
other requests. A currently locked target may only accept requests when CBLOCK# is negated
during the address phase. A currently locked target will respond by asserting CSTOP# with
CTRDY# negated (retry) to all transactions when CBLOCK# is asserted during the address phase.
To summarize, a target of an access locks itself on any access it claims when CBLOCK# is negated
during the address phase. It unlocks itself anytime CFRAME# and CBLOCK# are both negated. It
may seem confusing for the target to lock itself on a transaction that is not locked. However, from an
implementation point of view, it is a simple mechanism that uses combinatorial logic and always
works. The device will unlock itself at the end of the transaction when it detects CFRAME# and
CBLOCK# both negated. A target can also remember state (which is useful for a multiport device)
to determine if it is truly locked or not. The target is truly locked when CBLOCK# is negated
during the address phase and asserted on the following clock.
The arbiter must be in some type of "fairness" algorithm when CBLOCK# is asserted; otherwise, a
livelock may occur.
Existing software that does not support the CardBus PC Card lock usage rules has a potential of not
working correctly. CardBus PC Card resident memory that supports CBLOCK# and desires to be
backward compatible to existing software is recommended to implement complete resource lock.
Refer to 5.2.6.5 Supporting CBLOCK# and Write-back Cache Coherency for details of how to avoid
deadlocks.
A master that uses CBLOCK# on CardBus PC Card must adhere to the following rules:
1. A master can access only a single resource during a lock operation.
2. A lock cannot straddle a device boundary.
3. First transaction of lock operation must be a read transaction.
4. Only the address range accessed in the initial read can be assumed to be locked.
5. CBLOCK# must be asserted the clock following the address phase and kept asserted to
maintain control.
12 The maximum is the complete resource.
6. CBLOCK# must be released if retry is signaled before a data phase has completed and the lock
has not been established.13
7. CBLOCK# must be released whenever an access is terminated by target-abort or master-abort.
8. CBLOCK# must be negated for a minimum of one IDLE cycle between consecutive lock
operations.
Since different processors and system architectures support different, and often incompatible,
exclusion protocols, both software and hardware designers should use only generally accepted,
compatible constructs. Given the nature of a resource lock, the bus protocol will ensure that correctly
written software exclusion algorithms will function over CardBus PC Card. Other system constraints,
such as processor protocols and other system busses, however, make it only possible to guarantee
that read-and-set operations (a read-modify-write where the data bits are all 1's) are universally
accepted by the systems. This is sufficient to implement semaphores, and thus to implement all
other forms of exclusion in software.
Furthermore, it is an unreasonable burden, not to mention a potentially significant performance
degradation, to ensure that arbitrary transaction combinations under lock operate correctly. Based
on this, the following rules are defined for transactions initiated by a bus master residing on a
CardBus PC Card:
1. First transaction of an exclusive access must be a Memory Read transaction14.
2. An exclusive sequence may contain only one Memory Write transaction.
3. If an exclusive sequence includes a Memory Write, then the Memory Write must be the last
transaction.
4. All Memory Read and Memory Write transactions must be DWORD aligned.
5. If an exclusive sequence contains multiple Memory Read transactions, and ends with a Memory
Write transaction, then the write is not guaranteed to be atomic with respect to any of the
Memory Reads.
These rules should not be construed as defining the only behavior for exclusive accesses allowed in
a system. However, a card designer cannot assume that the system supports other transaction
sequences for exclusive operations.
5.2.6.1 Starting an Exclusive Access

When an agent needs to do an exclusive operation, it checks the internally tracked state of
CBLOCK# before asserting CREQ#. The master marks CBLOCK# busy anytime CBLOCK# is
asserted and not busy when both CFRAME# and CBLOCK# are negated. If CBLOCK# is busy, the
agent should delay the assertion of CREQ# until CBLOCK# is available.
While waiting for grant, the master continues to monitor CBLOCK#. If CBLOCK# is ever busy, the
master negates CREQ#, because another agent has gained control of CBLOCK#.
When the master is granted access to the bus and CBLOCK# is not busy, ownership of CBLOCK#
has occurred. The master is free to perform an exclusive operation when the current transaction
completes and is the only agent on the bus that can drive CBLOCK#. Any other agent must not
drive CBLOCK#, even when it is the current master.
13Once lock has been established, the master retains ownership of CBLOCK# when terminated with retry or
disconnect.
14Note that any one command, Memory Read, Memory Read Line, or Memory Read Multiple, represents a single
transaction. However, prefetching is not recommended for the command which establishes an exclusive access to
a target unless a complete resource lock is implemented.
Figure 5-9 illustrates starting an exclusive access. CBLOCK# is negated during the address phase to
request a lock operation which must be initiated with a read command. CBLOCK# must be asserted
the clock following the address phase, which is on clock 3, to keep the target in the locked state
which allows the current master to retain ownership of CBLOCK# beyond the end of the current
transaction.
CCLK
1 2 3 4 5
CFRAME#
CBLOCK#
CAD ADDRESS DATA
CIRDY#
CTRDY#
Figure 5-9 CardBus PC Card Starting an Exclusive Access
A locked operation is not established on the bus until completion of the first data phase of the first
transaction (CIRDY# and CTRDY# asserted). If the target retries the first transaction without a data
phase completing, not only must the master terminate the transaction but it must also release
CBLOCK#. Once the first data phase completes, the exclusive operation is established, and the
master keeps CBLOCK# asserted until either the lock operation completes or an error (master- or
target-abort) causes an early termination. Target termination by retry or disconnect is a normal
termination even when a lock operation is established. When a master is terminated by the target
with disconnect or retry after the lock has been established, the target is indicating it is currently
busy and unable to complete the requested data phase. The target will accept the access when it is
not busy and continue to honor the lock by excluding all other accesses. The master continues to
control CBLOCK#. Non-exclusive accesses to unlocked targets on CardBus PC Card are allowed to
occur while CBLOCK# is asserted. When the exclusive access is complete, CBLOCK# is negated
and other masters may vie for ownership.
5.2.6.2 Continuing an Exclusive Access

Figure 5-10 shows a master continuing an exclusive access. However, this access may or may not
complete the exclusive operation. When the master is granted access to the bus, it starts another
exclusive access to the target it previously locked. CBLOCK# is negated during the address phase
to re-establish the lock. The locked device accepts and responds to the request. CBLOCK# is
asserted on clock 3 to keep the target in the locked state and allow the current master to retain
ownership of CBLOCK# beyond the end of the current transaction.
When the master is continuing the lock operation, it continues to assert CBLOCK#. When the
master completes the lock operation, it negates CBLOCK# after the last data phase which occurs on
clock 5 (refer to 5.2.6.4 Completing an Exclusive Access for more information on completing an
exclusive access).

CCLK
1 2 3 4 5
CFRAME#
Release
CBLOCK# Continue
CAD ADDRESS DATA
CIRDY#
CTRDY#
Figure 5-10 CardBus PC Card Continuing an Exclusive Access
5.2.6.3 Accessing a Locked Agent

Figure 5-11 shows a master trying a non-exclusive access to a locked agent. When CBLOCK# is
asserted during the address phase, and if the target is locked, it signals retry and no data is
transferred. An unlocked target ignores CBLOCK# when deciding if it should respond. Also, since
CBLOCK# and CFRAME# are asserted during the address phase, an unlocked target does not go
into a locked state.
CCLK
1 2 3 4 5
CFRAME#
CBLOCK# (driven low by master holding lock)
CAD ADDRESS DATA
CIRDY#
CTRDY#
CSTOP#
CDEVSEL#
Figure 5-11 CardBus PC Card Accessing a Locked Agent

5.2.6.4 Completing an Exclusive Access

During the final transfer of an exclusive operation, CBLOCK# is negated so the target will accept
the request, and then re-asserted until the exclusive access terminates successfully. The master may
negate CBLOCK# at anytime when the exclusive operation has completed. However, it is
recommended (but not required) that CBLOCK# be negated with the negation of CIRDY#
following the completion of the last data phase of the locked operation. Releasing CBLOCK# at any
other time may result in a subsequent transaction being terminated with retry unnecessarily. A
locked agent unlocks itself whenever CBLOCK# and CFRAME# are negated.
If a master wants to execute two independent exclusive operations on the bus, it must ensure a
minimum of one clock between operations where both CFRAME# and CBLOCK# are negated. (For
example, the fast back-to-back case depicted in Figure 5-7 (clock 3) would be illegal.) This ensures
any target locked by the first operation is released prior to starting the second operation. (An agent
must unlock itself when CFRAME# and CBLOCK# are both negated on one clock edge.)
5.2.6.5 Supporting CBLOCK# and Write-back Cache Coherency

The resource lock as described earlier has a potential of deadlock when the host system is using a
write-back cache. A deadlock may occur if software allows locks to cross a cache line boundary when
write-back caching is supported and a complete resource lock is used. An example of this potential
deadlock is where the lock spans memory locations corresponding to the host system cache lines n
and n+1. Cache line n+1 has been modified in the cache. A master establishes a resource (memory)
lock by reading location corresponding to cache line n. The locked operation continues by reading
location corresponding to cache line n+1. The snoop (of n+1) results in a hit to modified line in the
host system's write-back cache. However, the cache writeback of the modified line fails because the
target only accepts accesses from the owner of CBLOCK#. This results in a deadlock because the
read cannot occur until the modified line is written back and the writeback cannot occur until
CBLOCK# ownership is released.
5.2.6.6 Complete Bus Lock

The CardBus PC Card resource lock can be converted into a complete bus lock by having the arbiter
not grant the bus to any other agent while CBLOCK# is asserted. When the first access of the locked
sequence is retried, then the master must negate both its CREQ# and CBLOCK#. When the first
access completes normally, then the complete bus lock has been established and the arbiter will not
grant the bus to any other agent. If the arbiter granted the bus to another agent when the complete
bus lock was being established, the arbiter must remove the other grant to ensure that complete bus
lock semantics are observed. A complete bus lock may have a significant impact on the performance
of the system, particularly the video subsystem. All non-exclusive accesses will not proceed while a
locked operation is in progress.
As with the complete resource lock and write-back cacheable memory, potential of a deadlock exists
for complete bus lock. The arbiter that supports complete bus lock must grant the bus to the cache to
perform a writeback due to a snoop to a modified line when a lock is in progress.
5.2.7 Other Bus Operations
5.2.7.1 Device Selection

CDEVSEL# is driven by the target of the current transaction as shown in Figure 5-12. CDEVSEL#
may be driven one, two, or three clocks following the address phase and its timing is indicated in

the configuration space Status register. CDEVSEL# must be asserted with or prior to the edge at
which the target enables its CTRDY#, CSTOP#, or data (read). In other words, a target must assert
CDEVSEL# (claim the transaction) before it is allowed to issue any other target response. In all cases
except one, once a target asserts CDEVSEL# it must not negate CDEVSEL# until CFRAME# is
negated (CIRDY# is asserted) and the last data phase has completed. With normal master
termination, CDEVSEL# negation must be coincident with the negation of CTRDY#. The exception
is the target-abort.
CCLK
1 2 3 4 5 6 7 8
CFRAME#
CIRDY#
CTRDY#
NO RESPONSE
CDEVSEL# FAST MED SLOW SUB
ACKNOWLEDGE
Figure 5-12 CDEVSEL# Assertion
If no agent asserts CDEVSEL# within three clocks of CFRAME#, the agent doing subtractive decode
may claim and assert CDEVSEL#. If the system does not have a subtractive decode agent, the
master never sees CDEVSEL# asserted and terminates the transaction per the master-abort
mechanism (refer to 5.2.3.3.1 Master Initiated Termination).
A target must do a full decode before driving/asserting CDEVSEL#, or any other target response
signal. It is illegal to drive CDEVSEL# prior to a complete decode and then let the decode
combinationally resolve on the bus. (This could cause contention.) A target must qualify the CAD
lines with CFRAME# before CDEVSEL# can be asserted on commands other than configuration. A
target must qualify CCBE# and CAD[1::0] with CFRAME# before CDEVSEL# can be asserted on a
Configuration command.
It's expected that most (perhaps all) target devices will be able to complete a decode and assert
CDEVSEL# within one or two clocks of CFRAME# being asserted (fast and medium in the figure).
Once CDEVSEL# has been asserted, it cannot be negated until the last data phase has completed,
except to signal target-abort.
If the first access maps into the targets address range, it asserts CDEVSEL# to claim the access. But if
the master attempts to continue the burst access across the resource boundary, the target is required
to signal disconnect.
When a target claims an I/O access, and the byte enables indicate one or more bytes of the access
are outside the target's address range, it must signal target-abort. To deal with this type of I/O
access problem, a subtractive decode device (e.g., expansion bus bridge) may do one of the
following:
• do positive decode (by including a byte map) on addresses for which different devices share
common DWORDs, additionally using byte enables to detect this problem and signal target-
abort.

• pass the full access to the expansion bus, where the portion of the access that cannot be serviced
will be ignored. (This occurs only when first addressed target resides on the expansion bus and
the other is on CardBus PC Card.)
5.2.7.2 Special Cycle

The Special Cycle command provides a simple message broadcast mechanism on CardBus PC Card.
In addition to communicating processor status, it may also be used for logical sideband signaling
between CardBus PC Card agents, when such signaling does not require the precise timing or
synchronization of physical signals.
A good paradigm for the Special Cycle command is that of a "logical wire" which only signals single
clock pulses; i.e., it can be used to set and reset flip flops in real time, implying that delivery is
guaranteed. This allows the designer to define necessary sideband communication without
requiring additional pins. As with sideband signaling in general, implementation of Special Cycle
command support is optional.
The Special Cycle command contains no explicit destination address, but is broadcast to all agents.
Each receiving agent must determine whether the message is applicable to it. CardBus PC Card
agents will never assert CDEVSEL# in response to a Special Cycle command. This means that there
is no target handshaking of any kind on these transactions, and subtractive decoding bridges must
not pass this bus operation on to their secondary bus. Special Cycle commands will not propagate
across bridges.
A Special Cycle command may contain optional, message dependent data, which is not interpreted
by the CardBus PC Card interface itself, but is passed, as necessary, to the hardware application
connected to the CardBus PC Card interface. In most cases, explicitly addressed messages should be
handled in one of the three physical address spaces on CardBus PC Card, and not with the Special
Cycle command.
Using a message dependent data field can break the logical wire paradigm mentioned above, and
create delivery guarantee problems. However, since targets only accept messages they recognize
and understand, the burden is placed on them to fully process the message in the minimum
delivery time (six bus clocks) or to provide any necessary buffering for messages they accept.
Normally this buffering is limited to a single flip flop. This allows delivery to be guaranteed. In
some cases it may not be possible to buffer or process all messages that could be received. In this
case there is no guarantee of delivery.
A Special Cycle command is like any other bus command where there is an address phase and a
data phase. The address phase starts like all other commands with the assertion of CFRAME# and
completes like all other commands when CFRAME# and CIRDY# are negated. The uniqueness of
this command compared to the others is that no agent responds with the assertion of CDEVSEL#.
This command is basically a broadcast to all agents, and interested agents accept the command and
process the request.
The address phase contains no valid information other than the command field. There is no explicit
address. However, CAD[31::00] are driven to a stable level and parity is generated. During the
data phase CAD[31::00] contain the message type and an optional data field. The message is
encoded on the least significant sixteen lines namely CAD[15::00]. The optional data field is encoded
on the most significant sixteen lines namely CAD[31::16] and is not required on all messages. The
master of a Special Cycle command can insert wait states like any other command while the target
cannot (since there is no explicit target). The message and associated data are only valid on the first
clock CIRDY# is asserted. The information contained in and the timing of subsequent data phases is
message dependent.

During the address phase, CCBE[3::0]# = 0001 (Special Cycle) and CAD[31::00] are driven to
random values and must be ignored. During the data phase, CCBE[3::0]# are asserted and
CAD[31::00] are as follows:
CAD[15::00] Encoded message
CAD[31::16] Message dependent (optional) data field
The CardBus PC Card bus sequencer starts this command like all others and terminates it with a
master-abort. The hardware application provides all the information like for any other command
and starts the bus sequencer. When the sequencer reports that the access terminated with a master-
abort, the hardware application knows the access completed. In this case, the Received Master Abort
field in the configuration space Status register must not be set. The quickest a Special Cycle
command can complete is five clocks. One additional clock is required for the turnaround cycle
before the next access. Therefore, a total of six CardBus PC Card clocks is required from the
beginning of a Special Cycle to the beginning of another access.
There are 64 KBytes of messages. The message encodings are defined and described in Appendix
A.
5.2.7.3 Address/Data Stepping

The ability of an agent to spread assertion of qualified signals over several clocks is referred to as
stepping. This notion allows an agent with weak output buffers to drive a set of signals to a valid
state over several clocks (continuous stepping), thereby reducing the ground current load generated
by each buffer. An alternative approach allows an agent with strong output buffers to drive a subset
of them on each of several clock edges until they are all driven (discrete stepping), thereby reducing
the number of signals that must be switched simultaneously.
Either approach allows an agent to trade off performance for cost (fewer power/ground pins). When
using the continuous stepping approach, care must be taken to avoid mutual coupling between
critical control signals that must be sampled on each clock edge and the stepped signals that may be
transitioning on a clock edge.
Stepping is only permitted on CAD[31::00] and CPAR because they are always qualified by control
signals; i.e., these signals are only considered valid on clock edges for which they are qualified.
CAD's are qualified by CFRAME# in address phases, and by CIRDY# or CTRDY# in data phases
(depending on which direction data is being transferred). CPAR is implicitly qualified on each clock
after which CAD was qualified.
Figure 5-13 illustrates a master delaying the assertion of CFRAME# until it has successfully driven
all CAD lines. The master is both permitted and required to drive CAD and CCBE# once
ownership has been granted and the bus is IDLE. But it may take multiple clocks to drive a valid
address before asserting CFRAME#. However, by delaying assertion of CFRAME#, the master
runs the risk of losing its turn on the bus. As with any master, CGNT# must be asserted on the
clock edge before CFRAME# is asserted. If CGNT# were negated, on the clock edges marked A,
the master is required to immediately High-Z its signals because the arbiter has granted the bus to
another agent. (The new master would be at a higher priority level.) If CGNT# were negated on
the clock edges marked B or C, CFRAME# will have already been asserted, and the transaction
continues.

CCLK
1 2 3 4 5 6 7 8 9
A A B C
CGNT#
CFRAME#
CIRDY#
CAD ADDRESS DATA-0
CCBE# BUS CMD BE#'s-0
Figure 5-13 Address Stepping
5.2.7.4 Configuration Cycle

The CardBus PC Card definition provides for totally software driven initialization and configuration
via a separate configuration address space. CardBus PC Card devices are required to provide 256
bytes of configuration space for this purpose. Register descriptions are provided in the CardBus PC
Card Programming Model section of this specification. This section describes the bus commands for
accessing the CardBus PC Card configuration space.
As previously discussed, each device decodes its own addresses for normal accesses. However,
accesses in the configuration address space require device selection decoding to be done by the host
CardBus PC Card adapter. The configuration read and write cycle signals and timing are the same
as for other read and write commands. A CardBus PC Card device is a target of a configuration
command (read or write) only if CAD[1::0] are 00 during the address phase of the command.
Internal addressing of the 64-DWORD register space is done by CAD[7::2] and the byte enables.
The Configuration command, like other commands, allows accesses of a byte, word, DWORD, or as
a burst operation. The rest of the transaction is the same as other commands, including all
termination semantics. If no agent responds, the request is terminated via master-abort (refer to
5.2.3.3.1 Master Initiated Termination).

To support hierarchical buses, two types of configuration access are used. They have the following
formats which show the interpretation of CAD lines during the address phase of a configuration
access:
31 11 10 8 7 2 1 0
Function Register
Reserved 0 0
Number Number
Type 0
31 24 23 16 15 11 10 8 7 2 1 0
Bus Device Function Register
Reserved 0 1
Number Number Number Number
Type 1
Figure 5-14 Type 0 and Type 1 Configuration Accesses
Type 1 and Type 0 configuration accesses are differentiated by the values on the CAD[1::0] pins. A
Type 0 configuration cycle (when CAD[1::0] = "00") is used to select a device on the bus where the
cycle is being run. A Type 1 configuration cycle (when CAD[1::0] = "01") is used to pass a
configuration request on to another bus.
The Register Number and Function Number fields have the same meaning for both configuration
types, while Device Number and Bus Number are used only in Type 1 accesses. Reserved fields
must be ignored by targets.
Table 5Ð6 Common Access Field Definitions

Register Number is an encoded value used to index a DWORD in configuration space of the intended target.
Function Number is an encoded value used to select one of eight possible functions on a device.
Device Number is an encoded value used to select 1 of 32 devices on a given bus.
Bus Number is an encoded value used to select 1 of 256 buses in a system.
Bridges (e.g., Host-to-CardBus PC Card) that need to generate a Type 0 configuration cycle use the
Device Number to select a CardBus PC Card device. The Function Number is provided on
CAD[10::08]. The Register Number is provided on CAD[7::2]. CAD[1::0] must be 00 for a Type 0
configuration access.
Type 0 configuration accesses are not propagated beyond the local CardBus PC Card and must be
claimed by a local device or terminated with master-abort.
If the target of a configuration access resides on another bus (not the local CardBus PC Card), a Type
1 configuration access must be used. Type 1 accesses are ignored by all targets except CardBus PC
Card-to-CardBus PC Card bridges. These devices decode the Bus Number field to determine if the
destination of the configuration access is residing behind the bridge. If the Bus Number is not for a
bus behind the bridge, the access is ignored. The bridge claims the access if the access is to a bus
behind the bridge. If the Bus Number is not to the secondary bus of the bridge, the access is simply
passed through unchanged. If the Bus Number matches the secondary bus number, the bridge
converts the access into a Type 0 configuration access. The bridge changes CAD[1::0] to 00 and
passes CAD[10::02] through unchanged. The Device Number is decoded to select one of 32 devices
on the local bus, and the bridge initiates a configuration access to that device.

Devices that respond to Type 0 configuration cycles are separated into two classes. The first class
(single function device) uses only CAD[1::0] (00) to determine whether or not to respond. The
second class of device (multi-function device) understands the Function Number field and uses
CAD[1::0] (00), as well as the encoded value on CAD[10::08] to determine whether or not to
respond. The two classes are differentiated by an encoding in the configuration space header.
Multi-function devices are required to do a full decode on CAD[10::08], and only respond to the
configuration cycle if they have implemented the configuration space registers for the selected
function. They are also required to always implement function 0 in the device. Implementing other
functions is optional and may be assigned in any order (i.e., a two-function device must respond to
function 0, but can choose any of the other possible function numbers (1-7) for the second function).
Configuration code will probe the bus in Device Number order (i.e., Function Number will be
zero). If a single function device is detected, no more functions for that Device Number will be
checked. If a multi-function device is detected, then all remaining Function Numbers will be
checked.
5.2.7.4.1 Generating Configuration Cycles

Systems must provide a mechanism that allows CardBus PC Card configuration cycles to be
generated by software. This mechanism is typically located in the host bridge or the host CardBus
PC Card adapter. For PC-AT compatible systems, the mechanism for generating configuration
cycles is defined and specified below. For other system architectures there is presently no
specification.
Host bridges and host CardBus PC Card adapters to be used in PC-AT compatible systems must
implement this mechanism for generating CardBus PC Card configuration cycles.
5.2.7.4.1.1 Configuration Mechanism

Two DWORD I/O locations are used in this mechanism. The first DWORD location (CF8H)
references a read/write register that is named CONFIG_ADDRESS. The second DWORD address
(CFCH) references a register named CONFIG_DATA. The general mechanism for accessing
configuration space is to write a value into CONFIG_ADDRESS that specifies a particular CardBus
PC Card in the system, device on that bus, and configuration register in that device being accessed.
A read or write to CONFIG_DATA will then cause the bridge to translate that CONFIG_ADDRESS
value to the requested configuration cycle on that CardBus PC Card.
31 30 24 23 16 15 11 10 8 7 2 1 0
Bus Device Function Register
Reserved 0 0
Number Number Number Number
Enable bit (Ô1Õ = enabled, Ô0Õ = disabled)

Figure 5-15 Layout of CONFIG_ADDRESS Register
The CONFIG_ADDRESS register is 32 bits with the format shown in Figure 5-15 Figure. Bit 31 is an
enable flag for determining when accesses to CONFIG_DATA should be translated to configuration
cycles on CardBus PC Card. Bits 30 to 24 are reserved, read-only, and must return 0's when read.
Bits 23 through 16 choose a specific CardBus PC Card bus in the system. Bits 15 through 11 choose a
specific device on the bus. Bits 10 through 8 choose a specific function in a device (if the device
supports multiple functions). Bits 7 through 2 choose a DWORD in the device's configuration space.
Bits 1 and 0 are read-only and must return 0's when read.

Anytime a host bridge sees a full DWORD I/O write to CONFIG_ADDRESS, the bridge must latch
the data into its CONFIG_ADDRESS register. On full DWORD I/O reads to CONFIG_ADDRESS,
the bridge must return the data in CONFIG_ADDRESS. Any other types of accesses to this address
(non-DWORD) must be treated like a normal I/O access and no special action should be taken.
Therefore, the only I/O space consumed by this register is a DWORD at the given address. I/O
devices using BYTE or WORD registers are not affected because the cycles will be passed on
unchanged.
When a bridge sees an I/O access that falls inside the DWORD beginning at CONFIG_DATA
address, it checks the enable bit and the BUS NUMBER in the CONFIG_ADDRESS register. If
configuration cycle translation is enabled and the BUS NUMBER matches the bridge's bus number
or any bus number behind the bridge, then a configuration cycle translation must be done.
There are two types of translation that take place. The first, Type 0, is a translation where the device
being addressed is on the CardBus PC Card bus connected to the bridge. The second, Type 1, occurs
when the device is on another bus somewhere behind this bridge.
For Type 0 translations (see Figure 5-16), the bridge does a decode of the Device Number field to
access the appropriate device15 and performs a configuration cycle on CardBus PC Card, where
CAD[1::0] is 00. Bits 10 - 8 of CONFIG_ADDRESS are copied to CAD[10::8] on CardBus PC Card as
an encoded value which may be used by components which contain multiple functions. CAD[7::2]
are also copied from the CONFIG_ADDRESS register. Figure 5-16 shows the translation from the
CONFIG_ADDRESS register to CAD lines on CardBus PC Cards.
31 30 24 23 16 15 11 10 8 7 2 1 0
CONFIG_ADDRESS Bus Device Function Register

Reserved 0 0
REGISTER Number Number Number Number
Selects a CardBus PC Card
CardBus PC Card
Undefined 0 0
CAD LINES
31 11 10 1 0
Figure 5-16 Bridge Translation for Type 0 Configuration Cycles
For Type 1 translations, the bridge directly copies the contents of the CONFIG_ADDRESS register
onto the CardBus PC Card CAD lines during the address phase of a configuration cycle making
sure that CAD[1::0] is 01.
In both cases, byte enables for the data transfers must be directly copied from the processor bus.
For systems with peer bridges on the processor bus, one peer bridge would typically be designated
to always handshake accesses to the CONFIG_ADDRESS register. Other bridges would snoop the
data written to this register. Accesses to the CONFIG_DATA register are typically handshaken by
the bridge doing the configuration translation.
15 If the Device Number field contains an invalid device number, the bridge must complete the processor access
normally, dropping the data on writes and returning all ones on reads.

Host bridges and CardBus PC Card-to-CardBus PC Card bridges typically require two configuration
space registers whose contents are used to determine when the bridge does configuration cycle
translation. One register (Bus Number) specifies the bus number of the CardBus PC Card directly
behind the bridge, and the other register (Subordinate Bus Number) specifies the number of the last
hierarchical bus behind the bridge.16 POST code is responsible for initializing these registers to
appropriate values.
5.2.7.4.1.2 Generating Special Cycles with the Configuration Mechanism

This section defines how host bridges that implement the Configuration Mechanism for accessing
configuration space should allow software to generate Special Cycles. Host bridges are not required
to provide a mechanism for allowing software to generate Special Cycles.
When the CONFIG_ADDRESS register gets written with a value such that the Bus Number matches
the bridge's bus number, the Device Number is all 1's, the Function Number is all 1's, and the
Register Number has a value of zero, then the bridge is primed to do a Special Cycle the next time
the CONFIG_DATA register is written. When the CONFIG_DATA register is written, the bridge
generates a Special Cycle encoding (rather than configuration write) on the CCBE[3::0]# pins during
the address cycle, and drives the data from the I/O write onto CAD[31::00] during the first data
cycle. Reads to CONFIG_DATA, after CONFIG_ADDRESS has been set up this way, have
undefined results. The bridge can treat it as a normal configuration cycle operation (i.e. generate a
Type 0 configuration cycle on CardBus PC Card). This will terminate with a master-abort and the
processor will have all 1's returned.
If the Bus Number field of CONFIG_ADDRESS does not match the bridge's bus number, then the
bridge passes the write through CONFIG_DATA on to CardBus PC Card as a Type 1 configuration
cycle just like anytime the bus numbers don't match.
5.2.8 Error Functions

CardBus PC Card provides for parity and other system errors to be detected and reported. CardBus
PC Card error coverage may range from devices that have no interest in errors (particularly parity
errors) to agents that detect, signal, and recover from errors. This allows agents that recover from
parity errors to avoid affecting the operation of agents that do not. To allow this range of flexibility,
the generation of parity is required on all transactions by all agents. The detection and reporting of
errors is also required.
The discussion of errors is divided into the following two sections covering parity generation and
detection, and error reporting. Each section explains what is optional and what is required for each
function.
5.2.8.1 Parity
Parity on CardBus PC Card provides a mechanism to determine transaction by transaction if the
master is successful in addressing the desired target and if the data transfer occurred correctly. To
ensure that the correct bus operation is performed, the four command lines are included in the
parity calculation. To ensure that correct data is transferred, the four byte enables are also included
in the parity calculation. The agent that is responsible for driving CAD[31::00] on any given bus
phase is also responsible for driving even parity on CPAR.
During address and data phases, parity covers the CAD[31::00] and CCBE[3::0]# lines regardless of
whether or not all lines carry meaningful information. Byte lanes not actually transferring data are
16 Host bridges that do not allow peer bridges do not need either of these registers since the bus behind the bridge is,
by definition, bus 0 and all other CardBus PC Card buses are subordinate to bus 0.

still required to be driven with stable (albeit meaningless) data and are included in the parity
calculation. During Configuration or Special Cycle commands, some (or all) address lines are not
defined but are required to be driven to stable values and are included in the parity calculation.
Parity is generated according to the following rules:
• Parity is calculated in the same way on all CardBus PC Card transactions regardless of
the type or form.
• The number of "1"s on CAD[31::00], CCBE[3::0]#, and CPAR equals an even number.
• Parity generation is not optional; it must be done by all CardBus PC Card compliant
devices.
On any given bus phase, CPAR is driven by the agent that drives CAD[31::00] and lags the
corresponding address or data by one clock. Figure 5-17 illustrates a read and write transaction with
parity. The master drives CPAR for the address phases on clock 3 and 7. The target drives CPAR
for the data phase on the read transaction (clock 5) while the master drives CPAR for the data phase
on the write transaction (clock 8). Note that other than the one clock lag, CPAR behaves exactly like
CAD[31::00] including wait states and turnaround cycles.
CCLK
1 2 3 4 5 6 7 8 9
CFRAME#
CPAR
CPERR#
Figure 5-17 Parity Operation
Parity must be checked to determine if the master successfully addressed the desired target and if
data transferred correctly. Checking of parity on CardBus PC Card is required except in one class of
devices listed in 5.2.8.2 Error Reporting. Agents that support parity checking must always set the
Detected Parity Error field in the configuration space Status register when a parity error is detected.
Any additional action beyond setting this field is conditional upon the Parity Error Response field in
the configuration space Command register and is discussed in the error reporting section.
Any agent may check and signal an address parity error on CSERR#. Only the master may report
a read data parity error and only the selected target may signal a write data parity error.
5.2.8.2 Error Reporting

As mentioned, CardBus PC Card provides for the detection and signaling of both parity and other
system errors. It is intended that parity errors be reported up through the access and device driver
chain whenever possible. This error reporting chain from target to bus master to device driver to
device manager to operating system is intended to allow error recovery options to be implemented
at any level. Since it is generally not possible to associate system errors with a specific access chain,
they are reported directly to the system level.

Two signals are used in the CardBus PC Card error reporting scheme. CPERR# is used exclusively
for reporting data parity errors on all transactions except Special Cycle commands. It is a sustained
tri-state signal and is bussed to all CardBus PC Card agents. Bus protocol assures that CPERR# will
never be simultaneously driven by multiple bus agents and that proper signal turn around times
are observed to avoid any driver contention.
CSERR# is used for other error signaling, including address parity, and data parity on Special
Cycle commands, and may optionally be used on any other non-parity or system errors. It is an
open drain signal that is wire-ORÕed with all other CardBus PC Card agents and, therefore, may be
simultaneously driven by multiple agents. Since open drain signaling cannot guarantee stable
levels on every clock edge, once CSERR# is asserted its logical value must be assumed to be
indeterminate until the signal is sampled in the negated state on at least two successive clock edges.
Both CPERR# and CSERR# are required pins since parity error signaling on CardBus PC Card is
required. Note that all agents are required to generate parity.
Use of CSERR# to signal non-parity errors is optional. It must be assumed, however, that signaling
on CSERR# will generate an NMI and is, therefore, fatal. Consequently, care should be taken in
using CSERR#.
The following sections cover the responsibility placed on each bus agent regarding signaling on the
CPERR# and CSERR# pins.
5.2.8.2.1 Parity Error Response and Reporting on CPERR#

This section describes proper response to, and reporting of, data parity errors in all bus operations
except Special Cycle commands. All address parity errors, as well as Special Cycle command data
parity errors are reported on the CSERR# signal, and are described in the next section. All
references to parity errors in this section are by implication limited strictly to data parity (except
Special Cycle commands).
CardBus PC Card uses the CPERR# pin to signal a data parity error between connected devices on
CardBus PC Card (except on Special Cycle commands). Only the master of a corrupted data transfer
is allowed to report parity errors to software, using mechanisms other than CPERR#. Targets always
signal data parity errors back to the master on CPERR#. This gives the originator of the access, at
each hardware or software level, the prerogative of recovery.
Except for setting the Parity Error Detected field, all parity error signaling and response is
controlled by the Parity Error Response field. This field is required except in the previously listed
(excluded) devices. If the field is cleared, the agent ignores all parity errors and completes the
transaction as though parity was correct. If the field is set, the agent is required to assert CPERR#
when a parity error is detected; additional error response is device dependent. In all cases, the
Detected Parity Error field must be set.
An agent must always assert CPERR# two CardBus PC Card clocks after a data transfer in which an
error occurred, as shown in Figure 5-17. The agent receiving data is free to assert CPERR# when a
parity error is detected (which may occur before data is transferred).17 Once CPERR# is asserted, it
must remain asserted until two clocks following the actual transfer. A master knows a data parity
error occurred anytime CPERR# is asserted but only knows the transfer was error free two clocks
following the transfer.
In the case of multiple data transfers without intervening wait states, CPERR# will be qualified on
multiple consecutive clocks accordingly, and may be asserted in any or all of them. Since CPERR#
is a sustained tri-state signal, it must be actively driven to the correct value on each qualified clock
17 On a write transaction, this can occur when CIRDY# is asserted and the target is inserting wait states. On a read
transaction, this occurs when CTRDY# is asserted and the master is inserting wait states.

edge. To return it to nominal state at the end of each bus operation, it must be actively driven high
for one clock period, starting two clocks after the CAD bus turnaround cycle (e.g., clock 7 in Figure
5-17.) The CPERR# turnaround cycle occurs one clock later (clock 8 in Figure 5-17.) CPERR# may
never be driven (enabled) for the current cycle until at least three clocks after the address phase.
When a master detects a data parity error and asserts CPERR# (on a read transaction) or samples
CPERR# asserted (on a write transaction) it must set the Data Parity Detected field (Status register,
bit 8), and can either continue the transaction or terminate it. A target of a transaction that detects a
parity error can either continue the operation or cause it to be stopped via target termination.
Targets never set the Data Parity Reported field. When CPERR# is asserted, it is recommended that
both the master and target complete the transaction. CPERR# is only an output signal for targets
while masters use CPERR# as both an input and output.
When the master of the access becomes aware that a parity error has occurred on its transaction, it is
required to inform the system. It is recommended that the master inform its device driver of the
error by generating an interrupt (or modifying a status register or flag to mention a few options). If
none of these options is available to the device, it may, as a last recourse, pass responsibility of the
error to the operating system by asserting CSERR#. Note that the system designer may elect to
report all parity errors to the operating system by converting all CPERR# error signals into
CSERR# error signals in the central resource.
5.2.8.2.2 Error Response and Reporting on CSERR#

CSERR# is used to signal all address parity errors, data parity errors on Special Cycle commands
(since these are broadcast writes), and all errors other than parity errors. Any agent can check and
signal address parity errors on CSERR#, regardless of intended master and target. CSERR# may
only be asserted when the SERR Enable field in the Command register is set to a logical one (high),
regardless of the error type. When an agent asserts CSERR# it is required to set the Signaled
System Error field in the configuration space Status register, regardless of the error type. In
addition, if the error type is parity (e.g., address parity), the Parity Error Detected field must be set
in all cases, but reporting on CSERR# is conditioned on the Parity Error Response field in the
Command register.
A selected agent that detects an address parity error should do one of the following:
claim the transaction and terminate with target-abort, or not claim the cycle and let it terminate with
master-abort. The target is not allowed to terminate with retry or disconnect because an address
parity error was detected.
CSERR# has no timing relationship to any CardBus PC Card transaction. 18 However, errors should
be signaled as quickly as possible, preferably within two clocks of detection. The only agent
interested in CSERR# (as an input) is the central resource that converts a low pulse into a signal to
the processor. How the central resource signals the processor is system dependent, but could include
generating an NMI, high priority interrupt, or setting a status field or flag. However, the agent that
asserts CSERR# must be willing for the central resource to generate an NMI. Otherwise, the error
should be reported by a different mechanism (e.g., an interrupt, status register, or flag).
When the Parity Error Response field is enabled, and the SERR Enable field enabled, an agent may
assert CSERR# under the following conditions:
• Address parity error, or data parity error on Special Cycles detected.
• The detection of a parity error that is not reported by some other mechanism (current bus
master only).
18 Except for CCLK.

When the SERR Enable field is enabled, an agent may assert CSERR# under the following
conditions:
• The master (which does not have a driver) was involved in a transaction that was abnormally
terminated.
• A catastrophic error that left the agent questioning its ability to operate correctly.
Note that master-abort is not an abnormal condition for bridges during Configuration and Special
Cycle commands. CSERR# should not be used for these conditions or for normally recoverable
cases. The assertion of CSERR# should be done with deliberation and care since the result may be
an NMI. Target-abort is generally an abnormal target termination and may be reported (only by
the master) as an error by signaling CSERR# when the master cannot report the error through its
device driver.
5.2.9 Cache Support

In a mobile or a small desktop system, part or all of the system memory may reside on CardBus PC
Card. This may include read only program modules as well as RAM, both of which must be
cacheable by the processor. Also, supporting XIP (eXecute In Place) of software stored on PC Cards
is an important part of the CardBus PC Card standard. To make XIP viable, the XIP memory on PC
Cards must be cacheable, otherwise the execution performance would suffer considerably. However,
supporting cacheability of the memory residing on PC Cards, and providing a mechanism for
maintaining the memory and processor cache's data consistency involves some system and CardBus
PC Card interface design trade offs. CardBus PC Cards may contain cacheable memory. The
cacheability rules are optimized for systems using removable PC Cards.
The CardBus PC Card memory caching option assumes:
• A consistent, common, flat physical address space is maintained in the system, i.e. a given
address has a unique destination and an access of that address produces the same results
regardless of the access origin. This allows for the host system and bus masters on PC Cards to
access the system memory and memory on PC Cards, any memory mapped into the common
address space, in a uniform way.
Note that this provision does not preclude some private memory spaces in the host system or on
PC Cards. Also note that special memory mapping cases, like the DOS Compatibility Hole, are
outside the scope of this specification.
• The host system, the system master, is responsible for memory mapping and memory
allocation, including the memory on PC Cards.
• The host system's cache coherency must be maintained as if agents on the bus master cards
would be accessing the host system memory.
The first two rules for caching memory in the CardBus PC Card environment (and in the system)
are generic. They are as following:
1. An agent's private memory is not a shared memory, and, in general, it is not visible to other
agents in the system. It is cacheable by the corresponding agent without any limitations
pertaining to presence of CardBus PC Card in the system. An agent (a device or a function of
the device) can cache its own private memory. This memory must not be shared with other
agents (devices) in the system. The agent is responsible for maintaining its cache and memory
data consistency.
2. Non-modifiable code or data (ROM) can be cacheable, providing that corresponding code or
data in the cache(s) is write protected. If an agent cannot guarantee write protection of the
cached ROM data in its own cache, then this data is not cacheable by that agent.

For a read/write shared memory on PC Cards, the following cacheability discipline and requirements
must be met:
1. The host system may cache memory on a CardBus PC Card if the card configuration allows it
(e.g., as set in the card's Configuration Space), with hardware maintained data consistency.
2. All accesses to memory Cacheable by the host system must be visible to the host system for
maintaining its cache coherency.
3. An agent on a CardBus PC Card may cache only the card's on-board (local19) memory. If the
agent on the CardBus PC Card caches its local memory, that memory must not be cacheable by
the host system (e.g., disallowed in the card's Configuration Space). Cacheability of the card's
memory by the host system or by the local agent must be configured by the host system during
initialization of the card.
4. If an agent on the CardBus PC Card caches its local memory, it is responsible for its cache and
the memory data consistency when any other agent accesses that local memory.
In general, if the CardBus PC Card and the system bus do not operate concurrently, all CardBus PC
Card addresses should be visible on the system bus. Otherwise, the host CardBus PC Card adapter
must forward addresses in the cacheable range to the system bus for snooping. Also, card's address
range(s) which represent memory mapped I/O are not cacheable, while other regions of the card's
memory might be cacheable.
Any function in a CardBus PC Card device that contains memory that might be cacheable by the
host system, must implement a writable Cache Line Size register (refer to the CardBus PC Card
Programming Model Section of this specification). Contents of this register cannot be hard-wired to
any value. It must be written by the host system during the function configuration. If a non-zero
value is written into the Cache Line Size register, the agent must disconnect all types of memory
transactions (all Memory commands) crossing the cache line boundaries. If zero value is written to
the Cache Line Size register, the agent is released from maintaining the memory caching discipline,
i.e. it does not have to disconnect CardBus PC Card transactions on the cache line boundaries.
If the Cache Line Size register is written to 0, it is the responsibility of the host system software to
maintain the host system's cache coherency with respect to the memory on the card, or disable
caching of that memory.
An agent containing memory that is not cacheable by the host system, may hard-wire the contents
of the Cache Line Size register to zero.
5.2.10 Clock Control
5.2.10.1 Clock Frequency

The host system is allowed to vary the CardBus PC Card clock frequency, implement a single,
constant clock frequency, or stop the clock without software notification to CardBus PC Card devices.
The host system can change the clock frequency only when the CardBus PC Card interface is idle.
The clock (CCLK) can be stopped by the host system only while the CardBus PC Card interface is
idle, and no bus request (CREQ#20) or lock (CBLOCK#) is asserted by a CardBus PC Card agent.
The clock can be stopped only in a low state, and the clock line must remain low until the clock is
19Private and local memory are not synonyms here. Private memory is not a shared memory. The term local (on-
board) memory designates physical memory location, e.g. on a PC Card with another CardBus PC Card agent.
The local memory, however, could be logically shared by two or more agents in the system.
20CGNT# is not being considered here because it may never be asserted to a card unless the card's CREQ# is
asserted. The CardBus PC Card central resource (e.g., the host CardBus PC Card adapter) is the default bus owner.

restarted. The minimum clock cycle time and the minimum clock high and low parameters must
not be violated, and the clock edges must be monotonic. (See 5.3 CardBus PC Card Electrical
Specification for the clock specifications).
The provisions for variable clock frequency and for stopping the interface clock require the CardBus
PC Card device's interface logic to maintain its state. The device cannot rely on any particular
frequency of the clock across the interface.
5.2.10.2 Clock Control Protocol

The CardBus PC Card clock control protocol is implemented using an optional CCLKRUN# signal.
A PC Card asserts CCLKRUN# to request the host system:
• To restore the interface clock to a normal operating frequency21 if it is stopped or running below
this frequency.
• To keep the clock running while an internal process on the card is in progress.
The host system drives the CCLKRUN# line as following:
• Negates CCLKRUN# to indicate that the clock is about to be stopped or slowed to a non-
operational frequency. The host system should not negate CCLKRUN# if it is not going to stop
or slow down the clock.
• Asserts CCLKRUN# when the interface clock is either: running at a normal operating
frequency, or about to be started (or brought up to a normal operating frequency)
The CCLKRUN# signal is functional only while power on the CardBus PC Card interface is on.
When the power is off, the CCLKRUN# line has no meaning.
A PC Card which does not implement the CCLKRUN# signal must leave this pin unconnected. A
host system which does not implement this clock control protocol must always assert the
CCLKRUN# signal.
Devices are not allowed to pulse CCLKRUN# continuously to indicate non-static implementation of
their logic, thus preventing the host system from stopping the clock.
5.2.10.2.1 Clock Stop or Slow down

The host system (the CardBus PC Card adapter or the clock resource) drives CCLKRUN# low while
CCLK is running at a normal operating frequency (refer to Figure 5-18). Before stopping the clock
or slowing the clock down to a non-operational frequency, the host system synchronously drives
CCLKRUN# high for one clock period, and then switches its driver to the High-Z state. A low
current pull-up (a keeper) must be provided by the host system to prevent the line from floating.
Implementations may disable the pull-up when the host system samples CCLKRUN# low.
CCLK continues to run unchanged for a minimum of four clock periods after CCLKRUN# is
negated. In addition, CCLK must not be stopped before the card can request it to continue by
asserting CCLKRUN# (refer to 5.2.10.2.3 Maintaining the Interface Clock). For example, after clock
8 (in the timing diagrams, Figure 5-18 and Figure 5-20), the host system may stop or slow down the
clock if the requirements specified in 5.2.10.2.3 are met.
CardBus PC Card devices are required to maintain their states while the interface clock is stopped or
the clock frequency is changed.
21Normaloperating frequency is any frequency at which transactions can be executed across the interface. It does not
necessarily mean the maximum CCLK frequency. It is up to the host's discretion to establish the operating
frequency of the interface at a given time.

CCLK
1 2 3 4 5 6 7 8 9
CFRAME#
CIRDY#
CCLKRUN#
DRIVEN BY HOST PULL-UP ENABLED
Figure 5-18 CardBus PC Card Clock Stop or Slow Down
5.2.10.2.2 Clock Restart or Speed up

To request restoration of the interface clock, a device asserts the CCLKRUN# signal asynchronously.
The device holds CCLKRUN# asserted until it detects two rising edges of CCLK (refer to Figure 5-
19 .) After the second clock edge, the device must disable its open drain driver.
After detecting the assertion of CCLKRUN#, the host system starts the clock if the clock was
stopped, or brings it to an operating frequency if the clock was slowed down.
The host system drives CCLKRUN# low at any time after it detects that the line is asserted by the
CardBus PC Card device, but not later than on clock 3 (in the timing diagram, Figure 5-19 .) The
host system may disable the pull-up on the CCLKRUN# line at this time.
The host system must not drive CCLKRUN# high earlier than on clock 5.
The device may not assert (start driving) CCLKRUN# if it is already driven low by the host system.
The device must not assert CCLKRUN# unless the line has been negated for two successive clocks,
e.g., before the clock was stopped.
It is expected that a device which has asserted CCLKRUN# for gaining bus mastership would assert
CREQ# no later than four clocks after the clock is restarted. Otherwise, the clock can be stopped
again by the host system.
The host system should provide low latency clock restoration to the interface upon assertion of
CCLKRUN# (typically, not more than a few cycles of its internal clock) since this latency would
negatively impact the interface performance. The intent of this protocol is to provide a low latency
clock control which is transparent to the host system software, and which would have no apparent
impact on the system performance.

CCLK
1 2 3 4 5 6
CCLKRUN#
CREQ#
PULL-UP ENABLED DRIVEN BY HOST
DRIVEN BY CARD
Figure 5-19 CardBus PC Card Clock Start or Speed up
5.2.10.2.3 Maintaining the Interface Clock

Certain devices may require the interface clock to be active for completing some internal processes
after a CardBus PC Card transaction is already completed. This is accomplished by having the
device assert CCLKRUN# after it has been negated for two successive CardBus PC Card clocks
(refer to Figure 5-20.) The device must assert CCLKRUN# within a certain time window to avoid
interruption of the clock stream. In Figure 5-20 , the device samples CCLKRUN# high on clock 4,
and must drive CCLKRUN# low no later than one Tval after clock 6, but not earlier than after the
turn around cycle which occurs after clock 4. The device keeps CCLKRUN# asserted for two clocks
(clocks 6 and 7, or clocks 7 and 8), and must disable its open drain driver after the second clock.
The host system must provide a non-interrupted clock when the device asserts CCLKRUN# in the
time specified above. The system designer should take into account:
1. All delays in the path to the systemÕs function controlling the clock and to the clock source.
2. The time required to synchronize CCLKRUN#. The clock resource must not stop the clock
before a synchronized version of the CCLKRUN# signal received from the device can be
generated.
3. The host system must drive CCLKRUN# low on the CardBus PC Card interface no later than on
clock 8. (The host system may drive the line low at any time after it detects that CCLKRUN# is
asserted by the CardBus PC Card device.)
The host system must not drive CCLKRUN# high earlier than on the fourth clock edge after the
CCLKRUN# line was first sampled asserted.
The device may not drive CCLKRUN# if it is already driven low by the host system. The device
must not assert CCLKRUN# unless it has sampled the line high on a CCLK rising edge, and must
not drive CCLKRUN# on the same clock edge on which the line is first sampled high.

CCLK
1 2 3 4 5 6 7 8 9
CFRAME#
CIRDY#
CCLKRUN#
DRIVEN BY HOST PULL-UP ENABLED DRIVEN BY HOST
DRIVEN BY CARD
Figure 5-20 Maintaining CardBus PC Card Clock
5.2.11 Status Changed Notification
5.2.11.1 Card Status Changed

Card Status Changed (CSTSCHG) is an optional signal which is used by PC Cards to notify the host
system about such events as changes in the Ready (READY), Write Protect (WP), or Battery Voltage
Detect (BVD[2::1]) conditions of the card. (See 4.4.14 Status Changed (STSCHG#) [I/O and Memory
Interface].) CSTSCHG on CardBus PC Card is a level sensitive interrupt which is separate and
distinct from the functional interrupt CINT#. The CSTSCHG signal on CardBus PC Card is asserted
high, unlike its 16-bit PC Card (STSCHG#) equivalent, and it is asynchronous to the CardBus PC
Card clock.
Each function on a CardBus PC Card provides a set of four 32-bit registers: Function Event, Function
Event Mask, Function Present State, and Function Force Event. These registers are located in
memory space at the location given by the CISTPL_CONFIG_CB tuple in the function's Card
Information Structure (CIS). The order of the four 32-bit registers is: offset + 0: Function Event; offset
+ 4: Function Event Mask; offset + 8: Function Present State; offset +12: Function Force Event. For
description of the registers, refer to 5.2.11.3 Register Descriptions.
These registers are sometimes optional in CardBus PC Cards that do not implement the CSTSCHG
signal. In that case, TPCC_ADDR (CISTPL_CONFIG_CB) must have the Address Space Indicator
field set to zero (0) (see also the Metaformat Specification).
When the CSTSCHG signal is implemented these registers support Status Changed Notification.
When the CINT# signal is implemented these registers support Functional Interrupt Notification.
When neither CSTSCHG or CINT# signals are implemented these registers provide a consistent
interface to CardBus PC Card system software.
5.2.11.2 System and Interface Wake up

The CardBus PC Card specification defines an optional system and interface Wakeup protocol using
the CSTSCHG line. This protocol allows a CardBus PC Card to request that the system powers up
and configures the interface when the interface is powered off. When the interface is powered up,
the CSTSCHG line is used to signal the Card Status Changed events.

When the CardBus PC Card interface is powered off, the power required to drive the CSTSCHG
signal must come from either an external source or from some power source on the card itself (e.g., a
local battery).
In its negated state, CSTSCHG signal is held low. When an external event occurs, the card drives a
single positive pulse on the CSTSCHG line. Optionally, the card may drive CSTSCHG as a high
level or series of pulses until the interface is powered up (or until CRST# is negated by the host
system). Note that when the CardBus PC Card interface is powered up, the Status Changed is
signaled on the CSTSCHG line as a level, not a pulse.
Battery powered cards assert the CSTSCHG signal for a minimum duration of 1 ms to minimize
energy drain from on card batteries (especially when the host system is completely powered off or
does not support the Wakeup protocol).
The host system, which implements this Wakeup protocol, must be able to latch a single CSTSCHG
pulse of the minimum duration. The host system cannot rely on continuous assertion or series of
CSTSCHG pulses to be driven by the card when the interface is powered off.
The host system can mask the CSTSCHG signal on a particular card or on several cards using the
Function Event Mask register(s).
In order to prevent the system from spurious wake up due to the CSTSCHG signal during a power
down process, the system must assert the CardBus PC Card reset (CRST#) before and throughout
powering off the CardBus PC Card interface (See also 5.3.3.2 Reset and 5.5.4.7.2 CSTSCHG
Requirements.)(see the CardBus PC Card Electrical Specification and the Requirements for Cards and
Sockets sections for CRST# parameters and power cycling requirements).
Upon detecting of the CSTSCHG signal assertion, the host system which supports this Wakeup
protocol is expected to:
• Return the system to an operational state
• Power up and configure the CardBus PC Card interface
The host system must assert the CardBus PC Card reset (CRST#) while powering up the interface.
After the interface is powered up and configured, the CSTSCHG line assumes its original Card
Status Changed signaling functionality.
The CSTSCHG signal driven by the card must be current-limited to prevent damage to the card or
the host system. The required signal parameters are specified in the CardBus PC Card Electrical
Specification section.
A CardBus PC Card which uses the CSTSCHG line for a system and/or the interface wake up,
must implement the Function Event, Function Event Mask, Function Present State and Function
Force Event registers. Signaling Wakeup on the CSTSCHG line is allowed only if the Wakeup
(WKUP) field is set and the mask field corresponding to the wake up event is set in the Function
Event Mask register by the host system.
All fields corresponding to the wake up events in the Function Event, Function Event Mask,
Function Present State and Function Force Event registers, must retain their settings throughout
power cycling of the CardBus PC Card interface. Also, these fields are not effected by the CardBus
PC Card reset (CRST#).
After the CardBus PC Card interface is powered up and configured, the card must signal the Card
Status Changed interrupt (assert CSTSCHG as a level) if an event field (WP, READY, BVD[2::1]) is
set in the Function Event register and the corresponding mask field is set in the Function Event
Mask register.

The host system is responsible for reading and clearing the event field(s) in the Function Event
register. The host system is also responsible for setting or clearing the fields in the Function Event
Mask register.
If a Card Status Changed event can occur either when the CardBus PC Card interface is powered up
or powered down, and the card has an auxiliary power source, then the Wakeup functionality must
be implemented on the card.
The requirements of retaining the field settings throughout power cycling or reset, however, do not
apply to the cards which do not have any auxiliary power source. Such cards cannot implement the
system or interface Wakeup protocol. The host system must not accept spurious signaling on the
CSTSCHG line during power cycling of the interface as a valid Status Changed interrupt or the
system Wakeup event.
5.2.11.3 Register Descriptions

The Function Event, Function Event Mask, Function Present State, and Function Force Event
registers have some corresponding fields with the same names. These fields reflect the events which
can cause the system (or the CardBus PC Card interface) wake up to be signaled on the CSTSCHG
line. With the exception of the Interrupt request field, these fields also reflect the events which are
signaled to the host system as Status Changed interrupt on the CSTSCHG line when the interface
power is on.
When a capability is not implemented, writes to the associated status register field(s) are ignored.
Refer to the table in 5.2.11.3.5 Default Field Values for the values of status register fields returned
when a register is read and the associated capabilities are not implemented.
5.2.11.3.1 Function Event Register

A CardBus PC Card uses each card function's Function Event register to generate Status Changed
interrupts or the host system Wakeup which are signaled on the CSTSCHG line. The fields in this
register, when set, indicate that a change in the function status has occurred. A field in this register
is set when the corresponding field in the Function Present State register changes its value. The
Function Event register can be read or written. Writing "1's" into a field clears the field, writing "0's"
has no effect. Card Services must read this register and the Function Present State register to
determine the cause of the interrupt. Card Services is responsible for clearing the appropriate fields
after determining why the status changed interrupt occurred.

31 16 15 14 5 4 3 2 1 0
Reserved Reserved
Interrupt (INTR)
General Wakeup (GWAKE)

Battery Voltage Detect 1 (BVD1)
Ready/Busy (READY)
Write Protect (WP)
Figure 5-21: CardBus PC Card Function Event Register
Bit Field Name Description

0 WP Write Protect bit field is set (1) whenever the WP field in the Function Present State
register changes state. Writing a 1 to this field by the host system clears the field.
Writing a 0 has no effect. If the function can generate system/interface Wakeup when
WP changes state, then this field must not be affected by CRST# or power cycling of
the interface. Otherwise, the state after reset is 0.
1 READY Ready bit field is set (1) whenever the READY field in the Function Present State
register changes from the busy state to the ready state. Writing a 1 to this field by the
host system clears the field. Writing a 0 has no effect. If the function can generate
system/interface Wakeup when READY changes from busy to the ready state, then
this field must not be affected by CRST# or power cycling of the interface. Otherwise,
the state after reset is 0.
2 BVD2 Battery Voltage Detect 2 bit field is set (1) whenever the BVD2 field in the Function
Present State register changes state. Writing a 1 to this field by the host system
clears the field. Writing a 0 has no effect. If the function can generate system/interface
Wakeup when BVD2 changes state, then this field must not be affected by CRST# or
power cycling of the interface. Otherwise, the state after reset is 0.
3 BVD1 Battery Voltage Detect 1 bit field is set (1) whenever the BVD1 field in the Function
Present State register changes state. Writing a 1 to this field by the host system
clears the field. Writing a 0 has no effect. If the function can generate system/interface
Wakeup when BVD1 changes state, then this field must not be affected by CRST# or
power cycling of the interface. Otherwise, the state after reset is 0.
4 GWAKE General Wakeup bit field is set (1) whenever the GWAKE field in the Function
Present State register changes its state from 0 to 1. Writing a 1 to this field by the host
system clears the field. Writing a 0 has no effect. This field is used to generate a
system or interface Wakeup upon event(s) which are not represented by INTR, WP,
READY, BVD2, or BVD1 fields. If GWAKE field is implemented in the Function
Present State register, then it must also be implemented in this Function Event
register and it must not be affected by CRST# or power cycling of the interface.
Otherwise, this field must be treated as reserved.
5-14 Reserved These fields are reserved for future use.
15 INTR Interrupt bit field is set (1) when the INTR field in the Function Force Event Register
is set. The host system clears the INTR field by writing a 1 to this field. Writing a 0 to
this field has no effect. If the function can generate Wakeup when this field is set, then
this field must not be affected by CRST# or power cycling of the interface. Otherwise,
the state after reset is 0.

5.2.11.3.2 Function Event Mask Register

This register gives software the ability to control what events in the function cause the Status
Changed interrupts or the host system Wakeup. When a field is set in this register, it enables the
corresponding field in the Function Event register to cause a Status Changed interrupt or the system
Wakeup. Also, the Function Event Mask register provides capability to separately mask the system
Wakeup signaling. Since each function on a CardBus PC Card contains its own set of registers, the
masking is independent for each function on the card. This register can be read or written.
31 16 15 14 13 7 6 5 4 3 2 1 0
Reserved Reserved
Interrupt (INTR)
Wakeup (WKUP)
PWM Audio Enable (PWM)
Binary Audio Enable (BAM)
Battery Voltage Detect, BVD[2::1]
Ready/Busy (READY)
Write Protect (WP)
Figure 5-22: Function Event Mask Register

0 WP Write Protect mask. When cleared (0), setting of the WP field in the Function Event
register will not cause the Status Changed interrupt or the system Wakeup. Setting
this field to 1, enables the WP field in the Function Event register to generate the
Status Changed interrupt (and the system Wakeup if the WKUP field in this Function
Event Mask register is also set). If the function can generate Wakeup when the WP
field in the Function Event register is set, then this field must not be affected by
CRST# or power cycling of the interface. Otherwise, the state after reset is 0.
1 READY Ready mask. When cleared (0), setting of the READY field in the Function Event
register will not cause the Status Changed interrupt or the system Wakeup. Setting
this field to 1, enables the READY field in the Function Event register to generate the
Status Changed interrupt (and the system Wakeup if the WKUP field in this Function
Event Mask register is also set). If the function can generate Wakeup when the
READY field in the Function Event register is set, then this field must not be affected
by CRST# or power cycling of the interface. Otherwise, the state after reset is 0.
2-3 BVD[2::1] Battery Voltage Detect [2::1] mask. When cleared (00), setting of the BVD1 or BVD2
field in the Function Event register will not cause the Status Changed interrupt or the
system Wakeup. Setting this field (11), enables the BVD1 or BVD2 field in the
Function Event register to generate the Status Changed interrupt (and the system
Wakeup if the WKUP field in this Function Event Mask register is also set).
Encodings 01 and 10 are not valid for this field. If the function can generate Wakeup
when the BVD1 or BVD2 field in the Function Event register is set, then this field
must not be affected by CRST# or power cycling of the interface. Otherwise, the state
after reset is 00.


4 GWAKE General Wakeup mask. When cleared (0), setting of the GWAKE field in the Function
Event register will not cause the system/interface Wakeup. Setting this field to 1,
enables the GWAKE field in the Function Event register to generate the system
Wakeup if the WKUP field in this Function Event Mask register is also set. If GWAKE
field is implemented in the Function Event and Function Present State registers, then
it must also be implemented in this Function Event Mask register and it must not be
affected by CRST# or power cycling of the interface. Otherwise, this field must be
treated as reserved.
5 BAM Binary Audio Enable field. When cleared (0), Binary Audio Mode is disabled. When
set (1), Binary Audio signal is enabled on the CAUDIO pin. If the PWM Audio Enable
field is also set, the state of the CAUDIO pin is undetermined. The state after reset is
0.
6 PWM PWM Audio Enable field. When cleared (0), PWM Audio Mode is disabled. When set
(1), PWM Audio encoded signal is enabled on the CAUDIO pin. If the BAM field is
also set, the state of the CAUDIO pin is undetermined. The state after reset is 0.
14 WKUP Wakeup mask. When cleared (0), the Wakeup function is disabled, i.e., setting a field
in the Function Event register will not cause the function to signal the system Wakeup
even if the corresponding event mask field is set in this Function Event Mask
Register. Setting this field to 1, enables the fields in the Function Event register to
generate the system/interface Wakeup on the CSTSCHG line (if the corresponding
event mask field is also set in this Function Event Mask Register). If the function can
generate system/interface Wakeup, then this field must be implemented and must not
be affected by CRST# or power cycling of the interface. Otherwise, this field must be
treated as reserved.
15 INTR Interrupt mask. When cleared (0), setting of the INTR field in either the Function
Present State register or the Function Event register will neither cause assertion of
the functional interrupt on the CINT# line while the CardBus PC Card interface is
powered up, nor the system Wakeup while the interface is powered off. Setting this
field to 1, enables the INTR field in both the Function Present State register and the
Function Event register to generate the functional interrupt (and the system Wakeup if
the corresponding WKUP field in this Function Event Mask register is also set). If the
function can generate Wakeup when the INTR field in either the Function Present
State register or the Function Event register is set, then this field must not be affected
by CRST# or power cycling of the interface. Otherwise, the state after reset is 0.
5.2.11.3.3 Function Present State Register

This read-only register reflects the current state of the function.
31 16 15 14 5 4 3 2 1 0
Reserved Reserved
Interrupt (INTR)

Battery Voltage Detect, BVD[2::1]
Ready/Busy (READY)
Write Protect (WP)
Figure 5-23: Function Present State Register


0 WP Write Protect bit field reflects the current state of the Write Protect switch. When it is
set (1), the card is write protected (not writeable). When this field is 0, the card is not
write protected. If a memory card has no Write Protect switch but the card is always
writeable, this field must be 0 (e.g., connected to GND). If the card is never writeable,
the field must be 1 (e.g., connected to VCC). This field is not affected by CRST#. If the
function can generate Wakeup when WP changes state, then this field must not be
affected by power cycling of the interface.( See 4.6.3 Write Protect Function and
see also the Metaformat Specification.)
1 READY READY bit field reflects the current state of the function. When it is set (1), the
function is ready to perform a new operation, e.g., accept a data transfer command.
When this field is 0, the function is busy, e.g., processing a previous command or
performing initialization. This field is not affected by CRST#. If the function can
generate Wakeup when READY changes state, then this field must not be affected by
power cycling of the interface.
2-3 BVD[2::1] Battery Voltage Detect [2::1] field reflects the current state of the card's battery. The
status is encoded as following:
BVD2 BVD1
1 1 Battery operational
0 1 Battery needs to be replaced
X 0 Battery is not providing operational voltage
This field is not affected by CRST#. If the function can generate Wakeup when
BVD[2::1] changes state, then this field must not be affected by power cycling of the
interface.
4 GWAKE General Wakeup field reflects the current state of the Wakeup event(s) which are not
represented by INTR, WP, READY, or BVD[2::1] fields. This field remains set (1),
until the condition which caused the Wakeup request has been serviced. It is cleared
(0) by the function when the event has been serviced. This field is not affected by
CRST# or power cycling of the interface.
15 INTR Interrupt field represents the internal state of a function specific interrupt request. This
field remains set (1), until the condition which caused the interrupt request has been
serviced. It is cleared (0) by the function when the event has been serviced. The value
of INTR field is available even if the interrupts have not been configured. This field is
not affected by CRST#. If the function can generate Wakeup when the interrupt
occurs, then this field must not be affected by power cycling of the interface.
5.2.11.3.4 Force Event Capability

This provides the ability to simulate events by forcing values in the Function Event register,
primarily for debug purposes. This is done by generating writes to the Function Force Event
register. Note that this is not a physically implemented register. Rather, it is an address at which
the Function Event register can be written. The effect of a write to this address will be reflected in
the Function Event register. However if the function is active, other events on the card may alter the
contents of the Function Event register before it is read.

31 16 15 14 5 4 3 2 1 0
Reserved Reserved
Interrupt (INTR)

Ready/Busy (READY)
Write Protect (WP)
Figure 5-24: Function Force Event Register

0 WP Write Protect. Writing a 1 to this bit field simulates a change in the state of the Write
Protect switch, and sets the WP field in the Function Event register. However, the
WP field in the Function Present State register is not affected and continues to reflect
the current state of the switch (if it exists). Writing a 0 to this field has no effect.
1 READY Ready. Writing a 1 to this bit field sets the READY field in the Function Event
register. However, the READY field in the Function Present State register is not
affected and continues to reflect the actual state of the function. Writing a 0 to this field
has no effect.
2 BVD2 Battery Voltage Detect 2. Writing a 1 to this bit field sets the BVD2 field in the
Function Event register. However, the BVD2 field in the Function Present State
register is not affected and continues to reflect the current state of the battery. Writing
a 0 to this field has no effect. 0.
3 BVD1 Battery Voltage Detect 1. Writing a 1 to this bit field sets the BVD1 field in the
Function Event register. However, the BVD1 field in the Function Present State
register is not affected and continues to reflect the current state of the battery. Writing
a 0 to this field has no effect.
4 GWAKE General Wakeup. Writing a 1 to this bit field sets the GWAKE field in the Function
Event register. However, the GWAKE field in the Function Present State register is
not affected and continues to reflect the current state of the Wakeup request. Writing a
0 to this field has no effect.
15 INTR Interrupt. Writing a 1 to this bit field sets the INTR field in the Function Event register.
However, the INTR field in the Function Present State register is not affected and
continues to reflect the current state of the functional interrupt. Writing a 0 to this field
has no effect.

5.2.11.3.5 Default Field Values

The following table indicates the value of each field that shall be returned when the Function Event,
Function Event Mask, or Function Present State registers are read and the capability associated with
the field is not implemented in the CardBus PC Card.
Bit Field Name Function Event Register Function Event Mask Function Present State
Register Register
0 WP clear (0) clear (0) clear (0)
1 READY clear (0) clear (0) set (1)
2 BVD2 clear (0) clear (0) set (1)
3 BVD1 clear (0) clear (0) set (1)
4 GWAKE clear (0) clear (0) clear (0)
5 BAM Reserved (0) clear (0) Reserved (0)
6 PWM Reserved (0) clear (0) Reserved (0)
7 - 13 Reserved Reserved (0) Reserved (0) Reserved (0)
14 WKUP Reserved (0) clear (0) Reserved (0)
15 INTR clear (0) clear (0) clear (0)
16 - 31 Reserved Reserved (0) Reserved (0) Reserved (0)
5.2.12 Card Audio

CardBus PC Card supports two types of audio signals: a single amplitude, Binary waveform,
and/or Pulse Width Modulation (PWM) encoded signal.
The CAUDIO signal may be available only when both the PC Card and the host system support
the same type of audio functions, and when both the card and the system's socket have been
configured to enable the signal. CAUDIO provides an interface to the system's speaker using one of
the two protocols, depending on capabilities of the host system and the PC Card.
In the Binary Audio mode, this signal is identical to the SPKR# signal definition given for 16-bit PC
Cards (i.e., it provides a single-amplitude, on-off (binary), audio waveform intended to drive the
host system's loudspeaker). The signal to the speaker should be generated by taking an exclusive-
OR of the CAUDIO signals (SPKR# signals from 16-bit PC Cards) from all those cards providing
Binary Audio. When no audio signal is present, or if the card does not support the Binary Audio
mode, the CAUDIO signal shall be held inactive low.
In the Pulse Width Modulation (PWM) mode, CAUDIO provides a PWM encoded signal on a 22.05
KHz carrier. The portion of each 45.3515 µs period during which the signal is held high corresponds
to a voltage between GND and VCC, i.e., a 50% duty cycle represents 0.5 VCC, and a constant low
signal represents 0.0 Vcc (or GND). This relation holds at the system-side decoding point. The
inverse relationship is true for the card's encoder if the audio signal being encoded is from an
analog source. Similarly, if the card's source for the PWM waveform is a digital representation, then
the input values from 0 to 255 are encoded into a corresponding duty cycle, i.e., 255 gives DC VCC,
0 gives DC GND, and 127 gives a 50% duty cycle waveform.
A PC Card would normally generate the PWM encoded signal using one of two methods. In the
first method, a set of stored 8-bit values and an 8-bit counter running at 5.6448 MHz (or a 22.05 KHz
rollover frequency) are used. Comparing the two magnitudes creates the PWM signal.

The second method for generating a PWM signal is using an analog input. The analog input and a
"ramp wave" are used as inputs to a comparator, and the output is the PWM signal. If the ramp
wave is generated by ramping a digital-to-analog converter (DAC), this method can also be used to
convert the signal to a store-able digital format.
On the system side, the PWM signal is fed into an integrator to re-create the analog waveform.
Several signals can be summed through multiple isolation capacitors at the input node of the
integrator, or by summing outputs of multiple integrators. The integrator should work over the
frequency range of 50 Hz to 10 KHz.
PC Cards which support the Binary Audio mode are required to support the Binary Audio Enable
field in the Card Function Event Mask Register and the TPCE_CBMI field in the Configuration
Table Entry Tuple, CISTPL_CFTABLE_ENTRY_CB. PC Cards which support the PWM Audio mode
are required to support the PWM Audio Enable field in the Card Function Event Mask Register and
the TPCE_CBMI field in the Configuration Table Entry Tuple, CISTPL_CFTABLE_ENTRY_CB. This
allows the system to selectively enable, disable, and configure the audio functions on a card by card
basis.
5.2.13 Special Design Considerations

This section describes other topics related to CardBus PC Card, which are not part of the basic
operation of the interface.
5.2.13.1 Multiple Retry Termination

A host CardBus PC Card bridge, in general, should implement a counter such that when the count
expires, the bridge does not retry an access. The counter is incremented (decremented) when an
access is terminated with retry. The counter is reset whenever the master transfers data. This is not a
requirement but is recommended to guarantee that an access will not continue to be terminated
with retry, thereby preventing the processor from handling an interrupt that could be indicating an
error condition.
5.3 CardBus PC Card Electrical Specification
5.3.1 Overview
This section defines all the electrical characteristics and constraints of CardBus PC Card components,
systems, and cards, including pin assignment on the PC card connector. The CardBus PC Card
electrical definition provides for a 3.3 V signaling environment. This should not be confused with 5
V and 3.3 V component technologies. A "5 V component" can be designed to work in a 3.3 V
signaling environment and vice versa; component technologies can be mixed in either signaling
environment. The signaling environments cannot be mixed.
However, supporting 16-bit PC Cards as well as CardBus PC Cards in the same socket implies that
the CardBus PC Card adapter must contain universal buffers capable of supporting 5 V, 3.3 V, and
eventually lower voltage PC Cards. This means that the CardBus PC Card adapter must use the
signaling convention of the PC Card in the socket (3.3 V or lower for CardBus PC Cards, 5 V or
lower for 16-bit PC Cards).
Supporting 16-bit PC Cards also means that CardBus PC Card's interconnect between the adapter
and the component on the PC Card must not have traces for signals in common between two
sockets. Protocol differences between CardBus PC Cards and 16-bit PC Cards make it impossible for
both cards to function on the same bus at the same time.

Finally, it means that the 68-pin connector must be used. This connector provides a limited number
of ground pins, creating a di/dt noise problem that is aggravated by CardBus PC Card's need to
switch a high speed, 32-bit interface over it. This necessitates managing di/dt noise across the
interface so that a clean ground reference can be maintained on the card.
5.3.1.1 Dynamic vs. Static Drive Specification

The need to control di/dt noise forces the use of buffers with edge rates slow enough that the
interconnect on the motherboard and PC Card do not exhibit transmission line characteristics.
However, CCLK needs to deliver crisp, monotonic edges to the PC Card. Usage of the same buffer
type prescribed for the address/data and control signals would result in uncontrollable clock skew.
Therefore CCLK uses a fast edge rate driver sized to switch the bus half way to the required high or
low voltage. As this electrical wave propagates down the bus and reflects off the unterminated end
back to the point of origin, the initial voltage excursion is doubled to achieve the required voltage
level. The bus driver is actually in the middle of its switching range during this propagation time.
During each edge, CCLK spends this relatively large proportion of time in transient switching,
where DC current is minimal, so the typical approach of specifying buffers based on its DC current
sourcing capability is not useful. Instead, it is specified in terms of its AC switching characteristics.
Specifically, the voltage to current relationship (V/I curve) of the driver through its active switching
range is the primary means of specification. These V/I curves are targeted at achieving acceptable
switching behavior in point-to-point configurations with one load on the motherboard and one on
the PC Card. If the motherboard implementation uses stubs, it must ensure that CCLK edge rate
requirement are satisfied.
5.3.2 Component Specifications

This section specifies the electrical and timing parameters for CardBus PC Card components, both on
the PC Card and on the motherboard. The 3.3 V environment is based on VCC relative switching
voltages, and is an optimized CMOS approach. The intent of the electrical specification is that
components connect directly together, whether on the planar or a PC Card, without any external
buffers or other "glue."
The CardBus PC Card interconnect is estimated as a capacitive load and the address/data and
control signal output buffers are specified with respect to driving this load. The rise and fall times
specified provide a range that can deliver signal edge rates that meet timing requirements while
keeping the di/dt noise within reasonable bounds.
The CCLK output buffer is specified in terms of its V/I curves. Limits on acceptable V/I curves
provide for a maximum output impedance that can achieve an acceptable first step voltage in
typical configurations, and for a minimum output impedance that keeps the reflected wave within
reasonable bounds. Pull-up and pull-down sides of the buffer have separate V/I curves, which are
provided with the parametric specifications. The effective buffer strength is primarily specified by
an AC drive point, which defines an acceptable first step voltage, both high going [V oh(AC)], and
low going [Vol(AC)], together with required currents to achieve that voltage in typical
configurations. The DC drive point specifies steady state conditions that must be maintained, but in
a CMOS environment these are minimal, and do not indicate real output drive strength. The
shaded areas on the V/I curves shown in Figure 5-25 define the allowable range for output
characteristics.
The sign on all current parameters (direction of current flow) is referenced to a ground inside the
component, i.e., positive currents flow into the component while negative currents flow out of the
component.

5.3.2.1 3.3 V Signaling Environment
5.3.2.1.1 DC Specifications
Table 5Ð7 summarizes the DC specifications for 3.3 V signaling.
Table 5Ð7 DC Specification for 3.3 V Signaling

Symbol Parameter Condition Min Max Units Notes
VCC Supply Voltage 3.0 3.6 V
Icc Supply current 1 A 1
Icc(CIS) Supply current CIS reads 70 mA 2

Config reads
Config writes
Vih Input High Voltage 0.475 VCC VCC + 0.5 V
Vil Input Low Voltage -0.5 0.325 VCC V
Vitoh Input Device Turn-off Voltage 0.7 VCC V 3

(high)
Vitol Input Device Turn-off Voltage (low) 0.2 VCC V
Iil Input Leakage Current 0 < Vin < VCC +10 µA 4
Voh Output High Voltage Iout = -150 µA 0.9 VCC V
Vol Output Low Voltage Iout = 700 µA 0.1 VCC V
Ccard Card Input Pin Capacitance 5 17 pF 5
Chost System Load Capacitance 5 22 pF 6
Cclk Card CCLK Pin Capacitance 10 22 pF 7
1. This is determined solely by the maximum current capacity of the VCC pins on the connector.
2. This only applies to configuration accesses immediately following power-up and reset. Higher current
may be drawn after permission has been given by the host system. Since CIS can be located in config
space, expansion ROM, and/or memory space, CIS reads to all of these spaces must meet this
requirement. However, writes to memory space do not.
3. This specification must be guaranteed by design, and is only important to devices built for a
battery-operated environment. It is the Vin value at which current through the input totem pole is
essentially shut off.
4. Input leakage currents include High-Z output leakage for all bi-directional buffers with High-Z outputs.
CCD1#, CCD2#, CVS1, and CVS2 do not have to meet leakage requirements.
5. The max value assumes 5 pF for the card trace, 10 pF for the buffer, and 2 pF for the connector and
vias. The min value assumes 1 pF for the card trace, 3 pF for the buffer, and 1 pF for the connector and
vias. CCD[2::1]#, CVS1, and CVS2 do not have to meet the minimum capacitance requirement.
6. The max value assumes 10 pF for the motherboard trace, 10 pF for the buffer, and 2 pF for the
connector and vias. The min value assumes 1 pF for the motherboard trace, 3 pF for the buffer, and 1
pF for the connector and vias.
7. CCLK values account for longer trace length and additional input capacitance on the input buffer.
5.3.2.1.2 AC Specifications
Inputs are required to be clamped to both ground and VCC (3.3 V) rails. When dual power rails are
used, parasitic diode paths could exist from one supply to another. These diode paths can become
significantly forward biased (conducting) if one of the power rails does not meet specifications
momentarily. Diode clamps to a power rail, as well as output pull-up devices, must be able to
withstand short circuit current until drivers can be placed in a High-Z state. (See also 5.3.3.2 Reset.)

Table 5Ð8 AC Specifications for 3.3 V Signaling

trcb Output Rise Time 0.2 Vcc - 0.6 Vcc 0.25 1.0 V / ns 1
tfcb Output Fall Time 0.6 Vcc - 0.2 Vcc 0.25 1.0 V / ns 1
Icl Low Clamp Current -3< Vin < -1 -25+(Vin+1)/0.015 mA
Ich High Clamp Current VCC+4> Vin > VCC+1 25+(Vin-VCC-1)/0.015 mA
1. This does not apply to CCLK. Minimum and maximum rates are measured with the minimum
capacitive load a driver will see (7 pF). The values ensure the fastest edge rate will not switch
rail-to-rail faster than 3.6 ns.
5.3.2.1.3 CSTSCHG Buffer Specification

As noted in 5.2 CardBus PC Card Operation, the CSTSCHG pin can be used by the CardBus PC
Card to remotely power up the system. Because the system could be powered off, the potential
exists for this pin to be shorted to GND through parasitic diodes. The design of the CardBus PC
Card's output buffer and the system's input buffer must ensure no electrical damage results. The
following rules provide a framework to ensure that CSTSCHG buffers are implemented properly:
1. The short circuit output current of the CardBus PC Card's CSTSCHG output buffer must never
exceed 1 mA.
2. The ESD diodes in the socket's CSTSCHG input buffer must be able to withstand a sustained
forward bias current of 1 mA when VCC = 0 V and Vin = 3.6 V. The input must be designed to
sustain this for an infinite amount of time.
5.3.2.1.4 CCLK AC Specifications

Table 5Ð9 summarizes the AC specifications for 3.3 V signaling on CCLK. This buffer may be
realized by using the output buffer specified in the PCI Local Bus Specification, Revision 2.0 with
a 47 Ω ±10% series termination resistor assuming the motherboard trace impedance is between 60
Ω and 90 Ω. The CardBus PC Card trace impedance is specified in 5.3.4.2.2 Impedance. A detailed
set of AC and DC characteristics are provided in that specification.

Table 5Ð9 AC Specification for 3.3 V Signaling (CCLK)

Ioh(AC) Switching 0< Vout<0.3 VCC -5 VCC Eqt'n mA 1
Current High 0.3 VCC< Vout<0.9 VCC -7.1( VCC-Vout) A mA 1, 2
(Test Point) Vout = 0.7 VCC -11.7 VCC mA 2
Iol(AC) Switching VCC> Vout>0.6 VCC 6.7 VCC Eqt'n mA 1
Current Low 0.6 VCC> Vout>0.1 VCC 11.2 Vout B mA 1, 2
(Test Point) Vout = 0.46 VCC 9 VCC mA 2
trclk Unloaded Output 0.2 VCC - 0.6 VCC 1 4 V / ns

Rise Time
tfclk Unloaded Output 0.6 VCC - 0.2 VCC 1 4 V / ns
Fall Time
1. Refer to V/I curves in Figure 5-25.
2. Maximum current requirements must be met as drivers pull beyond the first step voltage (AC drive
point). Equations defining these maximums (A, B) are provided with the respective diagrams in Figure
5-25.. The equation defined maximum should be met by design. In order to facilitate component testing,
a maximum current test point is defined for each side of the output driver.
Pull Up Pull Down

Vcc Vcc AC drive
60 Ω load line point
Voltage
0.9 test
Vcc point
0.6
Voltage
Vcc
DC
0.5 Vcc
drive point
DC drive
0.3 point
Vcc
0.1 test
AC drive Vcc
point point
60 Ω load line
Current (mA) Current (mA)

-0.5 -5 Vcc -13.8 Vcc 1.5 6.7 Vcc 11.9 Vcc
Equation A: Equation B:
Ioh = (35.8/VCC)*(Vout-VCC)*(Vout+0.4 VCC) Iol = (36.2/VCC)*Vout*(VCC-Vout)
for VCC > Vout > 0.7 VCC for 0V < Vout < 0.46 VCC
Figure 5-25 V/I Curves for 3.3 V Signaling
5.3.2.1.5 Maximum AC Ratings and Device Protection (CCLK)

A maximum AC test specification is included here as a testing recommendation, because the CCLK
interconnect contains many reactive elements, and in general must be treated as a non-terminated,
transmission line environment. The basic premise of the environment requires that a signal reflect
at the end of the line and return to the driver before the signal is considered switched.

As a consequence of this environment, under certain conditions of drivers, device topology, board
impedance, etc., the open circuit voltage at the pins of CardBus PC Card devices will exceed the
ground to VCC voltage range expected by a considerable amount. The technology used to
implement CardBus PC Card can vary from vendor to vendor, so it can not be assumed that the
technology is naturally immune to these effects. This test specification provides a synthetic worst
case AC environment, against which the long term reliability of a device can be evaluated.
These inputs to the CardBus PC Card should be capable of continuous exposure to the following test.
The test is conducted with the equivalent of a zero impedance voltage source driving a series
resistor directly into CCLK. The waveform provided by the voltage source (or open circuit voltage
including the resistor) and the resistor value is provided in Figure 5-26. This test covers the AC
operating conditions only; DC conditions are specified elsewhere.
Overshoot Test Waveform

Voltage Source Impedance 11 nS
R = 29Ω (min)
+ 7.1 V
7.1 V, p-to-p
(minimum)
0V
R 4 nS
DUT (max)
V Test 30.0 nS
(33 MHz)
Setup
+ 3.6 V
7.1 V, p-to-p
(minimum)
- 3.5 V
Undershoot Test Waveform

Voltage Source Impedance
R = 28 Ω
Figure 5-26 Test Waveform for 3.3 V Signaling (CCLK)
5.3.2.1.6 Noise Considerations

As noted earlier, the primary consideration in designing a buffer for CardBus PC Card is managing
the di/dt noise caused by the limited number of AC return paths (VCC and GND) on the 68-pin
connector. The technique(s) used to reduce this noise may exceed the signal edge rates specified in
Table 5Ð8 under some conditions. For example, adding source resistance to the P-channel and
N-channel devices of a series of strong buffers will deliver performance which meets the description
above when many signals are switching but will exhibit fast edge rates when just a few switch. This
is acceptable as long as the overall current being driven across the connector remains constant, i.e.
as long as many signals switching slowly is equivalent to a few signals switching quickly.
Note that this also means that the technique used to slow the edge rates must actually reduce the
CardBus PC Card's di/dt requirements. Methods which slow the edge rate but create large shunt
currents through the output stage will simply replace the switching current with VCC current
without correcting the di/dt noise problem.

In all cases, di/dt noise shall not exceed Vil. (See Table 5Ð7 DC Specification for 3.3 V Signaling.)
The grounded shroud connector is required for CardBus PC Card implementations. (See the
Physical Specification and see also Appendix-B, 8. CardBus PC Card Connector Test
Methodology.)
5.3.2.2 Timing Specification
5.3.2.2.1 Clock Specifications

The clock waveform must be delivered to each CardBus PC Card component in the system. In the
case of CardBus PC Cards, compliance with the clock specifications is measured at the card
component, not at the connector slot. Figure 5-27 shows the clock waveform and required
measurement points. Table 5Ð10 summarizes the clock specifications.
3.3 Volt Clock

tcyc
thigh
tlow
0.6 Vcc
0.475 Vcc
0.4 Vcc, p-to-p
0.4 Vcc
(minimum)
0.325 Vcc
0.2 Vcc
Figure 5-27 CardBus PC Card Clock Waveform
Table 5Ð10 CardBus PC Card Clock Specifications

Symbol Parameter Min Max Units Notes
tcyc CCLK Cycle Time 30 ∞ ns 1
thigh CCLK High Time 12 ns
tlow CCLK Low Time 12 ns
- CCLK Slew Rate 1 4 V / ns 2

1. In general, all CardBus PC Card components must work with any clock frequency up to 33 MHz. The
clock frequency may be changed at any time during the operation of the system so long as the clock
edges remain clean (monotonic) and the minimum cycle and high and low times are not violated. If the
clock is stopped, it must be in a low state. A variance on this specification is allowed for the CardBus
PC Card adapter which may operate the CardBus PC Card interface at any single fixed frequency up to
33 MHz, and may enforce a policy of no frequency changes.
2. Rise and fall times are specified in terms of the edge rate measured in V / ns. This slew rate must be
met across the minimum peak-to-peak portion of the clock waveform (See Figure 5-27.)

5.3.2.2.2 Timing Parameters

Table 5Ð11 provides the timing parameters for the 3.3 V signaling environment.
Table 5Ð11 3.3 V Timing Parameters

Symbol Parameter Min Max Units Notes
tval CCLK to Signal Valid Delay 2 18 ns 1, 2
ton Float to Active Delay 2 ns 1
toff Active to Float Delay 28 ns 1
tsu Input Set up Time to CCLK 7 ns 3
th Input Hold Time from CCLK 0 ns 3
trst Reset Active Time After Power Stable 1 ms 4
trst-clk Reset Active Time After CCLK Stable 100 clocks 4
trst-off Reset Active to Output float delay 40 ns 4, 5
tpulse CSTSCHG remote wakeup pulse width 1 ms 6
1. tval includes the time to propagate data from internal registers to the output buffer and drive the output to
a valid level. Minimum tval is measured from CCLK crossing Vtest to the signal crossing Vih on
falling edges and Vil on rising edges. Maximum tval is measured from CCLK crossing Vtest to the
signal's last transition out of the threshold region (Vil for falling edges, Vih for rising edges).
2. Minimum times are specified with 0 pF equivalent load; maximum times are specified with 30 pF
equivalent load. Actual test capacitance may vary, but results should be correlated to these
specifications. Systems which exceed this capacitance, due to long traces between the socket and
adapter, must reduce the CCLK frequency appropriately.
3. tsu and th are measured at Vth for rising edges and Vtl for falling edges.
4. CRST# is asserted asynchronously and negated synchronously with respect to CCLK. "CCLK Stable"
means that VCC is within tolerances (See Table 5Ð7 DC Specification for 3.3 V Signaling.) and
CCLK is meeting specifications (See Table 5Ð10 CardBus PC Card Clock Specifications.). (See
also 5.3.3.2 Reset.)
5. See 5.1.2 Signal/Pin Description for the CardBus PC Card and adapter signals which must be in a
High-Z state.
6. This parameter only applies when signaling remote wakeup over the CSTSCHG pin. All other status
change information must be signaled by asserting CSTSCHG until the resultant interrupt is serviced.
5.3.2.2.3 Measurement and Test Conditions
Vth
CCLK Vtest
Vtl
tval(min)
OUTPUT Vih
DELAY Vil
tval(max)
High-Z
Vtest Vtest
OUTPUT
ton
toff
Figure 5-28 Output Timing Measurement Conditions

Vth
CCLK Vtest
Vtl
tsu
th
Vth
Vih
inputs Vmax
INPUT valid Vil
Vtl
Figure 5-29 Input Timing Measurement Conditions
Table 5Ð12 Measurement and Test Condition Parameters

Symbol 3.3 V Signaling Units Notes
Vth 0.6 VCC V 1
Vtl 0.2 VCC V 1
Vih 0.475 VCC V
Vil 0.325 VCC V
Vtest 0.4 VCC V
Vmax 0.4 VCC V 1
1. The input test for the 3.3 V environment is done with 0.125 VCC of overdrive. Timing parameters must
be met with no more overdrive than this. Vmax specifies the maximum peak-to-peak waveform
allowed for testing input timing.
5.3.2.3 Vendor Provided Specifications

In the time frame of CardBus PC Card, many system vendors will do board-level electrical
simulation of CardBus PC Card components. This will ensure that system implementations are
manufacturable and that components are used correctly. To help facilitate this effort, as well as
provide complete information, component, connector, and PC Card vendors should make the
following information available in their data sheets:
• Pin capacitance for all pins
• Pin inductance for all pins
• Output V/I curves. Two curves should be given for each output type used: one for driving
high, the other for driving low. Both should show best-typical-worst curves. Also,
"beyond-the-rail" response is critical, so the voltage range should span -3 to 7 V for 3.3 V
signaling. Note that AC switching characteristics may be necessary depending on how the
buffer is designed.
• Input V/I curves. A V/I curve of the input structure when the output is in a High-Z state is also
important. This plot should also show best-typical-worst curves over the range of -3 to 7 V.
• Unloaded rise/fall times for each output type
• Complete absolute maximum data, including operating and non-operating temperature, DC
maximums, etc.

5.3.3 System (Motherboard) Specifications
5.3.3.1 Clock Skew

The maximum allowable clock skew between the CardBus PC Card and the CardBus PC Card
adapter is 2 ns. This specification applies not only at a single threshold point, but at all points on the
clock edge that fall in the switching range defined in Table 5Ð12 and Figure 5-30. The maximum
skew is measured between any two components22, not to the connector. To correctly evaluate clock
skew, the system designer must take into account clock distribution on the CardBus PC Card, which
is specified in Section 5.3.4.
Table 5Ð13 Clock Skew Parameters

Symbol 3.3 V Signaling Units
Vtest 0.4 VCC V
tskew 2 (max) ns
Vih
CCLK Vtest
Vil
(@Device #1)
tskew
tskew
tskew
Vih
CCLK Vtest
(@Device #2) Vil
Figure 5-30 Clock Skew Diagram
5.3.3.2 Reset
The assertion of the CardBus PC Card reset signal (CRST#) is asynchronous with respect to CCLK
while the negation is synchronous. Both edges of the CRST# signal must be monotonic through the
input switching range. The CardBus PC Card specification does not preclude the implementation of
a fully synchronous CRST#, if desired. (See Table 5Ð11 3.3 V Timing Parameters.) The Tfail
parameter provides for system reaction to any of the power rails failing to meet specifications
momentarily. If this occurs, parasitic diode paths could short circuit active output buffers elsewhere
in the system. Therefore, CRST# is asserted upon power failure in order to float the output buffers.
The value of tfail is 500 ns (maximum) from any power rail going out of specification, i.e. exceeding
specified tolerances by more than 500 mV.
The system must assert CRST# during power up, power down, or in the event of a power failure.
After CRST# is asserted, CardBus PC Card components are not considered reset until both trst and
trst-clk parameters have been met. (See Figure 5-31.)
22There may be an additional source of clock skew with which the system designer need be concerned. This occurs
between two components that have clock input trip points at opposite ends of the Vil - Vih range. In certain
circumstances, this can add to the clock skew measurement as described here. In all cases, total clock skew must
be limited to the specified number.

POWER Vnominal - X%
tfail
)(
CCLK
100 ms (typ)
PWR_GOOD
)(
trst-clk
CRST#
)(
trst trst-off
CARDBUS
High-Z
PC CARD
SIGNALS
Figure 5-31 Reset Timing
5.3.3.3 Pull-ups
CardBus PC Card control signals must always contain stable values when no agent is actively
driving the bus. This includes CFRAME#, CTRDY#, CIRDY#, CDEVSEL#, CSTOP#, CSERR#,
CREQ#, CGNT#, CPERR#, CINT#, CSTSCHG and, when used, CBLOCK#, CCLKRUN#, and
CAUDIO.
This is often accomplished through the use of pull-up resistors on the motherboard. However, the
existence of 16-bit PC Cards and protocol in this interface complicates this because some of the
pull-ups needed on the host system for CardBus PC Card conflict with pull-downs required on 16-bit
PC Cards. Therefore, the system designer must eliminate the need for these pull-ups, use
"switchable" pull-ups which can be disconnected when 16-bit PC Cards are present, or use an
alternative means such as gated input structures. Note that pull-up resistors are always required for
CSERR# and CINT# because they are open-drain outputs.
Whatever scheme is chosen, the system designer must
1. ensure stable values on all signals at all times when a transaction is not in progress. This
guarantees that cycles are not falsely detected and that input structures will not oscillate due to
input voltages remaining in the threshold region for long periods of time.
2. ensure that floating inputs, caused by an empty socket, do not create a crossover current in the
adapter's input structure. This requirement applies to all adapter inputs, not just the control
signals.

The pull-up resistors on certain CardBus PC Card signals can be removed when the following
conditions are met:
1. The pull-up on CRST# may be eliminated, alleviating current draw when an 16-bit PC Card is
present, if the adapter guarantees the signal will not be in a High-Z state when a CardBus PC
Card is present.
2. The pull-down on CSTSCHG may be eliminated as long as the adapter implements the pull-up
required for 16-bit PC Cards and ensures that remote wakeup isn't falsely signaled when the
socket is empty.
3. The pull-up on CCLKRUN# may be eliminated if clock stopping is not implemented and the
adapter never places this signal in a High-Z state. In this case, the adapter would always drive
this signal low when a CardBus PC Card is present.
4. The pull-ups on CIRDY#, CTRDY#, CDEVSEL#, and CSTOP# may be eliminated if the
adapter ensures the signal is always driven when the bus is idle. In this case, the adapter must
begin driving these signals when the bus is sampled idle and set them to a High-Z state, as
appropriate, during the address phase.
5. The pull-up on CPERR# may be eliminated if the adapter ensures the signal is always driven
when the bus is idle. In this case, the adapter must begin driving on the fourth clock after the
last data phase and set it to a High-Z state, as appropriate, two clocks after CFRAME# is
sampled asserted.
6. The pull-up on CBLOCK# may be eliminated if the adapter ensures the signal is always driven
when the bus is idle. In this case, the adapter must begin driving one clock after the CardBus
PC Card releases it and set it to a High-Z state during the same cycle CGNT# is asserted.
5.3.3.3.1 Pull-up Values for Control Signals

The minimum pull-up resistance value allowed, Rmin, is primarily driven by Iol, the DC low
output current, whereas the number of loads only has a secondary effect. On the other hand, the
maximum value allowed, Rmax, is primarily driven by the number of loads present. The range of
resistance values allowed for the 3.3 V signaling environment are provided in Table 5Ð14.
Table 5Ð14 Minimum and Maximum Pull-up Resistor Values (3.3 V signaling)
Signaling Rail Rmin Rmax
3.3 V 4.8 KΩ 45 KΩ
5.3.3.3.2 Pull-up Values for Card Detect and Voltage Sense Pins
The CCD1# and CCD2# pins require pull-up resistors either on the motherboard or integrated in
the socket adapter. The maximum resistance implemented must be sufficient to hold the CCD1#
and CCD2# inputs at a valid Voh level when no PC Card is present and the CCD[2::1]# pin is
drawing its maximum rated leakage current. The minimum resistance implemented is
recommended to be consistent with Table 4Ð19 Electrical Interface, but the actual value is a function
of how much power drain is desired when a PC Card is present. The equations for calculating this
are:

Rcd(max) = Vih(min)/Iil(max)
where Vih(min) and Iil(max) are for the adapter's CCD[2::1]# pins
Rcd(min) = recommended to be greater than 10 KΩ.
The adapter must implement CVS1 and CVS2 so that a valid Vol can be delivered to the CCD1#
and CCD2# inputs of the socket adapter. The ON resistance of the CVS[2::1] pins is a function of the
Rcd resistance, the leakage characteristics of the CCD[2::1]# and CVS[2::1] pins, and the input
threshold used for those pins. The ON resistance of the CVS[2::1] pin driving low in a CardBus PC
Card adapter can be calculated using the following relationship:
Rvsl(min) = 0
Rvsl(max) = (Vil(max))(Rcd(min))/(VCC(max) - Vil(max))
where Vil(max) is for the adapter's CCD[2::1]# and CVS[2::1] inputs
Rcd(min) is the minimum value used for Rcd
VCC(max) is 3.6 V for the 3.3 V signaling environment
When driving high, the CVS[2::1] output's on resistance must be:

1. Small enough to deliver a valid Voh level to the CVS[2::1] and CCD[2::1]# inputs, and
2. Large enough so that the socket adapter's CVS1 and CVS2 buffers are not damaged by
excessive currents when the inserted PC card has one of the CVS[2::1] pins shorted to ground.
Note that the time required to achieve a valid Voh is related to on resistance by the RC time
constant of the CVSX and CCDX# interconnect. The ON resistance of the CVSX pin driving high can
be calculated using the following relationship:
Rvsh(max) = Vih(min)/(Iil(max) for CCDX# + Iil(max) for CVS[2::1])
Rvsh(min) = function of the CVS[2::1] output buffer specification
5.3.3.3.3 Pull-up Resistor Requirements

The signal differences between the 16-bit PC Card and CardBus PC Card interfaces can lead to
different requirements regarding the location of pull-up and pull-down resistors on both the host
system and on cards. The location and type (pull-up, pull-down) of resistor for each connector pin is
summarized in the following table. Refer to Table 4Ð19 Electrical Interface for specific resistance
values.

Table 5Ð15 Pull-up/Pull-down Resistor Requirements

Pin Name Host Resistors PC Card Resistors
16-bit PC Card Interface CardBus PC 16-bit PC CardBus & 16-bit PC CardBus PC
Memory-Only I/O and Memory Card Interface Card Only 16-bit PC Card Card
Card
GND GND GND
D3 D3 CAD0 pull-down
CE1# CE1# CCBE0# pull-up
A10 A10 CAD9 pull-down
OE# OE# CAD11 pull-up
A8 A8 CCBE1# pull-down
A13 A13 CPAR pull-down
A14 A14 CPERR# Note 2 pull-down
WE# WE# CGNT# pull-up pull-up
READY IREQ# CINT# pull-up pull-up
VCC VCC VCC
VPP1 VPP1 VPP1
A16 A16 CCLK pull-down
A15 A15 CIRDY# Note 2 pull-down
A12 A12 CCBE2# pull-down
D2 D2 RFU pull-down
WP IOIS16# CCLKRUN# Note 2
GND GND GND
1. The pull-up can be integrated into the adapter's CVS[2::1] output buffers.
2. The CardBus PC Card interface does not require the host system pull-up if the conditions outlined in
5.3.3.3 Pull-ups are met. However, support for 16-bit PC Card interface cards still necessitates the
presence of the resistor.

Table 5Ð16 Pull-up/Pull-down Resistor Requirements

Pin Name Host Resistors PC Card Resistors
16-bit PC Card Interface CardBus PC 16-bit PC CardBus & 16-bit PC CardBus PC
Memory-Only I/O and Memory Card Interface Card Only 16-bit PC Card Card
Card
GND GND GND
CD1# CD1# CCD1# pull-up pull-up
D14 D14 RFU pull-down
CE2# CE2# CAD10 pull-up
VS1# VS1# CVS1 pull-up Note 1
RFU IORD# CAD13 pull-up
RFU IOWR# CAD15 pull-up
A18 A18 RFU pull-down
A19 A19 CBLOCK# Note 2 pull-down
A20 A20 CSTOP# Note 2 pull-down
A21 A21 CDEVSEL# Note 2 pull-down
VCC VCC VCC
VPP2 VPP2 VPP2
A22 A22 CTRDY# Note 2 pull-down
A23 A23 CFRAME# pull-down pull-up
VS2# VS2# CVS2 pull-up Note 1
RESET RESET CRST# Note 2 pull-up
WAIT# WAIT# CSERR# pull-up pull-up
RFU INPACK# CREQ# pull-up pull-up
REG# REG# CCBE3# pull-up
BVD2 SPKR# CAUDIO Note 3 pull-up
BVD1 STSCHG# CSTSCHG pull-up Note 2
CD2# CD2# CCD2# pull-up pull-up
GND GND GND
1. The pull-up can be integrated into the adapter's CVS[2::1] output buffers.
2. The CardBus PC Card interface does not require the host system pull-up if the conditions outlined in the
5.3.3.3 Pull-ups are met. However, support for 16-bit PC Card interface cards still necessitates the
presence of the resistor.
3. PC Cards must pull-up BVD2 (pin 62) to avoid sensing a battery low condition.

5.3.3.4 Power Sequencing

The system must assert CRST# both at power up, and whenever the VCC rail does not meet
specifications. During reset, all CardBus PC Card signals are driven to their benign state. (See also
5.1.2 Signal/Pin Description.)
5.3.3.5 System Timing Budget

When computing a total CardBus PC Card load model, careful attention must be paid to maximum
trace length and loading of CardBus PC Cards. (See 5.3.4.2 Physical Requirements.) Also, the
maximum pin capacitance must be assumed for PC Cards, whereas the actual pin capacitance may
be used for the CardBus PC Card adapter.
The total clock period can be divided into three segments. Valid output delay (t val) and input setup
time (tsu) are specified by the component specifications while total clock skew (tskew) is a system
parameter.
Due to edge rate constraints, CardBus PC Cards will not operate in a transmission line environment,
making propagation time across the interface negligible. This means that signal timing can be
measured anywhere on the net with equivalent results. This allows system designers to directly
validate interface timings at the connector for all signals except CCLK. CCLK must be compensated
for the routing delay on the CardBus PC Card.
5.3.3.6 Physical Requirements

Traces between the CardBus socket connector pad and the CardBus PC Card adapter may be
stubbed as long as loading and etch characteristics are not compromised and the stub is short
enough that it does not behave as a transmission line. All stubs shall have a length of 2 inches (50.8
mm) or less.
5.3.3.6.1 Routing and Layout of Four Layer Boards

All CardBus PC Card interface signals are required to be referenced to the host system supplied
rails. However, some motherboards may employ a split power plane especially in light of the cold
insertion requirements. While this is a standard technique, routing high speed signals directly over
this plane split can cause signal integrity problems. The split in the plane disrupts the AC return
path for the signal, creating an impedance discontinuity.
A recommended solution is to arrange the signal level layouts so that no high speed signal (e.g.,
CCLK) is referenced to both planes. Signal traces should remain entirely over one plane or the
other. Signals that must cross from one domain to the other should be routed on the opposite side of
the board so they are referenced to the ground plane, which is not split. If this is not possible, and
signals must be routed over the plane split, the two planes should be capacitively tied together
(motherboard plane decoupled directly to CardBus PC Card plane) with 0.01 µF high-speed
capacitors for each four signals crossing the split, and that the capacitor be placed not more that 0.25
inches (6.35 mm) from the point the signals cross the split.
5.3.3.6.2 Motherboard Impedance

There is no bare board impedance specification for motherboards. However, the length and signal
velocity must allow a valid logic level to be presented at the far end of the trace within the specified
amount of time. Because of the edge rate restrictions in this specification, CardBus PC Card will not
be operating in a transmission line environment. Therefore, the system designer must make sure

the capacitance presented by the motherboard trace, any stubbed components, and the CardBus PC
Card adapter does not exceed the capacitance specified in Table 5Ð7.
5.3.4 CardBus PC Card Specifications
5.3.4.1 Power Requirements
5.3.4.1.1 Decoupling
Under typical conditions, the VCC plane to ground plane capacitance will provide adequate
decoupling for the VCC connector pins. The maximum trace length from a connector pad to the
VCC/GND plane via shall be 0.25 inches (6.35 mm) assuming a 20 mil trace width. However,
additional local decoupling will still be needed for components on the PC Card.
5.3.4.1.2 External Power Supplies

All signals which pass through the CardBus PC Card connector shall switch between the ground
and VCC levels which are provided to the interface by the host system. Those supplies shall be used
to provide the current sink/source capacity for all such signals and reference for semiconductor
substrates and clamping diodes which may be forward biased by CardBus PC Card interface
signals. Any signal translation to/from signals referenced to other power supplies must be
performed by the PC Card/system maker in such a way that it is invisible to the interface. The host
system VCC may be used to power PC Card functions other than the interface, but no other power
supply may be used to power the interface.
CSTSCHG, used to initiate remote wakeup, is exempt from this rule since it must be referenced to
an external power supply. This CardBus PC Card output must always use the 3.3 V signaling
convention to avoid interoperability problems.
5.3.4.2 Physical Requirements
5.3.4.2.1 Trace Length Limits

Trace lengths from the CardBus PC Card connector pad to the CardBus PC Card device are as
follows:
• The maximum trace lengths for all interface signals are limited to 1.5 inches (38.1 mm).
• The trace length for the CCLK signal is 2.5 inches ± 0.1 inches (63.5 + 2.54 mm) and must be
routed to only one load.
5.3.4.2.2 Impedance
The unloaded characteristic impedance (Z0) of the signal traces on the CardBus PC Card shall be
controlled to be in the 60 - 90Ω range. The trace velocity must be between 150 and 190 ps/inch (381
and 483 ps/cm).

5.3.4.2.3 Signal Loading

CardBus PC Card signals must be limited to one load on the expansion card. Violation of CardBus
PC Card trace length or loading limits will compromise system signal integrity. It is specifically a
violation of this specification for CardBus PC Cards to:
• Attach an expansion ROM directly (or via bus transceivers) to any CardBus PC Card pins.
• Attach two or more devices on a CardBus PC Card, unless they are placed behind a CardBus PC
Card-to-CardBus PC Card bridge.
• Attach any logic (other than a single CardBus PC Card device) that snoops CardBus PC Card
pins.
• Use CardBus PC Card component sets that place more than one load on each CardBus PC Card
pin; e.g., separate address and data path components.
• Use a CardBus PC Card component that has more than 10 pF capacitance per pin (12 pF for
CCLK).
5.4 CardBus PC Card Programming Model
5.4.1 Overview
CardBus PC Cards operate in a dynamic environment similar to 16-bit PC Cards. The CardBus PC
Card system programming environment extends the existing 16-bit PC Card software model as
required to support the new features of CardBus PC Card. Additionally, the CardBus PC Card
programming model continues to support 16-bit PC Cards.
This section describes the organization of a CardBus PC Card which drives many of the decisions
concerning programming model design.
5.4.2 Card Organization

A CardBus PC Card's organization may be viewed in the following hierarchy:
• The card is divided into one or more functions. There may be up to 8 functions associated with a
card. If implemented, functions 0-7 must each have a separate configuration space.
• Each function is composed of one or more of the following physical spaces:
1. configuration space (required to be present)
2. memory space
3. I/O space
4. expansion ROM
• Each function has the following defined and standardized logical spaces. All logical spaces are
accessible by software clients. (See the Card Services Specification.)
1. configuration header space Ñ corresponds physically to the first 64 bytes of the configuration
space.
2. status registers Ñ located physically in memory space. (See also 5.2.11.3 Register
Descriptions)
A CardBus PC Card is required to have at least one function. Each function is required to
implement a configuration space. The presence and location of other functions and physical spaces

on the card is determined via a combination of the presence of configuration space registers and the
descriptions included in the function's CIS.
For CardBus PC Card systems, 16-bit PC Card mappings are supported on the same adapter with
Base Address Register mappings. Note that 16-bit PC Card mappings only apply to 16-bit PC Cards
and Base Address Register mappings only apply to CardBus PC Cards.
CardBus PC Card has a 32-bit uniform address space, meaning that a given address, as presented to
both cards and system, refers to a unique location in this address space. It does not, for example,
refer to some offset within an individual card space. This eases the addressing required for bus
mastering by allowing the bus master to present addresses which do not require further translation.
An actual host system address space may be less than that which would be created by a full 32-bit
address space. In this case the actual address space is still uniform, but cards must be mapped into
the reduced address space; any CardBus PC Card address bits which exceed the host system address
space must be 0.
There is no simple direct analogy between CardBus PC Card memory spaces and 16-bit PC Card
Common and Attribute Memory address spaces. Instead, each CardBus PC Card space is
individually mappable via its corresponding Base Address Register. In addition, to support
processor independence, all CardBus PC Card I/O spaces must be mappable into host memory
space. This requires that a Memory Base Address Register be provided for each I/O Base Address
Register or set of I/O Base Address Registers. A card space is mapped into the host system address
space by assigning a host system address to the Base Address Register for the card space. Thus the
Base Address Register uniquely identifies the card space's location in the global system address
space. Card spaces do not share their host system addresses with other card spaces. A card space is
not mappable in finer granularity than that described by its associated Base Address Register, even
when a portion of the card space described by the Base Address Register is unpopulated.
The following figures provide mapping examples of the various spaces on a CardBus PC Card using
the Base Address Register mapping paradigm. A Base Address Register maps the beginning of a
given card address space into Host System address space.

Host System
Host
System
Memory
Address
Space
Card
Memory Base Address Register Memory
I/O Base Address Register Space 2
Memory Base Address Register
I/O Space
Expansion ROM Base Address

Memory Space 1
Device
Dependent
Region
Expansion
ROM
Figure 5-32 Card with Memory and I/O Space in Host System with no Separate I/O Space
Figure 5-32 shows a card with I/O space in a host system having no separate host I/O space,
requiring that the card space be memory-mapped. This is accomplished by using the memory Base
Address Register corresponding to that space, rather than the I/O Base Address Register which is
not supported by the host system. These Base Address Registers must be provided in order, with
the I/O Base Address Register (or Registers) immediately preceding the memory Base Address
Register, to avoid inadvertent double mapping, i.e. there may be a memory Base Address Register
following each I/O Base Address Register to map the I/O space, or a contiguous set of I/O Base
Address Registers may be followed by a single memory Base Address Register which maps all of
the I/O spaces described by the set.

Host System
Host
System
Memory
Address
Space
Card
Space 2

Memory Space 1
Device
Dependent
Region
Expansion
ROM
Figure 5-33 Memory-only Card in Host System

A PC Card is not required to have any I/O spaces, and thus might contain only memory spaces, as
in Figure 5-33. In this example, an expansion ROM is included, which is another optional
component of a CardBus PC Card.
Host System
Host Host
System System
I/O Memory
Address Address
Space Space
Card
I/O Space 1
I/O Base Address Register
I/O Base Address Register I/O Space 2
Device
Dependent
Region
Figure 5-34 I/O Space-only Card in a Host System with a Separate I/O Space
Figure 5-34 depicts a card that has I/O spaces and no memory spaces in a system with a separate
host I/O space. Note that the card I/O space could be memory-mapped as in Figure 5-32.

Host System
Host Host
System System
I/O Memory
Address Address
Space Space
Card
I/O Base Address Register Space 2
Memory Base Address Register I/O Space

Memory Space 1
Device
Dependent
Region
Expansion
ROM
Figure 5-35 Card and Host with All Spaces Described
Figure 5-35 shows a card having all of the allowable card spaces, and using both host system
memory space and a separate host I/O space.
The programming model for CardBus PC Card takes into consideration all of the above spaces, both
in describing what types of configuration information may reside where and in defining how card
and system software may gain access to a given space. Tuples may reside in any card space except
I/O space and the first 64 bytes of configuration space. For complete information on tuple definitions
and tuple chain traversal, see the Metaformat Specification.
Each function on a CardBus PC Card has a set of four status registers associated with it. (See 5.2
CardBus PC Card Operation.) These registers are located in that function's memory space at the
location given by the CISTPL_CONFIG_CB tuple in that function's CIS. (See the Metaformat
Specification.)
5.4.2.1 Configuration Space

The CardBus PC Card configuration space is a 256 byte memory region which is accessed during a
configuration access cycle. Configuration space is divided into two parts:

• a mandatory 64 byte predefined header.

• a device-dependent region which is always physically present, but which might not be
implemented by the card and used by its software.
Cards have a separate configuration space for each implemented function.
The CardBus PC Card configuration space is as described in Figure 5-36. Following the figure each
element is defined. "Reserved" indicates that the register is reserved for future use. "Allocated"
indicates that the register is not defined for CardBus PC Card and must not be redefined as other
environments may use the register. The purpose of the "Allocated" registers is to maintain
compatibility between CardBus PC Card and other environments. CardBus PC Card system
software must not make use of any of the information which may be stored in these "Allocated"
fields.

All unimplemented registers must return all 0's when read. Registers which are marked "Allocated"
may contain readable values. However, these values will be ignored by all CardBus PC Card
software and no programmatic interface is provided with which to access them.
31 16 15 0
Allocated Allocated 00h
Status Command 04h
Allocated Allocated 08h
BIST Header Type Latency Timer Cache Line Size 0Ch

Base Address Register 10h

Pre-Defined Header
Base Address Register 1Ch
64 bytes
CIS Pointer 28h

Reserved 2Ch
Expansion ROM Base Address 30h
Reserved Cap_Ptr 34h

Reserved 38h
Allocated Allocated Interrupt Pin Allocated 3Ch

Beginning of Device Dependent Space 40h
44h
Device Dependent Space Tuple Space

192 bytes Tuple Space
End of Device Dependent Space FFh
Figure 5-36 CardBus PC Card Configuration Space
CardBus PC Card header fields and registers are defined in the following sections. (See also
5.4.2.1.13 Register Summary.)

5.4.2.1.1 Command
This register specifies a function's ability to generate and respond to the different access cycles
possible for CardBus PC Card. When this register has a value of 0, the function accepts only
configuration accesses. Configuration accesses are required to be supported by all functions on all
cards as a minimum level of functionality.
Individual fields in the Command register may or may not be implemented depending on a
function's use. For instance, functions for which no I/O accesses are possible should not implement a
writable field at location 0. After a card is mapped into the host system, system software will enable
the appropriate accesses (memory and/or I/O) by setting the memory and/or I/O bits in the
Command register. After the CRST# signal is asserted, all fields in the Command register are reset
(given a value of 0). Additionally, after the card reset is complete, the Fast Back-to-Back Enable field
will contain an appropriate value based on the capabilities of the system. At this time (after the card
is reset) the client and/or the system software may reconfigure the card as necessary. Figure 5-37
shows the layout of the register and Table 5Ð17 explains the meanings of the different fields in the
Command register.
15 10 9 8 7 6 5 4 3 2 1 0
Reserved
Fast Back-to-Back Enable

SERR# Enable
Wait Cycle Control
Parity Error Response
VGA Palette Snoop
Memory Write and Invalidate Enable
Special Cycles
Bus Master
Memory Space
I/O Space
Figure 5-37 COMMAND Register Layout

Table 5Ð17 COMMAND Register Field Definitions

0 I/O Space Specifies whether a function responds to I/O space accesses. If reset, the function
does not respond to I/O space accesses. If set, the function responds to I/O space
accesses. If the Memory Space field is reset and this field is reset, then the card is
accepting only configuration accesses.
1 Memory Space Specifies whether a function responds to memory space accesses. If reset, the
function does not respond to memory space accesses. If set, the function responds to
memory space accesses. If the I/O Space field is reset and this field is reset, then the
card is accepting only configuration accesses.
2 Bus Master Specifies whether a function can act as a master on the bus. If reset, the function may
not generate bus accesses. If set, the function may behave as a bus master.
3 Special Cycles Specifies whether a function responds to Special Cycle operations. If reset, the
function ignores all Special Cycle operations. If set, the function may monitor Special
Cycle operations.
4 Memory Write and Specifies whether this master may generate the Memory Write and Invalidate
Invalidate Enable command. If reset, Memory Write must be used. If set, masters may generate the
command. This field must be implemented by masters that can generate the Memory
Write and Invalidate command.
5 VGA Palette Snoop Specifies how palette registers are handled by VGA compatibles. If reset, the function
should treat palette accesses like all other accesses. If set, special palette snooping
behavior is enabled (i.e. the function must not respond). VGA compatibles must
implement this field.
6 Parity Error Response Specifies how the function responds to parity errors. If reset, the function must ignore
any parity error that it detects and continue normal operation. If set, when a parity
error is detected, the function must take whatever action is defined for it in that event.
All functions must implement this bit field. Functions must generate parity even if their
parity checking mechanism is disabled.
7 Wait Cycle Control This controls whether or not a card does address/data stepping. If reset, the card does
not do stepping. If set, the card does stepping. If a card always does stepping, or never
does it, then this field may be read-only. For cards that can do either, however, the
field must be read/write and must be initialized to 1 after the card is reset. This field
has the same value for all of the functions on a card.
8 SERR# Enable This controls whether or not the SERR# output buffer is enabled. If reset, the SERR#
output buffer is disabled. If set, the SERR# output buffer is enabled. All functions must
implement this field. This field and the Parity Error Response field at location 6 must
both be set in order for address parity errors to be reported.
9 Fast Back-to-Back This controls whether or not a master can do fast back-to-back transactions to
Enable different devices. This will be set by system software if the adapter and the card are
fast back-to-back capable. If reset, fast back-to-back transactions are only allowed to
the same agent. If set, the master is allowed to generate fast back-to-back
transactions to different agents.
10-15 Reserved.
5.4.2.1.2 Status
This register holds run-time status information for bus related events. (See Figure 5-38: STATUS
Register Layout and Table 5Ð18 STATUS Register Field Definition.) Functions implement fields
based on the presence of functionality, and should not implement fields they will not use. For
instance, a function which acts as a target but will never signal target-abort, should not implement
the Signaled Target Abort field at location 11.
This register can be read without side-effects. Writes are slightly different in that fields can be reset,
but not set. A field is reset whenever the register is written and the data in the corresponding
location is a 1. For instance, to clear the field at location 14 and not affect any other fields, write the
value 0100000000000000B to the register. After a card reset all implemented fields in this register are
reset, except for the DEVSEL# Timing and Fast Back-to-Back Capable bit fields which are read-only.

15 14 13 12 11 10 9 8 7 6 5 4 0
Reserved
Extended Capabilites Support

Fast Back-to-Back Capable
Data Parity Dectecte
CDEVSEL# Timing
00 - fast
01 - medium
10 - slow
Signaled Target Abort

Received Target Abort
Received Master Abort
Received System Error
Detected Parity Error
Figure 5-38: STATUS Register Layout
Table 5Ð18 STATUS Register Field Definition

0-3 Reserved
4 Extended Capabilites If set, indicates this device supports the PCI Extended Capabilities feature and the
Support Capabilities Pointer at offset 34h should be used to locate the offset to the first data
structure. See the PCI Bus Power Management Specification for CardBus
Cards section for further definition of extended capability.
5-6 Reserved
7 Fast Back-to-Back This read-only field indicates whether or not the target is capable of accepting fast
Capable back-to-back transactions when the transactions are not to the same agent. If reset,
the function cannot accept these transactions. If set, the function can accept these
transactions.
8 Data Parity Detected This field is only implemented by bus masters. If set, then three conditions must have
been met: (1) the bus agent asserted CPERR# itself or observed CPERR# asserted;
(2) the agent setting the bit field acted as the bus master for the operation in which the
error occurred; (3) the Parity Error Response bit field (Command Register) is set.
9-10 CDEVSEL# Timing This field encodes the timing of CDEVSEL#. The three allowable timings are encoded
as 00b for fast, 01b for medium, and 10b for slow (11b is reserved). This field is read-
only and must indicate the slowest time in which a card asserts CDEVSEL# for any
bus command except Configuration Read and Configuration Write.
11 Signaled Target Abort This field must be set by a target whenever it terminates a transaction with target-
abort. Functions that will never signal target-abort do not need to implement this field.
12 Received Target Abort This field must be set by a master whenever its transaction is terminated with target-
abort. All masters must implement this field.
13 Received Master Abort This field must be set by a master whenever its transaction, except for Special
Cycles, is terminated with master-abort. All masters must implement this field.
14 Signaled System Error This field must be set whenever the function asserts CSERR#.
15 Detected Parity Error This field must be set by the function whenever it detects a parity error, even if parity
error handling is disabled.

5.4.2.1.3 Cache Line size

This register specifies the system cache line size in units of 32-bit words. This register must be
implemented by masters that can generate the Memory Write and Invalidate command. Functions
participating in the caching protocol use this register to know how to disconnect burst accesses at
cache line boundaries. The default value of this register when the card is reset, is 0. This register is
set by Card Services to inform the card what size is supported by the system. A size of 0 generally
indicates that the memory spaces of this function is not cacheable, i.e. software must guarantee
coherency if it is cached. Since this register indicates the level of system support, all cacheable
functions on a card will have the same value for Cache Line Size, which is defined by the system.
5.4.2.1.4 Latency Timer

This register specifies, in units of bus clocks, the value of the Latency Timer for this bus master. This
register must be implemented as writable by any master that can burst more than two data phases.
This register may be implemented as read-only for cards that burst two or fewer data phases, but
the hardwired value must be limited to 16 or less. A typical implementation would be to build the
five high-order bits (leaving the bottom three as read-only), resulting in a timer granularity of eight
clocks. The default value of the non-read-only fields of this register when the card is reset is 0.
5.4.2.1.5 Header Type

This register identifies the layout of bytes 10H through 3FH in configuration space and also whether
or not the card contains multiple functions. Bit 7 in this register is used to identify a multi-function
card. If reset, then the card has a single function. If set, Bit 7 indicates that the card has multiple
functions. Bits 6 through 0 specify the layout of bytes 10H through 3FH. One encoding, 00H, is
defined and specifies the layout of the pre-defined header space shown in Figure 5-36. This header
layout allows compatible information to be stored for both CardBus PC Card configuration spaces
and those used by other environments. The remaining encodings (1-127) are reserved for future
use.
Each function on the card has a configuration space including the pre-defined header. Every card
must contain function 0.
5.4.2.1.6 Built-in Self Test (BIST)

This optional register is used for control and status of BIST. Functions that do not support BIST must
always return a value of 0 (i.e., treat it as a reserved register). A function whose BIST is invoked
should not prevent normal operation of the bus. Figure 5-39 shows the layout for the BIST register.
Table 5Ð19 defines the BIST register fields.
7 6 5 4 3 0
Completion Code
Reserved
Start BIST
BIST Capable
Figure 5-39 BIST Register

Table 5Ð19 BIST Register Fields

7 BIST Capable If reset, function is not BIST capable. If set, function supports BIST.
6 Start BIST If reset, BIST is complete. If set, invoke BIST. Test fails if BIST is not complete after 2
seconds.
5-4 Reserved. Only reset is supported.
3-0 Completion Code A value of 0 means the function has passed its test. Non-zero values mean the test
failed. Function-specific failure codes can be encoded in the non-zero value.
5.4.2.1.7 Base Address Register

These registers provide the beginning Host System address for mapping CardBus PC Card memory
and I/O spaces into the Host System. Such mappings use Base Address Register windows. There
are a maximum of six Base Address Registers per configuration space. A Base Address Register
may refer to either a memory or an I/O mapping. Since it is not required that all CardBus PC Card
host systems implement a separate I/O space, any I/O space on a CardBus PC Card must be able to
be mapped into the host system memory address space, i.e., memory-mapped I/O.
A Base Address Register that contains a zero value, in bits (31:4), is in a disabled state. No access
shall be accepted by a card for a Base Address Register with bits (31:4) set to zero. All base address
registers must be have bits (31:4) set to zero by assertion of CRST#.
CardBus PC Card does not require that any Base Address Registers be implemented in a CardBus
PC Card function. However, the only way to access memory or I/O space on a CardBus PC Card
from a host system is via the Base Address Registers. The layout for a Base Address Register
referring to a memory mapping is given in Figure 5-40.
31 4 3 2 1 0
Base Address 0
Prefetchable
Type
Memory Space Indicator
Figure 5-40 Base Address Register Mapping for Memory Space
The Prefetchable field is set by the card if the following are all true:
• There are no side effects on reads.
• The function returns all bytes on reads regardless of the byte enables.
• Host bridges can merge processor writes into this range without causing errors.
The field must be reset otherwise. Any function that has memory which behaves like normal
memory, but will not be participating in CardBus PC Card's caching protocol, should mark the
range as prefetchable. A linear frame buffer in a graphics device is an example of a range which
should be marked prefetchable.
The Type field indicates valid placements in memory space for the mapping. The values are
defined as below in Table 5Ð20.

Table 5Ð20 Meaning of the Type Fields for a Memory Base Address Register
Bits 2/1 Meaning
00 Base Address Register is 32 bits wide and mapping can be done anywhere in the 32-bit memory space.
01 Base Address Register is 32 bits wide but must be mapped below 1M (Real Mode mapping) in memory
space.
10 Allocated.
11 Reserved
Bits 0-3 of a memory Base Address Register are read only. This results in 16 byte alignment for
CardBus PC Card base memory addresses. The number of upper bits that a function's configuration
space actually implements in this Base Address Register depends on how much of the address space
to which the memory associated with that Base Address Register will respond. In other words, the
number of upper bits implemented indicates directly the size of the mapping required and leads to
a power-of-2 sizing and alignment for the mapping.
The layout for a Base Address Register referring to an I/O mapping is given in Figure 5-41.
31 2 1 0
Base Address 0 1
Reserved
I/O Space Indicator
Figure 5-41 Base Address Register Mapping for I/O Space
Bits 0-1 of an I/O Base Address Register are read only. This results in 4 byte alignment for CardBus
PC Card I/O addresses. The function may in fact decode all 32 bits of a presented address, which
allows a one (1) byte granularity to be supported without waiting the extra cycle for a byte enable.
(See also 5.2.2.2 Addressing.) The number of upper bits that a function's configuration space actually
implements in this Base Address Register depends on how much of the I/O space to which this
function will respond. In other words, the number of upper bits implemented indicates directly the
size of the mapping required and leads to a power-of-2 sizing and alignment for the mapping.
All CardBus PC Cards implementing I/O spaces must to be able to be memory-mapped as well as
mapped via I/O Base Address Registers. Therefore, for those cards implementing an I/O space
there will be, as well as any I/O Base Address Registers mapping that space(s), at least 1 memory
Base Address Register to also map the space. The memory Base Address Register associated with
the I/O space(s) immediately follows the I/O space(s)'s I/O Base Address Register(s) in
configuration space.
There are six DWORD locations allocated for Base Address Registers, with the first starting at offset
10H.
5.4.2.1.8 CIS Pointer

This read-only register points to where the CIS begins, in one of the following spaces:
• configuration space Ñ must begin in device-dependent space at or after location 40H.
• memory space Ñ may be in any of the memory spaces.
• Expansion ROM space Ñ may be in any of the images.

Each configuration space of a multi-function card must have its own CIS, pointed to by the CIS
Pointer in its configuration space. The encoding for this pointer is given below in Figure 5-42.
31 28 27 3 2 1 0
Address Space Offset
ROM Image Address Space Indicator

Figure 5-42 CIS POINTER Layout
The Address Space Indicator field indicates in which of this function's address spaces the CIS begins.
The encoding for this field is given below in Table 5Ð21.
Table 5Ð21 Address Space Indicator Values

Value Meaning
0 CIS begins in device-dependent configuration space.
1-6 The CIS begins in the memory address space governed by one of the six Base Address Registers. For example,
if the value is 2, then the CIS begins in the memory address space governed by Base Address Register 2.
7 The CIS begins in the Expansion ROM space.
The value of the Address Space Offset gives the offset, into the address space indicated by the
Address Space Indicator field, at which the CIS begins. (See Table 5Ð22 Address Space Offset
Values.)
Table 5Ð22 Address Space Offset Values

Address Space Indicator Space Type Address Space Offset Values
0 configuration space 40H ≤ value ≤ F8H. The address in device-dependent
configuration space at which the CIS starts.
x; 1 ≤ x ≤ 6 memory space 0 ≤ value ≤ FFFF FFF8H. This is the offset into the memory
address space governed by Base Address Register x.
Adding this value to the value in the Base Address Register
gives the location of the start of the CIS.
7 expansion ROM 0 ≤ image ≤ FH, 0 ≤ value ≤ 0FFF FFF8H. This is the offset
into the expansion ROM address space governed by the
Expansion ROM Base Register. The image number is in
the uppermost nibble of the Address Space Offset. The
value consists of the remaining bytes.
The image is the image number used as the location
reference for the start of the CIS. The value is the offset of
the start of the CIS from the base of that image. Adding this
offset plus the starting offset of the image to the value in the
Expansion ROM Base Register gives the location of the
start of the CIS.
Note that the above definition ensures that no properly implemented CIS Pointer register will ever
have the value 0. It is required that each function in a multi-function CardBus PC Card have this
register implemented and that the pointer indicates the location of a valid CIS. (See 5.5.3.2 Required
CIS.)

5.4.2.1.9 Expansion ROM Base Address Register

The 4-byte register at offset 30H in configuration space is defined to handle the base address and
size information for an expansion ROM. Figure 5-43 shows how this register is organized. The
register functions exactly like a 32-bit Base Address Register except that the encoding and usage of
the lower bits is different. The number of bits, out of the upper 21 bits, that a function's
configuration space actually implements depends on what address alignment the function supports.
Functions that support an expansion ROM must implement this register.
31 11 10 1 0
Expansion ROM Base Address Reserved
Address Decode Enable

Figure 5-43 Expansion ROM Base Address Register Layout
The field at location 0 in the register is used to control whether or not the function accepts accesses to
its expansion ROM. When set, this field indicates that address decoding is enabled using the
parameters in the other part of the register. This allows a function to be used with or without an
expansion ROM depending on system configuration. When reset, the function's expansion ROM
address space is disabled. The Memory Space field in the Command register has precedence over
the Expansion ROM Enable field. A function will only respond to accesses to its expansion ROM if
both the Memory Space field and the Expansion ROM Base Address Enable field are set.
Since the Expansion ROM Base Address Register controls all accesses to the Expansion ROM, a
CardBus PC Card device must also respond to a write access to the Expansion ROM, even if the
Expansion ROM is a read-only device. A CardBus PC Card device responds to such write accesses as
if it was a successful transaction (CDEVSEL# and CTRDY# asserted, with CSTOP# negated). The
write data should be ignored and should not affect the operation of the CardBus PC Card
device.(See also 5.4.2.4 Expansion ROM.)
An Expansion ROM Base Address Register that contains a zero value, in bits (31:11), is in a disabled
state. No access shall be accepted by a card for the Expansion ROM Base Address Register with bits
(31:4) set to zero. The Expansion ROM Base Address Registers must be have bits (31:11) set to zero
by assertion of CRST#.
5.4.2.1.10 Cap_Ptr
The 8-bit Capabilities Pointer at location 34h is used to point to the beginning of the first PCI
defined Extended Capabilities data structure. It represents an offset from the beginning of the PCI
Configuration Space into the Configuration Space where the first data structure will be found.
If the PCI Extended Capabilities feature is not implemented, this value is 0.
See the PCI Bus Power Management Specification for CardBus Cards section for further definition
of extended capability.
5.4.2.1.11 Interrupt Pin

The Interrupt Pin register tells whether or not the function uses the interrupt pin. Functions which
do use the interrupt pin must set this register. Functions which don't use the interrupt pin must
reset this register. This register is read-only. Note that when multiple functions exist on a CardBus

PC Card and more than one uses the interrupt pin and these functions are concurrently enabled, the
functions share the interrupt pin.
5.4.2.1.12 Tuple Space

The device-dependent configuration space of a CardBus PC Card may contain a tuple chain. This
tuple chain may start anywhere on or after 40H in configuration space and must be contiguous until
a CISTPL_END is reached. This tuple chain may contain a LongLink tuple to another tuple chain in
another space associated with that function. Tuple space must begin with a CISTPL_LINKTARGET
tuple. (See the Metaformat Specification.)
5.4.2.1.13 Register Summary

All of the registers defined above may be accessed by CardBus PC Card system software.
Additionally, for some of the registers, the CardBus PC Card system software will provide the client
with an access API. (See the Card Services Specification.) Table 5Ð23 below gives a summary of the
usage characteristics of the configuration space registers. The columns in Table 5Ð23 have the
following meanings:
Register the name of the register in CardBus PC Card configuration space.
Field if applicable, the separately accessible field in the register.
Mandatory YES - the register or field is required.
NO - the register or field is optional, based on the function.
Function Unique YES - within a multi-function card, each function could give this register or field a different value.
NO - it is required that this register or field be given the same value by all functions on the card. In
fact, it would be possible to alias all of the occurrences of this register or field in all of the functions to
the same physical register.
Interface Control YES - this register or field either gives information about or controls the card to system interface.
NO - this register or field does not give information about or control the card to system interface.
System Software YES - CardBus PC Card system software is expected to read from or write to this register or field.
(Read/Write) NO - CardBus PC Card system software is not expected to read from or write to this register or
field.
Client Software YES - the function's client software is allowed to read from or write to this register or field. (See the
(Read/Write) Card Services Specification.)
NO - the function's client software does not access this register or field. The knowledge provided by
this register or field may be available to the client via the Card Services interface. However, the
client does not directly read from this register or field.

Table 5Ð23 Configuration Space Register Usage Summary

Register Mandatory Function Interface System Software Client Software
Field Unique Control Read Write Read Write
Command YES
I/O Space YES YES YES YES YES NO NO
Memory Space YES YES YES YES YES NO NO
Bus Master YES YES YES YES YES YES YES
Special Cycles YES YES YES YES YES NO NO
Memory Write and YES YES YES YES YES YES YES
Invalidate Enable
VGA Palette Snoop NO YES YES YES YES YES YES
Parity Error Response YES YES YES YES YES NO NO
Wait Cycle Control YES NO YES YES YES NO NO
SERR# Enable YES YES YES YES YES NO NO
Fast Back-to-Back YES NO YES YES YES NO NO
Enable
Status YES
Extended Capability NO YES NO YES NO YES NO
Support
Fast Back-to-Back YES NO YES YES YES NO NO

Enable
Data Parity Detected NO YES YES YES YES NO NO
DEVSEL# Timing YES NO YES YES NO NO NO
Signaled Target Abort NO YES YES YES YES NO NO
Received Target Abort NO YES YES YES YES NO NO
Received Master Abort NO YES YES YES YES NO NO
Signaled System Error NO YES YES YES YES NO NO
Detected Parity Error YES YES YES YES YES NO NO
Cache Line Size YES NO YES YES YES NO NO
Latency Timer YES NO YES YES YES NO NO
Header Type YES NO NO YES NO NO NO
BIST NO YES NO NO NO YES YES
Base Address Register NO YES YES YES YES YES NO
Expansion ROM Base NO YES YES YES YES YES NO
Register
Interrupt Pin YES YES YES YES NO NO NO
CIS Pointer YES YES NO YES NO YES NO
5.4.2.2 Memory Space

While there is no Attribute Memory, as defined for 16-bit PC Cards, on CardBus PC Cards, CardBus
PC Cards' memory space(es) could be viewed as 16-bit PC Card-like Common Memory. Each
CardBus PC Card memory device is mapped into host system address space via one of the six Base
Address Registers in configuration space.
Because CardBus PC Card sockets support 16-bit PC Cards, the CardBus PC Card programming
model must support 16-bit PC Card memory mapping mechanisms as well as the Base Address
Register mappings used for CardBus PC Cards. This includes the 16-bit PC Card window mapping

where a window of a given size is requested between a card offset address and a host system base
address.
Whether the memory space is mapped into host system address space via a 16-bit PC Card-like
mapping from a 16-bit PC Card or a Base Address Register mapping from a CardBus PC Card, it is
important that the card software manage the mapping. (See the Card Services Specification.)
Tuple chains may appear anywhere in memory space. Any tuple chains in memory space, unlike
those in configuration space, may be mapped directly into the host system address space and
accessed by the client, although the Card Services tuple parsing routines are still the preferred
access mechanism partly because those tuple chains in CardBus PC Card configuration space cannot
be directly mapped into the host system address space.
5.4.2.3 I/O Space

When used in CardBus PC Card systems which implement a separate host system I/O space, cards
are assigned I/O addresses. (See the Card Services Specification.)
5.4.2.4 Expansion ROM

An expansion ROM may be mapped into the host system address space via the Expansion ROM
Base Address Register in the configuration space. The ROM consists of one or more images, each of
which may apply to different system and processor architectures. Each image must start on a 512-
byte boundary and must contain the CardBus PC Card expansion ROM header. The starting point
of each image within the expansion ROM depends on the size of previous images. The last image in
a ROM has a special encoding in the header to identify it as the last image.
If an expansion ROM is present, as indicated by the Expansion ROM Base Address Register, then
there may be tuple chains in any of the images.
At the beginning of each expansion ROM image is an expansion ROM header, as described in
Table 5Ð24, below. All of the registers in the expansion ROM Image Header and in the CardBus PC
Card Data Structure, unless otherwise stated, are required to be present, with legal values.
Table 5Ð24 Expansion ROM Image Header

Offset Length Value Description
0H 1 55H ROM Signature, byte 1
1H 1 AAH ROM Signature, byte 2
2H-17H 16 variable Reserved (processor architecture unique
data)
18H-19H 2 variable Pointer to CardBus PC Card Data Structure
(defined in Table 5Ð25). This pointer must
have a value of at least 20H, in order not to
conflict with the placement of the image
header.
ROM Signature - this is a two-byte field containing 55H in the first byte and AAH in the second
byte. This signature must be the first two bytes of the ROM address space for each image of the
ROM.
Pointer to CardBus PC Card Data Structure - this is a two-byte pointer in little endian format which
points to the CardBus PC Card Data Structure. The reference point for this pointer is the beginning
of the ROM image.

The CardBus PC Card Data Structure must be located within the first 64 KBytes of the ROM image
and must be DWORD aligned. The CardBus PC Card Data Structure contains the information
summarized in Table 5Ð25. Details of each field are given after the figure. "Reserved" in the
diagram below indicates that the register is reserved for future use. "Allocated" indicates that the
register is not defined for CardBus PC Card and must not be redefined as other environments may
use the register. The purpose of the "Allocated" registers is to maintain compatibility between
CardBus PC Card and other environments. CardBus PC Card system software will not make use of
any of the information which may be stored in these fields.
Table 5Ð25 CardBus PC Card Data Structure Fields

Offset Length Description
0H 4 Signature, the string "PCIR"
4H 4 Allocated
8H 2 Pointer to Vital Product Data
AH 2 CardBus PC Card Data Structure Length
CH 1 CardBus PC Card Data Structure Revision
DH 3 Allocated
10H 2 Image Length
12H 2 Revision Level of Code/Data
14H 1 Code Type
15H 1 Indicator
16H 2 Reserved
Signature - these four bytes provide a unique signature for the CardBus PC Card Data Structure.
The string "PCIR" is the signature with "P" being at offset 0, "C" at offset 1, etc.
Pointer to Vital Product Data - the Pointer to Vital Product Data (VPD) is a 16-bit field which is the
offset from the start of the ROM image and points to the VPD. This field is in little-endian format.
The VPD must be within the first 64 KBytes of the ROM image. A value of 0 indicates that no VPD
is in the ROM image. The content of the VPD structure is not currently defined.
CardBus PC Card Data Structure Length - this is a 16-bit field which defines the length of the data
structure from the start of the data structure (the first byte of the Signature field). This field is in
little-endian format and is in units of bytes.
CardBus PC Card Data Structure Revision - this is an 8-bit field which identifies the data structure
revision level. This revision level is 0.
Image Length - this is a two-byte field which represents the length of the image. This field is in
little-endian format and gives the value in units of 512 bytes.
Revision Level - this is a two-byte field which contains the revision level of the code in the ROM
image.
Code Type - this is a 1-byte field which identifies the type of code contained in this section of the
ROM. The code may be executable binary for a specific processor and system architecture or
interpretive code. Table 5Ð26 describes the available Code Types.

Table 5Ð26 Code Type Descriptions

Type Description
0 Intel Architecture, PC-AT compatible
1 Open Firmware Standard23
2-FFH Reserved
Indicator - bit 7 in this field tells whether or not this is the last image in the ROM. If reset, another
image follows. If set, this is the last image. Bits 0-6 are reserved.
5.5 Requirements For CardBus PC Cards and Sockets
5.5.1 Overview
This chapter describes the minimum hardware and software interfaces that PC Card and system
designers can rely on for basic compatibility across PC Cards, systems, and related software. These
interfaces ensure that the CardBus PC Card can meet the PCMCIA/JEIDA goal of PC Card
interoperability.
5.5.2 Software Requirements

CardBus PC Card allows PC Cards and sockets to be accessed by multiple PC Card-aware device
drivers, configuration utilities, and applications with efficient and non-conflicting use of system
resources. The primary components of the software interface are Socket Services and Card Services.
Socket Services provides the lowest-level function set for socket hardware adapter control. Card
Services allocates resources and coordinates PC Card-related activities for higher-level clients. Both
components can be developed as a single module as long as all functions described are available.
5.5.2.1 Socket Services

Socket Services functionality must be provided. It is the lowest level software layer, providing only
socket-control functions and low-level PC Card functions accessible through control of CardBus PC
Card sockets. The services provide hardware-independent control functions that are used to
manipulate implementation-dependent hardware. This isolates higher-level software from most
hardware implementation dependencies allowing different socket implementations to be supported
by a common client. Socket Services is the only interface defined and supported by the PC Card
Standard.
Once Card Services is loaded, Card Services has exclusive use of Socket Services. After Card
Services is initialized, any software using Socket Services will receive an error status when accessing
Socket Services functions directly. This allows the CardBus PC Card-compatible software to operate
without conflicts and gain control of host system resources. (See also the Socket Services
Specification.)
23 Open Firmware is a processor architecture and system architecture independent standard for dealing with device
specific option ROM code. Documentation for Open Firmware is available in the IEEE P1275-1994 Standard for
Boot (Initialization, Configuration) Firmware Core Requirements and Practices.

5.5.2.2 Card Services

Card Services is the only required software interface for managing CardBus PC Cards in CardBus
PC Card-compliant systems. It provides the capability of client registration for card event call backs
and meets the minimal requirements for manipulating CardBus PC Card-compliant host system
interfaces. The Card ServicesÕ specification explicitly defines a guaranteed minimum set of card
control functions on which higher-level software and associated PC Cards can rely. Most of the Card
Services functions are used by clients only for installation and configuration.
It is important to recognize that more than one type of adapter can be present in any given system.
One adapter could be part of the motherboard and another adapter could be plugged into a system
expansion slot. In this case, there will typically be several implementations of Socket Services, one
implementation to control each adapter type. However, even if there is more than one Socket
Services handler, there can be only one Card Services implementation present in a system. Card
Services is the central coordinator for clients to acquire system and socket resources (e.g., mapping
windows, system mappable address space, etc.). The hardware notification of PC Card insertion and
status change events from all adapters goes to a single Card Services handler. (See also the Card
Services Specification.)
5.5.2.3 System Resource Availability

Multiple CardBus PC Card-aware device drivers, utilities, and applications share system resources
in providing for PC Card access. Therefore, CardBus PC Card compliance cannot guarantee that any
given client of Card Services will always be granted a requested resource. If Card Services is unable
to provide resources to a client due to resource availability limitations, it returns a failure indication.
In this case, the client can try to operate with different or fewer resources or may simply report that
it is unable to provide its function.
5.5.2.4 System Resource Determination

Each implementation of Card Services must have some implementation-dependent way to
determine the system hardware resources (e.g., memory address space, I/O address space,
interrupts) present in a given system. Card Services must know what system I/O and memory
address space is usable by the adapter hardware, what system I/O and memory address space is
unused, what interrupts can be steered by the adapter hardware, and what interrupts are unused.
Note that automated processes to determine system resource availability are usually not 100%
accurate. Also the system configuration could change rendering a pre-initialized table obsolete. As a
result, there must be the ability for later adjustment of the Card Services resource table.
Therefore, CardBus PC Card-compliant systems must provide the following:
an automated method of initializing Card or a Card Services that is preinitialized with the
Services with the available resources (those not available resources
preassigned)
and
a method of later modifying the Card Services set of available resources based on the changing configuration of
non-PC Card components in the host system.24
24Thismethod does not have to be supported if an automated process can guarantee 100% accuracy in dynamically
determining system resource availability and it is used to initialize Card Services whenever resources change.

5.5.2.5 Enabler Support

The purpose of an enabler is to allow a single piece of software to configure and unconfigure a PC
Card to prevent the redundancy of every PC Card requiring separate and unique configuration
software.
Enablers recognize PC Cards in one of two ways. First, they may recognize a card specifically from
information in the Card Information Structure (CIS) that is unique to that card. For example, some
enablers use combinations of the manufacturer string and product string from the VERS_1 tuple and
the Manufactuer ID and Function ID tuples. Second, enablers may recognize a PC Card solely from
its Function ID tuple. For most Data/FAX modems, a Function ID that indicates the PC Card has a
serial interface causes the card to be configured as the next available COM port.
Once a card is configured, it may be used by software that is or is not aware that the functionality is
located on a PC Card. If the software is PC Card-aware, it may piggy-back on the efforts of the
enabler and use the card's functionality until the card is removed and the enabler releases the
system resources used by the card.
If the software is not PC Card-aware, it must locate the card's resources where the enabler mapped
them into the host system's address space. For most cards this means assuming the PC Card is
placed at the same locations typically used by standard ISA peripherals that perform the same
functions.
Some cards offer functionality that use configuration files to describe where they are located in
system memory address space. As an example, network adapters have a NET.CFG or
PROTOCOL.INI file describing the IRQ level, I/O address range and memory range used to
address the adapter. In this case, the enabler must place the PC Card's resources as indicated in the
configuration file.
It is recommended that CardBus PC Card software implementations provide for the support of
enablers. (See also Guidelines.)
5.5.3 Card Requirements

In order for a socket to reliably recognize a PC Card and configure it, all CardBus PC Cards must
meet certain minimum functionality requirements. This section outlines this minimum functionality
for CardBus PC Cards.
5.5.3.1 Configuration Space

All CardBus PC Cards are required to implement configuration space for each function (see the
CardBus PC Card Programming Model section of this specification). All other spaces, memory, I/O,
and expansion ROM, are optional.
Common silicon (CardBus PC Card interface components designed for use on both PC cards and
PCI) must implement configuration space as outlined in the "CardBus PC Card/PCI Common Silicon
Requirements" guideline. This document specifies how to construct configuration space such that it is
usable both by CardBus PC Card and PCI in addition to documenting electrical and protocol
considerations.
5.5.3.2 Required CIS

CardBus PC Cards must implement a minimum set of tuples per function. (See the Metaformat
Specification.)

5.5.3.3 Required Signals

All CardBus PC Cards must implement the following signals:
Address and Data: CAD[31::0]
CCBE[3::0]#
CPAR
Interface Control: CFRAME#
CTRDY#
CIRDY#
CSTOP#
CDEVSEL#
Error Reporting: CPERR#
CSERR#
System: CCLK
CRST#
Card and Voltage Detect: CCD[2::1]#
CVS[2::1]
Power and Ground: GND (four pins)
VCC (two pins)
CardBus PC Cards with bus master capability must also implement:

Arbitration: CREQ#
CGNT#
CCLKRUN#
The following signals are optional:

CINT# for CardBus PC Cards requiring interrupt services
CSTSCHG for CardBus PC Cards which generate status changed events or remote wakeup
CBLOCK# for CardBus PC Cards containing shared memory (See 5.2.6.5 Supporting CBLOCK# and Write-
back Cache Coherency.)
CAUDIO for CardBus PC Cards using the system's speaker
VPP1, VPP2 for CardBus PC Cards requiring this additional supply
The remote wakeup capability is optional even for CardBus PC Cards which implement the
CSTSCHG pin. All connector pins associated with signals which aren't implemented must be no-
connects on the PC Card.
5.5.3.4 Pull-up/Pull-down Resistors

When a PC Card is removed from the socket, there will be periods when the connector contacts
bounce causing signals on the interface to glitch. During these times, the interface signals will float,
possibly leading to false initiation or detection of cycles by the CardBus PC Card.
Therefore, CGNT# (for bus masters) and CFRAME# (on all cards) must be pulled-up to VCC on the
CardBus PC Card using the resistor values specified in 5.3.3.3.1 Pull-up Values for Control Signals.
The CGNT# resistor ensures the CardBus PC Card never initiates a cycle. The CFRAME# resistor
ensures that it never falsely detects a cycle.
5.5.3.5 CSTSCHG Support

CSTSCHG can be generated from a number of different sources, e.g., WP, BVD[2::1], READY, or
remote wakeup. CardBus PC Cards do not have to implement all of the fields in the associated

registers, just those which apply to the particular function. For example, LAN functions typically
won't implement the write-protect switch but memory cards would.
There are additional requirements on CSTSCHG support when implementing PCI Bus Power
Management for CardBus. Refer to the PCI Bus Power Management for CardBus Cards section for
CardBus card specifics and the PC Card Host System Specification for additional details.
5.5.3.6 Power Consumption

The maximum power allowed for any CardBus PC Card is a function of the maximum current that
can be supplied by the VCC pins.
It is anticipated that some systems either cannot or will not provide the full power budget. For this
reason, CardBus PC Cards must not consume more than Icc(CIS) (see 5.3.2.1.1 DC Specifications)
when reading the CIS and for configuration space reads and writes after power-up or reset. All other
functions can be suspended, if necessary. This power saving state can be achieved in a variety of
ways. For example:
• Circuitry on the PC Card can be disabled on power-up or reset until re-enabled via an access to
• Clock rates on the CardBus PC Card can be reduced, which reduces performance but does not
limit functionality.
• Power planes to non-critical parts could be shut off with a FET, which could limit functional
capability.
Any CardBus PC Card which requires more than Icc(CIS) during normal operation must report this,
along with the maximum current it requires, in the CIS. This is done using a power description
structure. (See the Metaformat Specification.)
5.5.3.7 I/O Space Support

Any addresses on a CardBus PC Card that can be mapped into I/O space must also be mappable
into memory space. This means that CardBus PC Cards which utilize I/O space must also
implement a memory base address register(s) to facilitate memory-mapped I/O. It is the system's
responsibility to configure the appropriate base address register. Refer to the Configuration Space
section of this specification for details on where I/O and memory-mapped I/O base address
registers must be placed.
5.5.4 Socket Requirements

This section outlines the minimum functionality that must exist in a CardBus PC Card socket. This
functionality may be integrated in the socket adapter silicon but is not required to be.
5.5.4.1 16-bit PC Card Support

All CardBus PC Card adapters must provide support for 16-bit PC Cards. Refer to 5.5.4.6 Card
Insertion and Removal and the following sections for how the adapter must deal with configuring
the interface to utilize the correct protocol. The CardBus PC Card interface does not impose any
additional constraints on adapters than is already implied by the 16-bit PC Card specification. For
example, CardBus PC Card adapters implemented in 3.3 V-only systems are not required to support
5 V 16-bit PC Cards.

5.5.4.2 Address Spaces

The CardBus PC Card interface supports three basic address spaces: memory, I/O, and
configuration. Configuration space is accessed using an address independent mechanism which
treats each function's configuration space as being unique. Therefore, configuration space does not
have to be mapped into the system address space. As a result, the socket adapter only needs to be
concerned with mapping memory and I/O spaces.
Implementations, including systems with hierarchical bus topologies, must ensure that Card
Services can correctly map CardBus PC Card adapters and cards into the system address space.
These implementations must also accommodate the dynamic insertion/removal characteristics
fundamental to PC Cards. The solution to these issues is system dependent and outside the scope of
this document.
5.5.4.2.1 Memory Space

A CardBus PC Card's memory space is classified as either:
cacheable which uses hardware mechanisms to guarantee coherency. The availability and capability of this hardware
mechanism is a function of the system architecture. This may impact the performance of card-to-card transfers
since addresses must be presented to the snooping agents before letting the transaction proceed.
prefetchable which is not being cached but doesn't exhibit side effects when read.
non-cacheable which is generally not cacheable (i.e. software must guarantee coherency if it is). If this memory exhibits side
effects when read, it may not be prefetchable or cacheable under any circumstances. It has the same
characteristics as memory mapped I/O space.
The CardBus PC Card adapter must provide a means to decode accesses from the system intended
for its PC Card interfaces and those from CardBus PC Cards intended for the system. In many cases,
system bus constraints will dictate that the adapter function as a system bus-to-CardBus PC Card
bridge. In these cases, the adapter must provide a base address register and limit address register
for each supported space (cacheable, prefetchable, and non-cacheable).
All CardBus PC Card adapters must provide support for prefetchable memory. In the bridged
implementation mentioned above, this means the adapter must provide each socket with a
minimum of two prefetchable base and limit register pairs for each socket supported. A mechanism
must also be provided to disable prefetching, on a per window basis, to allow support of non-
cacheable memory and/or memory mapped I/O. If that cacheable space is supported, the adapter
must provide additional base and limit register pairs for that space. These registers are also
required on a per socket basis.
Note: Each Base and Limit register pair may be reassignable from socket to socket, but may not be
shared across multiple sockets simultaneously.
The resources they point to must be mappable anywhere in the available system memory space.
The adapter must provide at least 32 KBytes of contiguous memory to each socket and also must be
able to map larger memory blocks into available system memory space. The top 20 bits of the
prefetchable base and limit registers correspond to address bits CAD[31::12] of a memory address.
For the purposes of address decoding the adapter assumes that address bits CAD[11::0] of the base
address are zero. Similarly, it assumes that address bits CAD[11::0] of the limit address are FFFH.
This forces a prefetchable address range to be aligned to a 4 KByte boundary and to have a size
granularity of 4 KBytes. The low four bits of the prefetchable memory base and limit registers are
required to be read only and must return a value of 0 to indicate only 32-bit addressing is
supported. The returned value of 01 is allocated and must not be used by CardBus PC Card
adapters.
Note that some system buses, particularly in hierarchical topologies, specify bridges which require
the assignment (i.e., the base address value) to be above 1 MB. Therefore, it is recommended that

CardBus PC Card follow the convention of placing memory in upper memory whenever the
CardBus PC Card adapter does not reside on the primary system bus.
The address spaces of a CardBus PC Card with multiple address spaces may be interleaved with
another CardBus PC Card's spaces only if all the affected cards reside on the same adapter and the
adapter provides a mechanism to allow this. Since the CardBus PC Card interface requires each
address to have a unique destination, this mechanism must allow the mapping to be done such that
the spaces do not overlap.
5.5.4.2.2 I/O Support

All CardBus PC Card adapters must support either memory-mapped I/O or both memory-mapped
I/O and I/O space. The selection will depend largely on the system architecture the adapter is
intended to be used in. The requirement to also support memory-mapped I/O, if I/O space is
supported, is driven by the potential emergence of memory-mapped I/O only cards. Supporting
both modes may also position the adapter to be sold into multiple system architectures.
5.5.4.2.2.1 CardBus PC Card with Memory Mapped I/O

The adapter must provide at least 4 KBytes of contiguous memory for each socket and must be able
to map larger memory blocks into available system memory space. The top 20 bits of the base and
limit registers correspond to address bits CAD[31::12] of a memory address. For the purposes of
address decoding the adapter assumes that address bits CAD[11::0] of the base address are zero.
Similarly, it assumes that address bits CAD[11::0] of the limit address are FFFH. This forces a
memory mapped I/O address range to be aligned to a 4 KByte boundary and to have a size
granularity of 4 KBytes. The low four bits of the memory-mapped I/O base and limit registers are
required to be read only and return zero when read.
Note that some system buses, particularly in hierarchical topologies, specify bridges which require
the assignment (i.e., the base address value) to be above 1 MB. Therefore, it is recommended that
CardBus PC Card follow the convention of placing memory-mapped I/O in upper memory
whenever the CardBus PC Card adapter does not reside on the primary system bus.
5.5.4.2.2.2 CardBus PC Card with I/O Space

CardBus PC Card adapters which support I/O space must also provide each socket with a minimum
of:
• two I/O base address registers
• two I/O limit address registers
Each register must have 4 byte granularity and power-of-two alignment. The adapter must provide
at least 1 byte of I/O space for each socket. The lower two bits are read only and encode whether
the adapter supports 16 or 32 bit I/O addressing. If these bits have the value 0, then the adapter
supports only 16 bit addressing and assumes that the upper 16 address bits, CAD[31::16], of the I/O
base address register are zero. In this case, the I/O address range supported by the adapter will be
restricted to the first 64 KBytes of I/O address space.
If the lower two bits of the I/O base and I/O limit registers are 01, then the adapter supports 32-bit
I/O address decoding and the upper 16 bits of the base and limit registers hold the upper 16 bits,
corresponding to CAD[31::16], of the 32-bit I/O address space. When the I/O base and limit
registers indicate support for 32-bit I/O address decoding, the I/O address range may be anywhere
in the 4 GB CardBus PC Card I/O address range.

Note that some system buses, particularly in hierarchical topologies, specify bridges which decode
I/O addresses on 4 KByte boundaries. This means that Card Services must be aware of where each
CardBus PC Card function physically resides in the system so valid I/O assignments can be made.
5.5.4.2.2.3 ISA Support Implications

CardBus PC Card adapters in systems which support the ISA expansion bus must also support an
ISA mode which defaults to the disabled state whenever the adapter is reset. The system software
responsible for configuring this mode must enable it in systems with an ISA bus. This is a historical
artifact of ISA's 10-bit I/O addressing capability and the convention of using the two most significant
bits to indicate motherboard devices. Further, other system buses which support a 16-bit I/O
addressing mode decode the upper six bits for additional register selection. This created a situation
where the lower 256 bytes of every 1 KByte block were aliases of ISA addresses.
Therefore, when this mode is enabled, the adapter will only forward transactions downstream (from
the system bus to CardBus PC Card) when they are in the top 768 bytes of each naturally aligned 1
KByte address block. Conversely, I/O transactions on CardBus PC Card in the top 768 bytes of any
1 KByte block will be forwarded upstream (from CardBus PC Card to the system bus). This results
in I/O address decoding on the CardBus PC Card interface that is similar to EISA slot decoding.
Note that this mode only affects the I/O address decoding. It does not affect the adapter's
prefetching, posting, ordering, or error handling behavior.
5.5.4.3 Interrupt Handling and Routing
5.5.4.3.1 Functional Interrupts (CINT#)

A CardBus PC Card socket must have at least one system interrupt for routing PC Card functional
interrupts (CINT#). Since CardBus PC Cards must support sharable interrupts, hardware does not
have to provide a separate functional interrupt for each socket. Therefore, an implementation could
provide only a single functional interrupt, shared by all CardBus PC Card sockets, and still be
compliant although it would pay an interrupt latency penalty.
Any interrupt request lines which are available to the CardBus PC Card interface must be reported
to Card Services during its initialization. Note that there is a distinction between the ability to route
an interrupt and the availability of that interrupt. The system shall not report any interrupt, that
cannot be routed to, as being available.
5.5.4.3.2 Status Change Events

CardBus PC Card adapters must provide a second system interrupt for signaling Status Changed
events such as card insertion, removal, and CSTSCHG assertion. This interrupt routing must be
distinct from functional interrupts, i.e., Card Services must only receive Status Changed interrupts,
never functional ones.
The adapter must generate the Status Changed interrupt for at least each of the conditions listed
below:
• PC Card insertion event
• PC Card removal event
• CardBus PC Card asserted CSTSCHG
• PC Card power-up completed

Further, the adapter must make the following status information, associated with status change
events, available to Card Services:
• if a removal event caused a failed transaction or left data in the adapter's buffers
• if an inserted PC Card cannot be supported by the hardware
• what type of PC Card was inserted (16-bit PC Card vs. CardBus PC Card)
Note that a CardBus PC Card may assert CSTSCHG as a pulse to request remote wakeup when the
CardBus PC Card interface is powered down. If the system supports remote wakeup, the socket
must capture this event.
There are significant additional requirements for the adapter (PCI to CardBus Bridge) when
supporting PCI Bus Power Management for CardBus. See the PC Card Host System Specification
for additional information for adapter (PCI to CardBus Bridge) requirements.
5.5.4.4 Register Descriptions

CardBus PC Card adapters must contain a number of registers to manage status changed events,
remote wakeup events, PC Card insertion/removal, and status information about the PC Card in
the socket. The adapter must provide Event, Mask, Present State, Force, and Control registers for
each socket it supports. These registers and the fields that they contain are described in the
following sections. Note that space from the host system's address space must be allocated for these
registers.
5.5.4.4.1 Socket EVENT Register

The adapter uses the socket Event register to generate status changed interrupts. The fields in this
register indicate that a change in socket status has occurred. Card Services must read this register
and the socket Present State register to determine the cause of the interrupt. Card Services is
responsible for clearing the appropriate fields after determining why the status changed interrupt
occurred.
31 4 3 2 1 0
Reserved
Interface power cycle completed (PowerCycle)

CCD2# changed state (CCD2#)
CCD1# changed state (CCD1#)
CSTSCHG pin was asserted (CSTSCHG)
Figure 5-44 Socket EVENT Register

Table 5Ð27 Socket EVENT Register Fields

0 CSTSCHG This field is set (1) whenever the CSTSCHG field in the Present State register
changes state. It is cleared by writing it to 1. The state after the adapter has been reset
is 0.
Also, see PC Card Host System Specification for additional CSTSCHG
requirements when supporting PCI Bus Power Management for CardBus.
1 CCD1# This field is set (1) whenever the CCD1# field in the Present State register changes
state. It is cleared by writing it to 1. The state after the adapter has been reset is 0.
2 CCD2# This field is set (1) whenever the CCD2# field in the Present State register changes
state. It is cleared by writing it to 1. The state after the adapter has been reset is 0.
3 PowerCycle This field is set (1) by the adapter when it detects that the interface has finished
powering up or powering down. Note that the Present State register must be read to
see if it was successful. This field is cleared by writing it to 1. The state after the
adapter has been reset is 0.
5.5.4.4.2 Socket MASK Register

This register gives software the ability to control what events cause the status changed interrupt to
be generated. It inhibits the corresponding fields in the socket Event register from causing a status
changed interrupt.
Also, see the PC Card Host System Specification for additional CSTSCHG requirements when
supporting PCI Bus Power Management for CardBus.
31 4 3 2 1 0
Reserved
Interface Power Cycle Completed (PowerCycle)

Card insertion/removal (CardDetect)
CSTSCHG pin was asserted (CSTSCHG)
Figure 5-45 Socket MASK Register

Table 5Ð28 Socket MASK Register Fields

0 CSTSCHG When cleared (0), the assertion of CSTSCHG by the card will not cause a status
changed interrupt to occur although the CSTSCHG field in the Event register will be
set. It is set by writing it to 1. It must be cleared whenever the socketed PC card is
removed or when the adapter is reset.
Also, see the PC Card Host System Specification for additional CSTSCHG
requirements when supporting PCI Bus Power Management for CardBus.
1-2 CardDetect This field masks the CCD1# and CCD2# fields in the Event register so that insertion
and removal events will not cause a status changed interrupt to occur. Note that
the CCD1# and CCD2# fields in the Event register will still be set. The meaning
of the bits is:
00 Masks the CCD1# and CCD2# fields in the Event register. Insertion and removal
events will not cause a status changed interrupt. This is the default state after
the adapter is reset.
01 Undefined
10 Undefined
11 Unmasks the CCD1# and CCD2# fields in the Event register. Insertion and
removal events will cause a status changed interrupt.
3 PowerCycle When cleared (0), the status changed event signaling the power up process has
completed will not be generated although the PowerCycle field in the Event register
will be set. It is set by writing it to 1. The state after the adapter has been reset is 0.
5.5.4.4.3 Socket PRESENT STATE Register

This read-only register reflects the current state of the socket. Some of the fields are reflections of
interface signals while others are flags set to indicate conditions associated with a status changed
event. This register may be written using the Force event capability described in 5.5.4.4.4 FORCE
Event Capability.

31 30 29 28 27 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved
Socket can supply Y.Y V (YVsocket)

Socket can supply X.X V (XVsocket)
Socket can supply 3.3 V (3Vsocket)
Socket can supply 5.0 V (5Vsocket)
Card can accept Vcc=Y.Y V (YVcard)
Card can accept Vcc=X.X V (XVcard)
Card can accept Vcc=3.3 V (3Vcard)
Illegal Vcc value requested (BadVccReq)
Card removal caused data loss (DataLost)
Unrecognized card inserted (NotACard)
Reserved
CardBus PC Card inserted (CBcard)
16-bit PC Card inserted (16card)
Power applied successfully (PowerCycle)
State of CCD2# pin (CCD2#)
State of CSTSCHG pin (CSTSCHG)
Figure 5-46 Socket PRESENT STATE Register

Table 5Ð29 Socket PRESENT STATE Register Fields

0 CSTSCHG This field reflects the current state of the CSTSCHG pin on the interface. 1 indicates
CSTSCHG is asserted, 0 indicates it is negated.
1 CCD1# This field reflects the current state of the CCD1# pin on the interface. 1 indicates
CCD1# is High (card is not present), 0 indicates CCD1# is low (card is present).
Since the CCD1# pin could be shorted to either CVS1 or CVS2, the value stored here
is for when the CVS[2::1] pins are held low.
2 CCD2# This field reflects the current state of the CCD2# pin on the interface. 1 indicates
CCD2# is High (card is not present), 0 indicates CCD2# is low (card is present).
Since the CCD2# pin could be shorted to either CVS1 or CVS2, the value stored here
is for when the CVS[2::1] pins are held low.
3 PowerCycle When set (1), indicates that the interface is powered up, i.e. the power up process
was successful. When cleared (0), indicates that the interface is powered down, i.e.
the power up process was not successful. This field is updated by the adapter to
communicate the status of each power up/power down request.
4 16card When set (1), indicates that the card inserted was an 16-bit PC Card. This value does
not have to be updated until a non-16-bit PC Card (e.g. CardBus PC Card or
unrecognized card) is inserted. When set, the adapter must configure the socket
interface for 16-bit PC Card. Setting this field disables the adapter's voltage checking
hardware so extreme care must be taken when writing the Control register or the
hardware could be damaged.
5 CBcard When set (1), indicates that the card inserted was a CardBus PC Card. This value
does not have to be updated until a non-CardBus PC Card (e.g. 16-bit PC Card or
unrecognized) is inserted. When set, the adapter must configure the socket interface
for CardBus PC Card.
6 Reserved This field is reserved for future use.
7 NotACard When set (1), indicates that the type of card inserted could not be determined. This
value does not have to be updated until a recognizable card (e.g. 16-bit PC Card or
CardBus PC Card) is inserted.
8 DataLost When set (1), indicates that a PC card removal event may have caused data to be
lost either because a transaction was not completed properly or data was left in the
adapter's buffers. It must be cleared by Card Services when the removal event status
changed interrupt is serviced.
9 BadVccReq When set (1), indicates that software attempted to apply a VCC voltage to a socket that
was outside the range detected using the CVS[2::1] and CCD[2::1]# pins.
10 5VCard When set (1), indicates that the card inserted will function at VCC=5.0 V. When
cleared (0), indicates that the card will not function at VCC=5.0 V. This is determined
by interrogating the voltage sense and card detect pins. When a CardBus PC Card is
present, the adapter must not allow the socket to be powered up at VCC=5.0 V.
11 3VCard When set (1), indicates that the card inserted will function at VCC=3.3 V. When
cleared (0), indicates that the card will not function at VCC=3.3 V. This is determined
present, and this bit is cleared, the adapter must not allow the socket to be powered
up at VCC=3.3 V.
12 XVCard When set (1), indicates that the card inserted will function at VCC= X.X V. When
cleared (0), indicates that the card will not function at VCC= X.X V. This is determined
up at VCC= X.X V.
13 YVCard When set (1), indicates that the card inserted will function at VCC= Y.Y V. When
cleared (0), indicates that the card will not function at VCC= Y.Y V. This is determined
up at VCC= Y.Y V.
28 5Vsocket When set (1), indicates that the socket can supply VCC=5.0 V. When cleared (0),
indicates that the socket cannot supply VCC=5.0 V.
29 3Vsocket When set (1), indicates that the socket can supply VCC=3.3 V. When cleared (0),
indicates that the socket cannot supply VCC=3.3 V.

30 XVsocket When set (1), indicates that the socket can supply VCC= X.X V. When cleared (0),
indicates that the socket cannot supply VCC= X.X V.
31 YVsocket When set (1), indicates that the socket can supply VCC= Y.Y V. When cleared (0),
indicates that the socket cannot supply VCC= Y.Y V.
5.5.4.4.4 FORCE Event Capability

CardBus PC Card provides the ability to simulate events by forcing values in the socket's Event and
Present State registers, primarily for debug purposes. This is done by generating writes to the
socket Force register. Note that this is not a physically implemented register. Rather, it is an address
at which the socket's Present State register can be written. The effects of a write to this address will
be reflected in the socket's Present State and Event registers. However, other events may alter those
registers before they can be read.
31 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved
Force interrogation of CVS/CCD pins (CVStest)

Card can accept Vcc=Y.Y V (YVcard)
Card can accept Vcc=X.X V (XVcard)
Illegal Vcc value requested (BadVccReq)
Card removal caused data to be lost (DataLost)
Unrecognized card inserted (NotACard)
Reserved
CardBus PC Card inserted (CBcard)
16-bit PC Card inserted (16card)
Power applied successfully (PowerCycle)
State of CSTSCHG pin (CSTSCHG)
Figure 5-47 Socket FORCE Register

Table 5Ð30 Socket FORCE Register Fields

0 CSTSCHG Writing a 1 to this field simulates the assertion of the CSTSCHG pin. This results in
the Event register's CSTSCHG field being set. Note that the CSTSCHG field in the
Present State register is not affected and continues to reflect the present state of the
CSTSCHG pin. Writing a 0 has no meaning.
1 CCD1# Writing a 1 to this field causes the CCD1# field in the Event register to be set. Note
that the CCD1# field in the Present State register is not affected and continues to
reflect the present state of the CCD1# pin. Writing a 0 has no meaning.
2 CCD2# Writing a 1 to this field causes the CCD2# field in the Event register to be set. Note
that the CCD2# field in the Present State register is not affected and continues to
reflect the present state of the CCD2# pin. Writing a 0 has no meaning.
3 PowerCycle Writing a 1 to this field simulates the successful completion of a power cycle event by
causing the PowerCycle field in the Event register to be set. Note that the
PowerCycle field in the Present State register is not affected and continues to reflect
the present state of the interface power. Writing a 0 has no meaning.
4 16card Writes to this field cause the 16-bit PC Card field in the Present State register to be
written. If a card is present in the socket (i.e. CCD1# and CCD2# are asserted),
writes to this bit field are ignored.
5 CBcard Writes to this field cause the CBcard field in the Present State register to be written. If
a card is present in the socket (i.e. CCD1# and CCD2# are asserted), writes to this
bit field are ignored.
7 NotACard Writes to this field cause the NotAcard field in the Present State register to be written.
If a card is present in the socket (i.e. CCD1# and CCD2# are asserted), writes to this
bit field are ignored.
8 DataLost Writes to this field cause the DataLost field in the Present State register to be written.
9 BadVccReq Writes to this field cause the BadVccReq field in the Present State register to be
written.
10 5VCard Writes to this field cause the 5VCard field in the Present State register to be written.
Setting this field disables the socket's ability to power up VCC until the CVStest field is
set in the Force register.
11 3VCard Writes to this field cause the 3VCard field in the Present State register to be written.
set.
12 XVCard Writes to this field cause the XVCard field in the Present State register to be written.
set.
13 YVCard Writes to this field cause the YVCard field in the Present State register to be written.
set.
14 CVStest When written to a 1, causes the adapter to interrogate the CVS[2::1] and CCD[2::1]#
pins and update the nVCard fields in the Present State register. This action also re-
enables the socket to power up VCC if the nVCard fields had been previously forced.

5.5.4.4.5 CONTROL Register

This register provides control of what voltages should be applied to VPP[2::1] and VCC.
31 7 6 4 3 2 0
Reserved
Vcc Requested (VccControl)

Reserved
Vpp Requested (VppControl)
Figure 5-48 Socket CONTROL Register
Table 5Ð31 Socket CONTROL Register Fields

Bit Name Description
0-2 VppControl This field is used to request VPP[2::1] voltages:
000 Requested VPP[2::1] voltage = power off
001 Requested VPP[2::1] voltage = 12.0 V
100 Requested VPP[2::1] voltage = X.X V
101 Requested VPP[2::1] voltage = Y.Y V
110 Reserved
111 Reserved
4-6 VccControl This field is used to request VCC voltages:
000 Requested VCC voltage = power off
001 Reserved
010 Requested VCC voltage = 5.0 V
011 Requested VCC voltage = 3.3 V
100 Requested VCC voltage = X.X V
101 Requested VCC voltage = Y.Y V
110 Reserved
111 Reserved
5.5.4.5 VPP[2::1] Power Requirements

VCC, VPP1, and VPP2 must be initially powered up at the voltage indicated by the CVS[2::1] pins.
Other voltages can be applied to VPP1 and VPP2 only after the allowed values have been
determined from the PC Card's Card Information Structure. (See the Metaformat Specification.)
However, if the PC Card was previously configured and the socket can guarantee that no card
change has taken place, VPP[2::1] may be powered up at the desired voltage instead of VCC.

5.5.4.6 Card Insertion and Removal
5.5.4.6.1 Card Insertion

The CardBus PC Card interface requires Cold socket insertion. This allows the adapter to properly
configure its interface to the correct protocol (16-bit PC Card vs. CardBus PC Card) and determine
the correct voltage for VCC. Card Detect, CCD[2::1]#, and Card Voltage Sense, CVS[2::1], signals
are allowed to be active in this cold state, but must not cause any damage to PC Cards and systems.
When a PC Card insertion is detected, the adapter must:
1. Debounce the CCD[2::1]# pins when a low on the card detect lines occurs.
2. Interrogate the CVS[2::1] and CCD[2::1]# pins to determine the type of PC Card inserted
(CardBus PC Card or 16-bit PC Card) and its VCC requirements. (See 3. Card Type Detection
Mechanism). The results will be reflected in the CBcard, 16card, NotACard, and nVCard fields
of the socket's Present State register.
3. Set up its logic to match the protocol required by the PC Card inserted (16-bit PC Card or
CardBus PC Card). If the adapter chose to drive outputs low to the empty socket, it must High-Z
or power off all signals25 at this time in preparation for power up activities. No signals may be
actively driven High to an unpowered PC Card except CVS1 and CVS2.
4. Notify Card Services that an insertion event occurred by generating a Status Changed interrupt.
The adapter must ensure that the interface is setup for the correct card type before the status
changed interrupt is serviced.
5. Card Services determines the cause of the status changed interrupt (insertion event in this
scenario) by reading the socket's Event register. After identifying the socket, Card Services
reads the socket's Present State register to obtain PC Card type and VCC requirement
information. The power up process will not proceed beyond this point until Card Services gives
permission. Automatic power up upon insertion, i.e., without software involvement, is
forbidden.
WARN I N G :
If a 16-bit PC Card was inserted, then the adapter should proceed with
powering-up the interface as described in 4.4.16.1 Socket Vcc for CIS
Read.
1. Card Services notifies Socket Services of the voltage requirements. Socket Services writes the
appropriate register(s) in the adapter to specify the requested VCC and VPP[2::1] value.
2. The adapter must keep glitches on the CSTSCHG input from causing the CSTSCHG field to be
set in the socket's Event register during the power-up process by disabling this field. This must
be done from card insertion until the "Power Up Complete" condition is reached.
3. If the requested voltage is supported by the PC card and can be supplied to the socket, the
adapter applies that voltage to the socket's VCC and VPP[2::1]26 pins. If the requested voltage is
outside the range decoded from the card's CVS[2::1] pins or is not available in the system, the
adapter must set the BadVccReq field in the socket's Present State register and must not apply
power to the VCC pins. When servicing the status changed interrupt, Card Services must also
read the socket's Present State register to ensure power was successfully applied. Note that this
25CVS1 and CVS2 must not be set to a High-Z state or the CCD# pins will indicate a card removal event for
CardBus PC Cards. If a CardBus PC Card was inserted, CRST# must be driven low.
26The requirements for applying power to Vpp are specified in 5.5.4.5 Vpp[2::1] Power Requirements.

requires the adapter to be aware of the voltages available so that illegal requests can be
detected. CRST# must remain asserted throughout the power up process.
4. The adapter sets the PowerCycle field in the socket's Event register to cause a status changed
interrupt to inform Card Services that the power up process is complete. Note that if an illegal
voltage was requested, no power up will actually occur.
5. After recognizing that the power up process is complete, Card Services clears the socket's
EVENT Register to eliminate spurious interrupt events arising from powering up the interface
(e.g., glitches on CSTSCHG from CardBus PC Cards not supporting remote wakeup).
6. Card Services instructs the socket to negate CRST#. Note that software must ensure that the
timings outlined in 5.3 CardBus PC Card Electrical Specification have been met. Also, software
alone controls the negation of CRST# but hardware will automatically assert CRST# in most
circumstances.
7. Card Services proceeds with the CardBus PC Card configuration process as defined in 5.4
CardBus PC Card Programming Model. (See also the Card Services Specification.)
5.5.4.6.2 Card Removal

CardBus PC Card adapters must consider a PC Card removed when either of the CCD[2::1]# signals
is negated, even if only momentarily. When this condition is detected and a 16-bit PC Card is
present, the adapter must take action as defined in 4.4.1.7 Socket Vcc for CIS Read. If a CardBus PC
Card is present, the adapter must:
1. Immediately idle the bus by asserting CRST# even if the final data phase has not been
completed, driving CGNT# high, and driving CFRAME# high one clock later to allow for a
turn-around cycle. This immediate assertion is necessary since contact bounce issues make it
impossible to reliably execute cycles across the interface. CRST# must remain asserted
throughout the power down process.
Only by physically locking the card in, or providing an imminent removal indication, can
cycles be reliably completed and the need to immediately assert CRST# be avoided. Note that
the imminent removal warning must occur at least 256 CCLK periods before card removal
begins.
2. Drive CAD, CCBE[3::0]#, CPAR, CVS1, and CVS2 low, in addition to CRST#, and set the
other outputs to a High-Z state. The adapter must not drive any signal High to an unpowered
socket.
3. Disable the socket's remote wakeup capability by clearing the CSTSCHG field in the socket's
Mask register. The adapter must also disable the CSTSCHG field in the socket's Event register
to keep glitches on CSTSCHG from causing false status changed events. This action could be
taken in parallel with steps 1-3.
4. Remove power, VCC and VPP[2::1], from the connector. This action must be automatic; it must
not wait for the involvement of software. Note that CGNT# must be set to a High-Z state or
driven low before power is removed.
5. Update the CCD1# and CCD2# fields in the socket's Present State register to set corresponding
fields in the socket's Event register and generate a status changed interrupt notifying Card
Services of the removal event. If a transaction on the CardBus PC Card interface was aborted by
the CRST# assertion or data was stranded in the adapter's buffers, the adapter must also set the
DataLost field in its Present State register.

The dynamic removal of a card creates a window of time, between the

removal event and when the status changed interrupt is serviced, where
clients may attempt to access non-existent resources. In many systems, the
attempted accesses must be completed before pending interrupts can be
serviced. This means that the adapter must accept writes to the removed
card and return "false" data on reads (all one's for x86 architecture systems)
from it. If a new card is inserted, the adapter would have to continue
accepting transactions to the previous card but not forwarding them on. The
only exception is in systems which provide another mechanism to deal with
accesses during this status changed interrupt latency window.
When a socket is in the Cold state, any externally powered CardBus PC Card must appear at the
CardBus PC Card interface like a CardBus PC Card without an external power source. One
exception to this rule is for CSTSCHG which can be driven across the interface by CardBus PC
Cards complying with the remote system wakeup protocol.
5.5.4.7 Power Cycling the Interface

It is recommended for the host system to discharge the CardBus PC Card connector's VCC and
VPP[2::1] to ground as soon as the power is switched off. Further, care should be taken when
dynamically changing the voltage applied to VCC or VPP[2::1] so that power supply shorts do not
occur. The safest implementation is to ensure that all power supply changes transition through 0V.
5.5.4.7.1 Signal Requirements

When powering up or powering down the CardBus PC Card interface, the adapter must hold
CRST# asserted throughout the process. (See 5.3.3.2 Reset.) The CardBus PC Card adapter's inputs
must not react to voltages on its inputs for the duration of the power up or power down process
(except for the CCD[2::1]# and CVS[2::1] pins).
When CRST# is asserted, the interface signals must be driven to their benign state. (See 5.1.2
Signal/Pin Description.) After the interface has been powered down, the adapter may drive the
interface signals low. The adapter must not drive any signal High to an unpowered socket.
5.5.4.7.2 CSTSCHG Requirements

The adapter must default to ignoring the CSTSCHG signal during the power up and power down
procedures. This is necessary because CardBus PC Cards which don't implement remote wakeup
may glitch this pin while VCC transitions. However, this could cause a remote wakeup pulse to be
missed during power down events. Therefore, if the adapter supports remote wakeup and the
CardBus PC Card in the socket has implemented it, Card Services, either on its own or at the
direction of a client, must explicitly enable this capability. The adapter reverts to this default mode
whenever it is reset or the CardBus PC Card is removed.
5.5.4.7.3 In-Rush Current

During the PC Card power up process, a significant amount of capacitance will be instantaneously
added to the power supply's load, drawing a large amount of current. This is referred to as "in-rush"
current. It is the responsibility of the system designer to ensure that this does not pull VCC out of its
specified tolerance range by either current limiting the supply to the socket or other appropriate
means.

5.5.4.8 Required Pins

The implementation of CAUDIO is recommended but not required. All other signals are required.
(See 5.1.2 Signal/Pin Description.)
However, a simplified implementation is allowed for CCLKRUN#. If the adapter is implemented in
a system which will not stop the clock, the adapter may simply assert CCLKRUN# when CRST# is
not asserted and set CCLKRUN# set to a High-Z state when CRST# is asserted.
5.5.4.9 Clock Stopping Support

CardBus PC Card adapters that are going to participate in the clock control protocol (CCLKRUN#)
must be able to communicate with the clock source. The mechanisms required are system bus
dependent but the following behavior must be present in all adapters:
1. The adapter must be able to restart CCLK when a transaction originates on the system bus, or
another CardBus PC Card, and needs to cross the affected CardBus PC Card interface.
2. The adapter must forward "don't stop the clock" requests from the CardBus PC Card to the clock
source in a manner that ensures the clock stream isn't interrupted when the CardBus PC Card
meets the CCLKRUN# specification.
3. The adapter must ensure that the latency involved in restarting the clock doesn't become visible
to software. Note that this has implications on the system design since the adapter doesn't
necessarily have full control of the clock resource.
4. The adapter must not allow the clock to stop before the time specified in the CCLKRUN#
protocol.
5.5.4.10 Special Cycle Support

CardBus PC Card adapters do not have to respond to, or generate special cycles on the CardBus PC
Card interface. This capability has been defined to allow communication in the event sufficient pins
do not exist on the interface.
5.5.4.11 Actions When Adapter Is Reset

When the system resets the CardBus PC Card adapter, the adapter must:
1. Quit accepting transactions on its system bus and CardBus PC Card interfaces.
2. Flush write buffers to its CardBus PC Card interfaces. Flush read buffers when the master
resides on one of its CardBus PC Card interfaces. Any read data intended for masters elsewhere
in the system should be deleted.

6 . PCI BU S POW E R M AN AGE ME N T I N T E R F AC E

F OR CAR D BU S CAR D S
6.1 Introduction
Since its introduction in 1993, PCI has become a very popular bus. It is used in a wide variety of
computer systems sold today ranging from laptops to large servers. Its bandwidth and efficient
support for multiple masters has allowed it to sustain high performance applications while at the
same time, its low pin count and high integration factor has enabled very low cost solutions.
Power Management in the current PC platform is performed by a combination of BIOS and System
Management Mode (SMM) code utilizing hardware unique to each platform. While this strategy has
successfully brought the PC platform into the mobile environment it is beset with problems because
of the fact that there is no standard way to truly determine when the system is busy and when it is
actually idle. The operating system does have this information so it makes sense to give it the
responsibility for power management. The reason that this has not happened up to now is a lack of
standards to provide the operating system with the required information that would allow it to
control the hardware in a platform independent way. This specification addresses this need.
While the PCI Local Bus Specification is quite complete with a solid definition of protocols, electrical
characteristics and mechanical form factors, no provision was made in the original specification for
supporting power management functionality. This specification addresses this requirement by
defining four distinct power states for the PCI bus and four distinct power states for PCI functions as
well as an interface for controlling these power states.
6.1.1 Goals of this Specification

The goal of this specification is to establish a standard set of PCI peripheral power management
hardware interfaces and behavioral policies. Once established this infrastructure enables an
operating system to intelligently manage the power of PCI functions, and buses.
Detailed Goals for PCI Power Management Interface:

• Enable multiple PCI function power levels
• Establish a standard for PCI function wakeup events
• Establish a standard for reporting power management capabilities
• Establish a standard mechanism for controlling a PCI function's power state
• Establish a standard mechanism for controlling a PCI bus's power state
• Minimal impact to the PCI Local Bus Specification
• Backwards compatible with PCI Bus Revision 2.1, and 2.0 compliant designs
• Preserve the designerÕs ability to deliver differentiated products
• Provide a single architecture for all markets from mobile through server

PCI BUS POWER MANAGEMENT INTERFACE FOR CARDBUS CARDS
Key Attributes of this Specification:

• Enhances the PCI BusÕs Plug and Play capabilities by comprehending power management.
• Standardized power state definitions
• Standardized register interface in PCI configuration space
• Standardized wake events
6.1.2 Target Audience

This chapter is intended to address the needs of developers of CardBus cards. This chapter describes
the hardware requirements of such devices to allow the power management of those devices in an
operating system directed power management environment.
Software developers are also a targeted audience for this specification. Specifically, developers of
operating systems and device drivers need to understand the power management interfaces
presented by compliant devices to be able to manage them.
6.1.3 Overview/Scope
In order to implement a power managed system under the direction of the operating system, a
large array of tightly coupled hardware, and software ingredients needs to be defined and
integrated. The following diagram outlines, at a high level, this set of required architectural
building blocks.

OSPM specifications
. Device drivers
specifications
. PM policy specifications
Storage
Audio
Graphics
Platform Architecture Device-Class

Integration Power Management
Specification Specifications
Host PCI Bus

IEEE1394
USB
PCI
Config Regs
I/O Bus
PCI to
Power Management CardBus
Specifications Bridge
SCOPE of
Specification
Config Regs Config Regs
CardBus CardBus
Function Function
Figure 6-1: Operating System Directed Power Management System Architecture
The scope of this specification is sharply focused on establishing a standard set of interfaces that are
required to power manage PCI-to-CardBus Bridges, buses, devices, CardBus cards and functions.
Any PCI based component can use the mechanisms described in this specification.
Devices which can only be implemented on the motherboard are power managed in motherboard-
specific ways (such as ACPI), and as such, fall outside the scope of this specification. Docking
bridges, for example fall into the motherboard devices category because the physical docking
bridge component always resides logically on the motherboard, and is never deployed as an add-in
card. As such Docking bridges are not covered by this specification.
The PCI Bus Power Management Interface Specification describes requirements for implementing
power management for PCI functions which are capable of being used on an add-in card.

6.1.4 Glossary of Terms

Bus Segment Reset Bus Segment Reset is defined as the hardware reset signal that is taken as actual physical
input to a given component within a system. The Bus Segment Reset signal for a CardBus
card is the CRST# signal.
Legacy PCI Devices A class of CardBus cards built before the PCI Bus Power Management Interface Specification
for CardBus was added to the PC Card Standard and are PC Card Standard February
1995 compliant. Legacy CardBus cards are assumed to be in the D0 power management
state whenever power is applied to them.
Operating System Throughout this specification, the terms ÒOperating SystemÓ and Òsystem softwareÓ refer to
the combination of power management services, device drivers, user mode services, and/or
kernel mode services.
Originating Device From the perspective of the operating system (Host CPU), the first bridge component
encountered with a PCI bus downstream of it is defined as the Originating Device for that PCI
bus segment. For a CardBus card, the originating device is the PCI-to-CardBus bridge
controlling its bus (see figure below)
CPU
Host Bus I/F
Host Bridge
Originating Device
PCI Bus I/F for bus(0)
PCI Bus(0)
Primary Bus I/F
PCI to CardBus
Bridge
Secondary Bus I/F
Originating Device
for CardBus bus
CardBus bus
Figure 6-2: Example "Originating Devices"

PCI-to-CardBus Bridge PCI-to-CardBus bridges couple the PCI bus and the CardBus bus together. They are
characterized by a primary bus interface, and a secondary bus interface.
CardBus card (or device) A physical card consisting of one load on the CardBus bus. This single CardBus card may
contain up to 8 CardBus Functions.
CardBus Function A set of functionality inside a CardBus card represented by one 256 byte configuration space.
Each CardBus function within a device generally has a separate software driver.
PCI Function Context The variable data held by the CardBus function, usually volatile. Function context refers to
small amounts of information held internal to the function. Function Context is not limited only
to the contents of the functionÕs PCI registers, but rather refers also to the operational states of
the function including state machine context, power state, execution stack (in some cases),
etc. For example, for a PCI-to-CardBus Bridge, the internal status and mask registers and the
Vcc control signals would be a special case of Function Context which must be preserved.
PME Context Power Management Event Context is defined as the functional state information and logic
required to generated Power Management Events (PMEs), report PME status, and enable
PMEs.
Power Management Mechanisms in software and hardware to minimize system power consumption, manage
system thermal limits and maximize system battery life. Power management involves
tradeoffs among system speed, noise, battery life, and AC power consumption.
Power Management Event (PME) A power management event is the process by which a CardBus function can request a
change of its power consumption state. Typically a device uses a PME to request a change
from a power savings state to the fully operational (and fully powered) state. However, a
device could use a PME to request a change to a lower power state. A power management
event is requested via the assertion of the PME# signal. For a CardBus card, assertion of
CSTSCHG (and STSCHG# for a PC Card) are translated to the host systemÕs PME#
through the PCI-to-CardBus bridge . The power management policies of the system
ultimately dictate what action is taken as a result of a power management event.
Primary or Ordinate Bus The primary bus of a CardBus card refers to the bus that is topologically closest to the CPU
that is running the operating system.
Restore Time Restore time is defined as the time required to fully restore a CardBus function to its fully
operational state from a power saving mode of operation. It is measured as the total elapsed
time between when the system software request for restoration occurs to when the function is
fully configured and activated.
Secondary or Subordinate Bus The secondary bus of a CardBus card refers to the bus that is topologically farthest from the
CPU that is running the operating system.
Sleeping State A computer state where the computer consumes a small amount of power, user mode
threads are not being executed, and the system ÒappearsÓ to be off (from an end userÕs
perspective, the display is off, etc.). Latency for returning to the Working state varies on the
wakeup environment selected prior to entry of this state (for example, should the system
answer phone calls, etc.). Work can be resumed without rebooting the OS because large
elements of system context are saved by the hardware and the rest by system software. It is
not safe to disassemble the machine in this state.
Soft Off State A computer state where the computer consumes a minimal amount of power. No user mode
or system mode code is run. This state requires a large latency in order to return to the
Working state. The systemÕs context will not be preserved by the hardware. The system
must be restarted to return to the Working state. It is not safe to disassemble the machine.
Wakeup Event An event which can be enabled to wake the system from a Sleeping or Soft Off state to a
Working state to allow some task to be performed.
Working State A computer state where the system dispatches user mode (application) threads and they
execute. In this state, devices (peripherals) are dynamically having their power state
changed. The user will be able to select (through some user interface) various
performance/power characteristics of the system to have the software optimize for
performance or battery life. The system responds to external events in real time. It is not safe
to disassemble the machine in this state.
6.1.5 Related Documents

PCI Local Bus Specification, Revision 2.1, June 1, 1995, PCI Special Interest Group
PCI to PCI Bridge Architecture Specification, Revision 1.0, April 5, 1994, PCI Special Interest
Group
PCI Mobile Design Guide, Revision 1.0, October 27, 1994, PCI Special Interest Group

PCI Bus Power Management Specification, Revision 1.0, Mar 18, 1997, PCI Special Interest Group
PC Card Standard, April 1998 (Release 6.1), PCMCIA/JEIDA
Advanced Configuration and Power Interface Specification Revision 1.0, Intel Corporation,
Microsoft Corporation and Toshiba
Toward the ÒOnNowÓ Machine: The Evolution of the PC Platform, Microsoft Technology Brief,
April 1996, Microsoft Corporation
Device Power Management, Microsoft Technology Brief, April 1996, Microsoft Corporation
Device Class Power Management Reference Specifications, Draft Proposals, 1996, Microsoft
Corporation
OnNow Design Initiative and ACPI, Microsoft Web Page with links to many of the documents
above, 1996, Microsoft Corporation
OnNow Power Management and the Win32 Driver Model, 1996, Microsoft Corporation
PCI Hot-Plug Specification, PCI Special Interest Group
6.1.6 Conventions Used in this Chapter

Several conventions are used in this chapter to help make it more readable. These are listed below.
• Power states are shown in bold italic text as in D0.
• Register names are shown in bold text as in PMCSR.
• Names of bits or fields within registers are in italic text as in PowerState.
• Signal names are all capitalized and bold as in PME#.
• All numbers are represented in decimal unless followed by a small letter.
• Hexadecimal numbers are represented with a following ÒHÓ (e.g. DCH).
• Binary numbers are represented with a following ÒBÓ (e.g. 10B).
6.2 CardBus Power Management Overview
6.2.1 CardBus Power Management States

Power management states are defined as varying, distinct levels of power savings. Power
Management states are denoted by a state number. Throughout this chapter power management
states for both CardBus buses and CardBus functions will be defined, specified and discussed. Power
management states for PCI buses, by convention, are prefixed with a ÒBÓ, and end in the power
management state number (0-3). The higher the number the more aggressive the intended power
savings. Similarly for CardBus functions the power management state is prefixed with a ÒDÓ, and
ends with the power management state number (0-3). Intended power savings increase with the
power management state number.
6.2.1.1 CardBus Function Power States

Up to four power states are defined for each CardBus function in the system. These are D0-D3 with
D0 being the maximum powered state, and D3 being the minimum powered state. D1 and D2
power management states enable intermediate power savings states between the D0 (on) and D3
(off) power management states.

While the concept of these power states is universal for all functions in the system, the meaning, or
intended functional behavior when transitioned to a given power management state is dependent
upon the type (or class) of the function.
6.2.1.2 Bus Power States

The power management state of a bus can be characterized by certain attributes of the bus at a
given time such as whether or not power is supplied, the speed of the clock, and what types of bus
activities are allowed. These states are referred to as B0, B1, B2 and B3.
This specification defines a mechanism that enables explicit control of a CardBus busÕ power and
CardBus clock as a function the power management state of its originating device. The mechanism
can be disabled (see 6.3.2.5 PMCSR_BSE - PMCSR PCI-to-PCI Bridge Support Extensions
(Offset=6) Ð Not Used in CardBus Cards - Reserved, and 6.4.7.1 Control of Secondary Bus Power
Source and Clock).
6.2.1.3 Device-Class Specifications

The PCI Bus Power Management Interface Specification standardizes the power management
hardware interface for the CardBus Bus, and CardBus cards. However CardBus functions belonging
to different device classes may behave differently when operating in the same power management
state. This is the notion of Device-Class specific power management policy. For example, the list of
capabilities that an audio subsystem would support in a given power management state would most
likely be different than the list of capabilities supported by a graphics controller operating in the
same power management state.
While Device-Class Power Management Specifications fall outside the scope of this specification,
they are mentioned here to inform the reader of their important relationship to the interfaces
defined in this chapter. Each class of device must have its own class specific set of power
management policies to define their intended behavior while in each of the power management
states.
For a fully integrated power management system, these class-specific power management policies
must also be standardized. Each major device type must have a ÒDevice-Class Power Management
SpecificationÓ that all manufacturers can use as a guide to facilitate the seamless integration of their
power managed products into a system.

Device-Class Specifications will generally cover the following areas:

Device-class power characteristics Each class of CardBus function should have a standard definition for each function power
management state. This should include target power consumption levels, command response
latencies, and state-change latencies. Implementation details for achieving these levels (such
as whether an entire functional block is powered-off or the clock is stopped) might be
important to a particular device class and, if so, should be specified. If any of these
characteristics are in conflict with the requirements of the bus specifications, the function may
not be able to implement that state on that particular bus.
Minimum Device-Class power Each class of CardBus function should have a standard set of power capabilities appropriate
capabilities to the class. An example might be to require support either for all four power states or for
some lesser number. Requirements might also be specified for accuracy and frequency of
power status updates. Finally, there might be class-specific requirements for Wakeup
capabilities. For example, all modems should be able to wake the PC from D1, and so on.
Device-class functional Each class of CardBus function should have a standard definition of the available subset of
characteristics functioning capabilities and features in each power state. For example, the network adapter
can receive, but cannot transmit; the sound card is fully functional except that the power amps
are off; and so on.
Device-class Wakeup characteristics Each class of CardBus function should have a standard definition of its Wakeup policy,
including a recommended resume latency specification. This includes specifying the various
class-specific events that can wake up the system, and the power states from which the
Wakeup can be signaled, with implementation details and examples where appropriate.
6.2.1.4 Bus Support for CardBus Function Power Management

Four base capabilities enable a robust power management solution. The capabilities are defined as:
Get Capabilities operation This operation informs the operating system of the power management capabilities and
features of a given function. It is performed as a part of the Operating SystemÕs device
enumeration27 and uses the information it receives to help determine the power management
policies to implement in the system. Information required from the function include which
power states are implemented, and the functionÕs Wakeup capabilities.
Set Power State operation This operation puts the function into a specific power management state and enables power
management features based on the global system power management policy and the
functionÕs specific capabilities. This includes setting the function to wake the system from a
sleeping state if certain events occur.
Get Power Status operation This operation returns information about the current power state of the CardBus function.
Wakeup operation This is a mechanism for having a CardBus function wake the system from a sleeping state on
specified events.
While individual CardBus functions must support only the first three capabilities with wakeup
being optional, all basic power management operations must be supported by the bus architecture
to ensure that CardBus functions on the bus can be power managed.
For multi-function CardBus cards there is a common portion of bus interface logic that physically
binds each of the supported functions to the CardBus bus. This common logicÕs power consumption
is explicitly reported if supported, using the Data register of Function 0. For further detail on the
reporting of CardBus function power consumption, see 6.3.2.6 Data (Offset = 7).
Control of the common logic is handled by the multi-function device in a software transparent
fashion. For further power savings in a runtime environment, the enabling and disabling of some
portion of this common CardBus bus interface logic is the responsibility of the multi-function
component hardware. This implicit power control, if implemented, may be based upon the power
states of the functions behind it. As an example one might consider a hardware administered logic
control policy where the common logic can not be internally powered down unless all of the
functions hosted by the device have been placed in the D3hot state first.
27 The CardBus function provides power management capabilities reporting through a standard register definition
as specified in this document.

6.3 CardBus Power Management Interface

The four basic power management operations that have been defined are: Capabilities Reporting,
Power Status Reporting, Setting Power State and System Wakeup. Of these four capabilities all are
required of each function with the exception of wakeup event generation. This section describes the
format of the registers in CardBus configuration space which are used by these operations.
The Status and Capabilities Pointer (Cap_Ptr) fields have been highlighted to indicate where the
PCI Power Management features appear in the standard Configuration Space Header.
Device ID Vendor ID 00h

Status (with bit 4 set to 1) Command 04h
Class Code Revision ID 08h
BIST Header Type Latency Timer Cache Line Size 0Ch
10h
14h
Base Address Registers 18h
1Ch
20h
24h
CardBus CIS Pointer 28h
Subsystem ID Subsystem Vendor ID 2Ch
Expansion ROM Base Address 30h
Reserved Cap_Ptr(type 0) 34h
Reserved 38h
Max_Lat Min_Gnt Interrupt Pin Interrupt Line 3Ch
Figure 6-3: Standard PCI Configuration Space Header Type 0
Software must have a standard method of determining if a specific function is designed in

accordance with this specification. This is accomplished by using a bit in the CardBus cardÕs PCI
Status register to indicate the presence of the Capabilities List and a single byte in the standard
CardBus card PCI Configuration Space Header which acts as a pointer to a linked list of additional
capabilities. Software can then traverse the list looking for the proper ID for CardBus card PCI
Power Management (Cap_ID=01H). If there is no Capabilities List (New Capabilities bit in the Status
register = 0) or if the list does not contain an item with the proper ID, the function does not support
the CardBus PCI Power Management interface described in this chapter and the Operating System
will assume that the function only supports the D0 and D3cold power management states. These
Legacy CardBus functions may also require a device specific initialization sequence after any
transition from D3cold to D0 (see 6.8.3 Restoring PCI Functions From a Low Power State).
6.3.1 Capabilities List Data Structure

The New Capabilities bit in the PCI Status Register (offset=06h) indicates whether or not the subject
function implements a linked list of extended capabilities. Specifically, if bit 4 is set, the Cap_Ptr
register is implemented to give the offset in configuration space for the first item in the list.

Table 6-1: PCI Status Register

Bits Default Read/Write Description
Value
15:05 -- -- Definition given in PCI Local Bus Specification Revision 2.1

04 1B Read Only New Capabilities - This bit indicates whether this function implements a list
of extended capabilities such as PCI Power Management. When set this bit
indicates the presence of New Capabilities. A value of 0 means that this
function does not implement New Capabilities.
03:00 0H Read Only Reserved
The location of the Capabilities Pointer (Cap_Ptr) depends on the CardBus cardÕs PCI header type.
See 6.3.1.1 Capabilities List Cap_Ptr Location for Header Type specific Cap_Ptr offsets.
Table 6-2: Capabilities Pointer - Cap_Ptr

Value
07:00 XXH Read Only The Cap_Ptr provides an offset into the functionÕs CardBus cardÕs PCI
Configuration Space for the location of the first item in the Capabilities Linked
List. The Cap_Ptr offset is DWORD aligned so the two least significant bits
are always Ò0Ós.
If a function does not implement any capabilities with IDs defined by the PCI SIG, the New
Capabilities bit in the PCI Status register (bit 4) should read as Ò0Ó and the Cap_Ptr register should
be ignored. Values of 00h-3Fh are not valid values for the Cap_Ptr because they point into the
standard CardBus cardÕs PCI header. A CardBus function may choose any DWORD aligned offset as
indicated in Table 6-3: PCI Configuration Space Header Type / Cap_Ptr mappings.
Standard PCI Config Header Type 0

Cap_Ptr
Offset 34h
8 bits
Next Item ID
Capability X
Next Item 01h
PM Regs
Next Item 0 ID
Capability Y
Figure 6-4: Capabilities Linked List

The figure above shows how the capabilities list is implemented. The Cap_Ptr gives the location of
the first item in the list which is the PCI Power Management Registers in this example (although the
capabilities can be in any order). The first byte of each entry is required to be the ID of that
capability. The PCI Power Management capability has an ID of 01H. The next byte is a pointer
giving an absolute offset in the functionÕs CardBus PCI Configuration space to the next item in the
list and must be DWORD aligned. If there are no more entries in the list, the Next_Item_Ptr must
be set to 0 to indicate that the end of the linked list has been reached. Each capability can then have
registers following the Next_Item_Ptr. The definition of these registers (including layout, size and
bit definitions) is specific to each capability. The CardBus PCI Power Management Register Block is
defined in this specification.
6.3.1.1 Capabilities List Cap_Ptr Location

There are currently three defined PCI Configuration Space Header types. The following table shows
where to find the Cap_Ptr register for each of these Header Types.
Table 6-3: PCI Configuration Space Header Type / Cap_Ptr mappings

Header Associated PCI Function Cap_Ptr Minimum Value Maximum Value
Type Type (PCI Config Space Offset)
0 All other 34H 040H 0F8H
1 PCI-to-PCI Bridge 34H 040H 0F8H
2 PCI-to-CardBus Bridge 14H 080H 0F8H
Regardless of the implemented Header Type the definition of the Cap_Ptr register and the New
Capabilities bit in the CardBus PCI Status register is common.
6.3.2 Power Management Register Block Definition

This section describes the CardBus cardÕs PCI Power Management Interface registers.
The figure below illustrates the organization of the CardBus Power Management Register Block.
The first 16 bits (Capabilities ID [offset = 0] and Next Item Pointer [offset = 1]) are used for the linked
list infrastructure.
The next 32 bits (PMC [offset = 2] and PMCSR registers [offset = 4]) are required for compliance
with this specification. The next 8 bit register (Bridge support PMCSR extensions [offset = 6]) is
required only for bridge functions, and the remaining 8 bit Data register [offset = 8] is optional for
any class of function. As with all PCI configuration registers, these registers may be accessed as
bytes, 16 bit words or 32 bit DWORDs.
Unless otherwise specified, all write operations to reserved registers must be treated as no-ops; that
is, the access must be completed normally on the bus and the data is discarded. Read accesses to
reserved or unimplemented registers must be completed normally and a data value of 0 returned.
Power Management Capabilities (PMC) Next Item Ptr Capability ID Offset = 0

Data PMCSR_BSE Bridge Power Management Control / Status Register Offset = 4
Support Extensions (PMCSR)
Figure 6-5: Power Management Register Block

The offset for each register is listed as an offset from the beginning of the linked list item which is
determined either from the Cap_Ptr (If Power Management is the first item in the list) or the
Next_Item_Ptr of the previous item in the list.
6.3.2.1 Capability Identifier - Cap_ID (Offset = 0)

The Capability Identifier, when read by system software as 01H indicates that the data structure
currently being pointed to is the PCI Power Management data structure. Each function of a PCI
device may have only one item in its capability list with Cap_ID set to 01H.
Table 6-4: Capability Identifier - Cap_ID

Value
07:00 01H Read Only ID - This field, when Ò01HÓ identifies the linked list item as being the PCI
Power Management Registers.
6.3.2.2 Next Item Pointer - Next_Item_Ptr (Offset = 1)

The Next Item Pointer Register describes the location of the next item in the functionÕs capability
list. The value given is an offset into the functionÕs CardBus cardÕs PCI Configuration space. If the
function does not implement any other capabilities defined by the PCI SIG for inclusion in the
capabilities list, or if power management is the last item in the list, then this register must be set to
00H.
Table 6-5: Next Item Pointer - Next_Item_Ptr

Value
07:00 00H Read Only Next Item Pointer - This field provides an offset into the functionÕs PCI
Configuration Space pointing to the location of next item in the functionÕs
capability list. If there are no additional items in the Capabilities List, this
register is set to 00H.
6.3.2.3 PMC - Power Management Capabilities (Offset = 2)

The Power Management Capabilities register is a 16 bit read-only register which provides
information on the capabilities of the function related to power management. The information in this
register is generally static and known at design time.

Table 6-6: Power Management Capabilities Ð PMC for CardBus Cards

Value
15:11 Device Read Only PME_Support - This five bit field indicates the power states in which the
Specific function may assert PME#. A value of 0B for any bit indicates that the function
is not capable of asserting the PME# signal while in that power state.
bit(11) XXXX1B Ð PME# can be asserted from D0
bit(12) XXX1XB Ð PME# can be asserted from D1
bit(13) XX1XXB Ð PME# can be asserted from D2
bit(14) X1XXXB Ð PME# can be asserted from D3hot
bit(15) 1XXXXB Ð PME# can be asserted from D3cold
10 Device Read Only D2_Support - If this bit is a Ò1Ó, this function supports the D2 Power
Specific Management State.
Functions that do not support D2 must always return a value of Ò0Ó for this bit.
09 Device Read Only D1_Support - If this bit is a Ò1Ó, this function supports the D1 Power
Specific Management State.
Functions that do not support D1 must always return a value of Ò0Ó for this bit.
08:06 000B Read Only Reserved
05 Device Read Only DSI - For definition regarding the Device Specific Initialization bit, see the PCI
Specific Bus Power Management Specification.
04 Device Read Only Auxiliary Power Source (VAUX) -This bit is only meaningful if bit 15 (D3cold
Specific supporting PME#) is a Ò1Ó. When this bit is also a Ò1Ó it indicates that support
for PME# in D3cold requires auxiliary power supplied by the system by way of
a the slot Vcc pins and will consume less than 200 mA.
A Ò0Ó in this bit indicates that the function supplies its own auxiliary power
source.
If the function does not support PME# while in D3cold, bit(15)=0, then this field
must always return Ò0Ó.
03 0B Read Only PME Clock - When this bit is a Ò1Ó it indicates that the function relies on the
presence of the PCI clock for PME# operation. When this bit is a Ò0Ó it
indicates that no PCI clock is required for the function to generate PME#.
Functions that do not support PME# generation in any state must return Ò0Ó for
this field.
02:00 001B Read Only Version - A value of 001B indicates that this function complies with the
Revision 1.0 of the PCI Power Management Interface Specification.
6.3.2.4 PMCSR - Power Management Control/Status (Offset = 4)

This 16 bit register is used to manage the PCI functionÕs power management state as well as to
enable/monitor power management events.
The Power Management Event support bits, PME_Status, and PME_En, are defined to be ÒstickyÓ
bits for functions that can generate power management events from D3cold, in that their states are
not affected by power on reset or transitions from D3cold to the D0 Uninitialized state. Preservation of
these bits is typically achieved by either powering them with an auxiliary power source, or by
using non-volatile storage cells for them. The only way to clear out these bits is to have system
software write to them with the appropriate values. For a CardBus card, setting PME_En in state D0
really performs no additional function other than causing the CSTSCHG signal to be latched into
the PME_Status field of the PMCSR. However, in states D1, D2 and D3xxx, CSTSCHG can not be
asserted unless PME_En is set. Again, this causes CSTSCHG, the CardBus cardÕs PME# signal, to
be latched into the PMCSRÕs PME_Status bit. These bits follow the ÒstickyÓ rules associated with any
PCI device. Only a software write to each bit or complete removal of all Vcc voltages, including
VAUX, will cause these bits to change state from a Ò1" to a "0".

As mentioned previously, the PME Function Context is defined as the logic responsible for
identifying power management events, the logic responsible for generating the PME# (CSTSCHG)
signal and the bits within this register that provide the standard system interface for this
functionality. PME Function Context also contains any device class specific status that must survive
the transition to the D0 Uninitialized state as well.
If a function supports PME# (CSTSCHG) generation from D3cold, its PME Function Context is not
affected by either a CardBus slot reset, CRST#, (hardware component reset), or the internal "soft" re-
initialization that occurs when restoring a device from D3hot. This is because the functionÕs Power
Management Event functionality itself may have been responsible for the wake event which caused
the transition back to D0. Therefore, the PME Function Context must be preserved for the system
software to process.
If PME# (CSTSCHG) generation is not supported from D3cold then all PME Function Context is
initialized with the assertion of a bus segment reset.
Because a CardBus bus CRST# assertion does not necessarily clear all functionsÕ PME Function
Context, (functions that support PME# (CSTSCHG) from D3cold), the system software is required to
explicitly initialize all PME Function Context, including the Power Management Event support bits,
for all functions during initial operating system load. In terms of the PMCSR this means that during
the initial operating system load each functionÕs PME_En bit must be written with a "0", and each
functionÕs PME_Status bit must be written with a "1" by system software as part of the process of
initializing the system.

Table 6-7: Power Management Control/Status - PMCSR

Bits Value at Reset Read/ Write Description
15 Sticky Bit, Read/ Write- PME_Status - This bit is set when the function would normally assert the
indeterminate at Clear PME# (CSTSCHG) signal independent of the state of the PME_En bit.
time of initial OS Writing a "1" to this bit will clear it and cause the function to stop asserting
boot if function a PME# (CSTSCHG) (if enabled). Writing a "0" has no effect.
supports PME#
(CSTSCHG) from This bit defaults to "0" if the function does not support PME# (CSTSCHG)
D3cold. generation from D3cold.
0B, if the function If the function supports PME# (CSTSCHG) from D3cold then this bit is
does not support sticky and must be explicitly cleared by the operating system each time the
PME# operating system is initially loaded.
(CSTSCHG) from
D3cold.
14:13 Device Specific Read Only Data_Scale - This two bit read-only field indicates the scaling factor to be
used when interpreting the value of the Data register. The value and
meaning of this field will vary depending on which data value has been
selected by the Data_Select field.
This field is required for CardBus cards.
See 6.3.2.6 Data (Offset = 7)for more details.
12:09 0000B Read Write Data_Select - This four bit field is used to select which data is to be
reported through the Data register and Data_Scale field.
This field is required for CardBus cards.
See 6.3.2.6 Data (Offset = 7)for more details.
08 Sticky Bit, Read/ Write PME_En - "1" enables the function to assert PME# (CSTSCHG). When
indeterminate at "0" PME# (CSTSCHG) assertion is disabled.
time of initial OS This bit defaults to "0" if the function does not support PME# generation
boot if function from D3cold.
supports PME#
(CSTSCHG) from If the function supports PME# (CSTSCHG) from D3cold then this bit is
D3cold. sticky and must be explicitly cleared by the operating system each time the
operating system is initially loaded.
0B, if the function
does not support
PME#
(CSTSCHG) from
D3cold.
01:00 00B Read/ Write PowerState - This two bit field is used both to determine the current power
state of a function and to set the function into a new power state. The
definition of the field values is given below.
00B - D0
01B - D1
10B - D2
11B - D3hot
If software attempts to write an unsupported, optional state to this field, the
write operation must complete normally on the bus, however the data is
discarded and no state change occurs.
6.3.2.5 PMCSR_BSE - PMCSR PCI-to-PCI Bridge Support Extensions (Offset=6) Ð

Not Used in CardBus Cards - Reserved
PMCSR_BSE supports PCI bridge specific functionality and is required for all PCI-to-PCI and PCI-to-
CardBus bridges.

Table 6-8: PMCSR Bridge Support Extensions - PMCSR_BSE

Bits Value at Read/Write Description
Reset
07 0 Read Only BPCC_En (Bus Power/Clock Control Enable) - Reserved

06 0 Read Only B2_B3# (B2/B3 support for D3hot) - Reserved
6.3.2.6 Data (Offset = 7)

The Data Register is an 8 bit read-only register that provides a mechanism for the function to report
state dependent operating data such as power consumed or heat dissipation. Typically the data
returned through the Data register is a static copy (look up table, for example) of the functionÕs
worst case "DC characteristics" data sheet. This data is required for CardBus cards.
Any type of data could be reported through this register, but only power usage is defined by this
version of the specification. The Data_Select and Data_Scale fields must also be implemented.
Table 6-9: Data Register

Value
07:00 00H Read Only Data - This register is used to report the state dependent data requested by
the Data_Select field. The value of this register is scaled by the value reported
by the Data_Scale field.
The Data register is used by writing the proper value to the Data_Select field in the PMCSR and
then reading the Data_Scale field and the Data register. The binary value read from Data is then
multiplied by the scaling factor indicated by Data_Scale to arrive at the value for the desired
measurement. The table below shows which measurements are defined and how to interpret the
values of each register.

Table 6-10: Power Consumption/Dissipation Reporting

Value in Data_Select Data Reported Data_Scale Units/Accuracy
Interpretation
0 D0 Power Consumed
1 D1 Power Consumed
2 D2 Power Consumed 0 = Unknown
3 D3 Power Consumed 1 = 0.1x Watts
4 D0 Power Dissipated 2 = 0.01x
5 D1 Power Dissipated 3 = 0.001x
6 D2 Power Dissipated
7 D3 Power Dissipated
8 Common logic power
consumption (Multi-function PCI
devices, Function 0 only)
9-15 Reserved (function 0 of a multi- 0 = Unknown 1-3 = TBD TBD
function device)
8-15 Reserved (single function PCI 0 = Unknown 1-3 = TBD TBD
devices, and other functions
(greater than function 0) within a
multi-function device)
When using the Data register as a window into the data sheet for the PCI function, data returned
must comply with measurements derived from the following test environment:
• Bus Frequency: 33 MHz
• VCC: 3.3 VDC
The power measurements defined above have a dynamic range of 0 to 25.5 W with 0.1 W
resolution, 0 to 2.55 W with 0.01 W resolution or 0 to 255 mW with 1 mW resolution. Power should
be reported as accurately as possible. For example, the data returned for each state supported must
indicate the maximum power used by the function when in that particular state. The "Power
Consumed" values defined above must include all power consumed from the PCI power planes
through the PCI connector pins. If the PCI card provides power to external devices that power must
be included as well. It should not include any power derived from a battery or an external source.
This information is useful for management of the power supply or battery.
The "Power Dissipated" values provide the amount of heat which will be released into the interior
of the computer chassis. This excludes any power delivered to external devices but must include
any power derived from a battery or external power source and dissipated inside the computer
chassis. This information is useful for fine grained thermal management.
If a function allows a wide range of implementation options, the values reported through this
register may need to be loadable through a serial EPROM or strapping option at reset much like the
Subsystem Vendor ID and Subsystem ID registers
Multi-function devices implementing power reporting should report the power consumed by each
function in each corresponding functionÕs Configuration Space. In a multi-function device, the
common logic power consumption is reported in function 0Õs Configuration Space through the Data
register once the Data_Select field of the function 0Õs PMCSR has been programmed to "1000B". The
sum of the values reported should then be accurate for the condition of all functions in the device
being put in that state.

Each function of each device on the card is responsible for reporting the power consumed by that
function.
6.4 CardBus Bus Power States

This section describes the different power states of the CardBus bus itself.
From a power management perspective, the CardBus bus can be characterized at any point in time
by one of four power management states. B0 corresponds to the bus being fully useable (full power,
and clock frequency) and B3 meaning that the power to the bus has been switched off or is
indeterminate. B1, and B2 represent intermediate power management states. The B1 bus power
management state is defined as a fully powered yet "enforced" idle28 CardBus bus with its clock free
running. The B2 state carries forward the characteristics of the B1 state, but also has its clock
stopped.
The table below shows a mapping of the four defined power states to key characteristics of the PCI
bus.
Table 6-11: CardBus Bus Power Management States

CardBus Vcc Clock Bus Activity
Bus States
B0 (Fully On) On Free running, CardBus Any CardBus Transaction,
compliant Function Interrupt, or PME Event
B1 On Free running, CardBus PME Event
compliant
B2 On Stopped PME Event
B3 Indeterminate except Stopped PME Event

CRST# asserted and
CCLK stopped low.
Bus may be off if VCC
removed
Each CardBus bus in a system has an originating device which can support one or more power
states. In most cases this will be some kind of a bridge such as a PCI-to-CardBus Bridge.
The PC Card Standard defines a bus power (VCC) and clock control mechanism. For a CardBus
bus, the clock control mechanism is CCLKRUN# and the Vcc control mechanism is the Vcc control
registers.
6.4.1 CardBus B0 State - Fully On

All buses support B0 by default.
A bus in B0 is capable of running any legal CardBus transaction.
Since B0 is the only CardBus Bus power management state where data transactions can take place,
system software must ensure that a CardBus bus is in B0 before attempting to access any CardBus
resources on that bus. If an access is attempted to a function residing downstream of a bus that is not
28 Enforced by the operating system which has previously programmed the functions residing on, and further
downstream of, that particular bus segment to power management states that would preclude normal CardBus
transactions or functional interrupts from occurring.

in B0, the transaction must be treated as if a "Master Abort" had occurred and error reporting
handled in the same manner.
It is the system softwareÕs responsibility to ensure that, prior to attempting to program the CardBus
bus to a power management state other than B0, all CardBus card functions residing on that
CardBus bus have previously been programmed to a state that would preclude any further bus
activity initiated by them. For new CardBus functions compliant with the CardBus PCI Bus Power
Management Interface Specification this means that all functions must have been previously
programmed to a power management state that, for each of them, has precluded any bus activity on
their parts. For legacy CardBus functions system software must rely on other means such as
disabling the Bus Master Enable bit of the legacy functionÕs CardBus Command register to ensure
that the function does not attempt to initiate any bus transactions.
The busÕs originating device must always exit from B0 gracefully by first allowing the bus to settle
into the idle state.
6.4.2 CardBus B1 State

When a CardBus bus is in B1, Vcc is still applied to all devices on the bus. However no bus
transactions are allowed to take place on the bus except type 0 configuration cycles. In the B1 state,
the CardBus bus is idle with the clock running. Clock run may be asserted.
Before the CardBus bus can be in the B1 state, the CardBus card must be in device state D1, D2 or
D3. The CardBus card is not allowed to initiate any transaction in these states except PME, therefore,
the PCI-to-CardBus bridge device can use this information to intelligently apply more aggressive
power savings in the bridgeÕs design.
6.4.3 CardBus B2 State

When a CardBus bus is in B2, Vcc is still applied to all devices on the bus but the clock is stopped
using the CCLKRUN# protocol if implemented, and held in the low state. All CardBus Bus signals
are required to be held at valid logic states at all times, consistent with the Electrical Specification.
The B2 state, if comprehended by the bridge design (see 6.4.7 Control/Status of CardBus Bus
Power Management States), provides the bridge function with information indicating that no
functions residing on the bus will attempt to initiate any bus transactions, with the possible
exception of a power management event. Nor do any of the CardBus functions require a CardBus
clock. This information could then be used to intelligently apply more aggressive power savings in
the bridge design. There is a minimum time requirement of 50 ms which must be provided by
system software between when the bus is switched from B2 to B0 and when a device on the bus is
accessed to allow time for the clock to start up and the bus to settle.
6.4.4 CardBus B3 State - Off

In B3, Vcc may be removed from all devices and the CardBus card may be operating on VAUX which
may be supplied through the CardBus slot Vcc pins and limited to 200 mA. When full Vcc is
reapplied to the CardBus bus, CRST# must be asserted for that bus segment, and the bus brought
to an active, idle state in accordance with the Electrical Specification.
In the case of when the PCI-to-CardBus bridge in the D3cold state, after the bridge controller receives
its bus segment reset (RST#), the bridge controller must assert CRST# for its subordinate bus
segments for slots having Vcc applied. Note that the bridge controller may not cause slot Vcc
settings to change when returning to D0 from any power state except on a card removal event.

B3 is exhibited by all PC Card Standard compliant systems when their power is removed. A
programmable interface for placing a bus in B3, or restoring it from B3 is optional.
6.4.5 CardBus Bus Power State Transitions

The CardBus Bus Power States can be changed as shown in the figure below.
B0 B2
(On) (Clock Stopped)
B1 B3
(Idle Bus) (Off)
Figure 6-6: PCI Bus PM State Transitions
A system reset always returns the CardBus bus to B0.

Removing all power always takes the bus to B3. All other bus state changes are made by software,
which writes to the appropriate location in the busÕs originating device. These programmed function
power state transitions implicitly have impact on the next power state for a particular bus. All buses
support B3 by default if power is removed from the system. A bridge may optionally support B3
when its power state is programmed to D3hot.
6.4.6 CardBus Clocking Considerations

PCI-to-CardBus bridge functions, must either directly drive and control the clock to their secondary
bus and/or provide sideband information to an external clock source for that bus segment. Mobile
PCI Clock Run protocol also meets this requirement.
Unless otherwise specified, all CardBus bus clocking is required to be Electrical Specification
compliant.

6.4.7 Control/Status of CardBus Bus Power Management States

CardBus bus power management states, as defined in this specification, adhere to the general policy
that a busÕs power state follows, or tracks, that of its originating deviceÕs power management state.
So by writing to, or reading from, an originating bridge functionÕs PMCSR PowerState field the
operating system can explicitly set, or determine its CardBus busÕs power management state.
Behavioral policy for power managed CardBus functions on a given bus, as defined in 6.5.6
CardBus Card Function Power Management Policies, dictates that a CardBus function must be at
the same or greater power management state as that of the bus it physically resides on. For
example, a PCI-to-CardBus bridge whose secondary bus is in B1 could correctly assume that no
CardBus functions on its secondary bus will attempt to initiate any bus traffic until the bridgeÕs state
is changed to D0 which would result in the secondary busÕs transition to B029. New PCI-to-CardBus
bridge designs could take advantage of this information regarding its surroundings to potentially
achieve further power savings in their designs.
6.4.7.1 Control of Secondary Bus Power Source and Clock

This section defines the standard mechanism that system software uses to control the clock, and
power source of a CardBus bus. This mechanism ties control of secondary bus power and clock to the
originating deviceÕs power management state.
The following table defines the relationship between an originating PCI-to-CardBus bridge
functionÕs power management state, and that of its secondary bus. The third column defines actions
that must occur as a direct consequence of the originating deviceÕs PowerState field having been
programmed to the current power management state.
Table 6-12: PCI Bus Power and Clock Control

Originating DeviceÕs Bridge PM Secondary Bus Resultant Actions by Bridge
State PM States (either direct or indirect)
D0 B0 None or CCLKRUN#
D1 B1 none or CCLKRUN#
D2 B2 Clock stopped on secondary bus or
CCLKRUN#
D3hot B3 Clock stopped and Vcc may be
removed from the slot.
(See definition of B2_B3#
in Table 6-8)
D3cold B3 VAUX support only
CCLK stopped low
CRST# low
Note that the power management state of a CardBus bus segment follows that of its originating
bridgeÕs power management state with one exception. The D3hot state may cause its secondary busÕs
power management state to transition to either B2 or B3.
Clock control for the PCI-to-CardBus bridgeÕs CardBus bus is accomplished using the Mobile PCI
clock run protocol. When the PCI-to-CardBus bridge desires to stop the clock to the CardBus card, it
requests permission from the card. If the card supports stopping the clock, permission is granted as
applicable. When the CardBus card requires that the clock be started again, it uses the clock run
29 Bus activity wouldnÕt actually resume until the downstream functions were also programmed to states that
permitted bus transactions to occur.

protocol to request that the CardBus clock be started from the PCI-to-CardBus bridge. This describes
the D0/B0 scenario. In CardBus card device states D1 and D2, the CardBus card can still request
that the clock be started only if PME_EN is true. In device state D2, the CardBus card must be
capable of the clock run request being denied because the PCI-to-CardBus bridge may not have a
PCI clock to pass on to the CardBus bus. It is expected that the PCI-to-CardBus bridge use the clock
run protocol to stop the clock in when the PCI-to-CardBus bridge is placed in device state D2/B2.
The clock run protocol cannot be exercised in device state D3.
6.5 CardBus Function Power Management States

CardBus defines a device as a physical load on the CardBus bus. Each CardBus device can host
multiple functions, each with its own CardBus configuration space. Since each CardBus function is
an independent entity to the software, each function must implement its own power management
interface. Each CardBus function can be in one of four power management states. All CardBus card
functions that adhere to this specification are required to support D0 and D3hot.
D1 and D2 are optional power management states for CardBus cards. These intermediate states are
intended to afford the system designer more flexibility in balancing power savings, restore time,
and low power feature availability tradeoffs for a given device class. The D1 state could, for
example, be supported as a slightly more power consuming state than D2, however one that yields
more available features and quicker restore time than could be realized from D2.
The D3 power management state constitutes a special category of power management state in that a
function could be transitioned into D3 either by software, or by physically removing power from its
CardBus device. In that sense the two D3 variants have been designated as D3hot and D3cold where
the subscript refers to the presence or absence of Vcc respectively. Functions in D3hot can be
transitioned to an uninitialized D0 state via software by writing to the functionÕs PMCSR register or
by having itÕs Bus Segment Reset (CardBus CRST#) asserted. Functions in the D3cold state can only
be transitioned to an uninitialized D0 state by reapplying Vcc and asserting Card Reset (CRST#) to
the functionÕs CardBus device.
CardBus cards which utilize the D3cold must consume less than 200ma of Vcc current when placed in
the D3 state with PME_En true.
CardBus functions operating in either D0, D1, D2, or D3hot are required to be compliant with the
Electrical Specification.
6.5.1 CardBus Function D0 State

All CardBus functions must support the D0 state.
A CardBus function must initially be put into D0 before being used. Upon entering D0 from power
on reset, or transition from D3hot, the device will be in an uninitialized state. Once initialized by the
system software the function will be in the D0 active state. All CardBus functions must support D0
and a reset will force all CardBus functions to the uninitialized D0 state. Legacy CardBus functions
built prior to the CardBus Bus Power Management Interface specification are assumed to be in D0
whenever power is applied to them. Transitioning from D0 unitialized to D0 active occurs when the
functionÕs appropriate memory, I/O or bus master enable bits are enabled.
All of PCI and CardBus Configuration Space, interrupts and functions are fully functional.

Implementation of the D1 power management state is optional.

D1 is used as a light sleep state. Some functions may be processing background tasks such as
monitoring the network which actually requires most of the function to be active. Allowable
behavior for a given function in D1 is dictated by the Device-Class-Power Management
Specifications for that class of function.
All of PCI and CardBus Configuration Space is functional. Functional context is preserved but not
accessible, functional and CSTSCHG interrupts are not available. PME# is functional.

Implementation of the D2 power management state is optional.
When a CardBus Function is not currently being used and probably will not be used for some time,
it may be put into D2. This state requires the function to provide significant power savings while
still retaining the ability to fully recover to its previous condition. In this state the only CardBus bus
operation the CardBus card function is allowed to initiate is a power management event (PME). The
function is only required to respond to PCI configuration accesses (i.e. memory and I/O spaces are
disabled). Configuration Space must be accessible by system software while the function is in D2.
System software must restore the function to D0 active before memory or I/O space can be accessed.
Initiated actions such as bus mastering and functional interrupt request generation can only
commence after the function has been restored to the D0 active state.
There is a minimum recovery time requirement of 200 µs between when a function is programmed
from D2 to D0 and when the function can be next accessed as a target (including CardBus
Configuration Accesses). If an access is attempted in violation of the specified minimum recovery
time, undefined system behavior may result.
All of CardBus PCI Configuration Space is functional.

All CardBus functions must support D3.
In this state function context need not be maintained. However if power management events (PME)
are supported from D3 then PME context must be retained at a minimum. When the function is
brought back to D0 (the only legal state transition from D3) software will need to perform a full
reinitialization of the function including its CardBus PCI configuration space.
There is a minimum recovery time requirement of 10 ms (enforced by system software) between
when a function is programmed from D3 to D0 and when the function is accessed (including
CardBus Configuration Accesses). This allows time for the function to reset itself and bring itself to a
power-on condition. It is important to note that regardless of whether the function is transitioned to
D0 from D3hot or D3cold, the end result from a software perspective is that the function will be in the
D0 Uninitialized state.
All of PCI Configuration Space can be read and is valid. The PowerState, PME_En and PME_Status
bits must be functional. PME_En and PME_Status are functional only if the card supports PME in the
D3 state.
6.5.4.1 Software Accessible D3 (D3hot)

Functions in D3hot must respond to configuration space accesses as long as power and clock are
supplied so that they can be returned to D0 by software.
When programmed to D0 the function performs the equivalent of a warm (soft) reset internally, and
returns to the D0 Uninitialized state without PCI RST# being asserted and without asserting

CRST#. Other bus activity may be taking place during this time on the same CardBus bus segment
so the device that has returned to D0 Uninitialized state must ensure that all of its CardBus signal
drivers remain disabled for the duration of the D3hot to D0 Uninitialized state transition30.
The only function context that must be retained in D3hot and through the soft reset transition to the
D0 Uninitialized state is the PME context.
There is a required delay of 10 ms when changing the state from D3 to D0 before the CardBus card
can be accessed.
6.5.4.2 Power Off (D3cold)

If Vcc, including VAUX, is removed from a CardBus card device, all of its CardBus functions transition
immediately to D3cold. All CardBus device functions support this state by default. When power is
restored, CardBus CRST# must be asserted and functions will return to D0 (D0 Uninitialized state)
with a full PC Card Standard Electrical Specification compliant power-on reset sequence.
Whenever the transition from D3 to D0 is initiated through assertion of CardBus CRST#, the power-
on defaults will be restored to the function by hardware just as at initial power up. The function
must then be fully initialized and reconfigured by software after making the transition to the D0
uninitialized state.
Functions that support power management events from D3cold must preserve their PME context
through the D3cold to D0 transition. PME context takes precedence over initialization default context
when returning from a PME_En enabled D3cold state. The power required to do this must be
provided by some auxiliary power source assuming that no power is made available to the PCI
device from the normal Vcc power plane.
If the host platform supports D3cold power management events, it must provide a minimum of 200
mA of IAUX for each slot so indicated. CardBus cards have no method to determine when the cardÕs
state is D3cold and not D3hot. It is appropriate for the CardBus card to enter the D3cold state from the
D3hot state when PME_En is true and the host CardBus bus enters state B3. The CardBus card can
then qualify the D3cold transition by PME_En true, CRST# low (asserted). By specification, when the
CardBus bus transitions from B3 to B0, the bus continues to assert CRST# for 100 clocks, thus the
CardBus card can utilize the transition of the bus to transition from D3cold to D0 uninitialized.
6.5.5 CardBus Function Power State Transitions

All CardBus function power management state changes are explicitly controlled by software except
for hardware reset which brings all functions to the D0 Uninitialized state. The figure and table
below shows all supported state transitions. The unlabeled arcs represent a software initiated state
transition (Set Power State Operation).
4CardBus bus signal drivers must behave the same as if the component had received a CRST#.

Power on
Reset
D0
Uninitialized
CRST#
D0
Active D2
soft reset D3 cold
D1 D3 hot Vcc removed

Vaux applied
Figure 6-7: PCI Function Power Management State Transitions

Table 6-13: State Diagram Summary
Present state Valid next states

D0 (unitialized) Software:
á D0 (active)
á D3
Hardware:
á D0 uninitialized via bus segment reset
á Off
D0 (active) Software:
á D1, D2, D3
Hardware:
á Off
D1 Software:
á D0, D2, D3
Hardware:
á Off
D2 Software:
á D0, D3
Hardware:
á Off
D3hot Software:
á D0 uninitialized
Hardware:
á D3cold if VAUX supplied
á Off
D3cold Software:
á None
Hardware:
á Off
6.5.6 CardBus Card Function Power Management Policies

This section defines the behavior for CardBus card functions. The figure below illustrates the areas
being discussed in this section.

PCI to
CardBus
Bridge
SCOPE
Config Regs Config Regs

CardBus CardBus
Card Card
Function Function
Figure 6-8: Non-Bridge CardBus Function Power Management Diagram
The following tables define the behavior for a CardBus card function while operating in each
combination of bus and functional power management states.
Legend:
CardBus Function PM State Current CardBus function power management state.
CardBus Bus PM State Current power management state of the CardBus functionÕs hosting CardBus bus segment.
Context Configuration register and functional state information that are required to be valid for the
given power management state. The registers that must remain valid, and the features that
must remain available for a given class of device are typically dictated by the corresponding
Device-class power management specification.
Power Power consumption
Access Delay The minimum required delay before attempting to access the CardBus function to change its
power state. If the bus is fully accessible (B0) then this delay is solely the result of the state
transition delay, or recovery time, following the last write to the functionÕs PowerState field. If
the bus is not in a fully accessible state (B1, B2 or B3) then the delay is characterized by
either the functionÕs state transition recovery time, or the time it takes to restore the bus to a
fully accessible state, whichever is greater.
Restore Time The total time from when a CardBus function transitions from its current power management
state to the fully configured D0 active state. (Measurement beginning from either a write to the
functionÕs PMCSR, or a bus segment reset).
Actions to Function Valid CardBus bus transactions that can be conducted with the function as the target of the
transaction.
Actions from Function Valid CardBus bus transactions, and/or operations that can be initiated by the function.

Table 6-14: D0 CardBus Card Power Management Policies

CardBus CardBus Context Power Access Restore Actions to Actions from Function
Bus PM Function PM Delay Time CardBus card
State State
B0 Legacy CardBus Full Full None None Any CardBus Any CardBus Transaction
Function (D0) Transaction or Interrupt
B0 D0 PME <70mA Vcc: off -> on, None None CardBus None
(Uninitialized) Context* 245mA if transitioning Config Cycles
from D3cold with
PME_En true
B0 D0 (Active) Full Full None None Any CardBus Any CardBus Transaction
Transaction or Interrupt, PME*
B1-B3 D0 (Active) N/A** N/A** N/A** N/A** N/A** N/A**

CardBus CardBus Context Power Access Delay Restore Actions to Actions from Function
Bus PM Function PM Time CardBus card
State State
B0 D1 Device Class < D0 None Device CardBus PME only*

Specific and uninitialized Class Config Cycles
PME Context* Specific
B1 D1 Device Class < D0 Bus Device None PME only*
Specific and uninitialized restoration Class
PME Context* time Specific
B2-B3 D1 N/A** N/A** N/A** N/A** N/A** N/A**

Bus PM Function PM Time CardBus card
State State
B0 D2 Device Class < next lower 200 µs Device CardBus PME only*
Specific and supported PM (Note 1) Class Config Cycles
PME Context* state, or < D0 Specific
uninitialized
B1 D2 Device Class < next lower Greater of Device None PME only*
Specific and supported PM either the bus Class
PME Context* state, or < D0 restoration Specific
uninitialized time or 200 µs
(Note 2)
B2 D2 Device Class < next lower Greater of Device none PME only*
Specific and supported PM either the bus Class
PME Context* state, or < D0 restoration Specific
uninitialized time or 200 µs
(Note 2)
B3 D2 N/A** N/A** N/A** N/A** N/A** N/A**

Table 6-17: D3hot CardBus Card Power Management Policies

Bus Function PM Time CardBus card
State State
B0 D3hot PME and < next lower 10 ms Device CardBus PME only*
functional supported PM (Note 1) Class Config Cycles
context* state, or < D0 Specific
uninitialized
B1 D3hot PME and < next lower Greater of Device none PME only*
functional supported PM either the bus Class
context* state, or < D0 restoration Specific
uninitialized time or 10 ms
(Note 2)
B2 D3hot PME and < next lower Greater of Device none PME only*
functional supported PM either the bus Class
context* state, or < D0 restoration Specific
uninitialized time or 10 ms
(Note 2)
B3 D3hot PME and < next lower N/A N/A none PME only*
functional supported PM
context* state, or < D0
uninitialized
Table 6-18: D3cold CardBus Card Power Management Policies

Bus Function PM Time CardBus card
State State
B3 D3cold PME context VAUX N/A full none PME only*

only* context
restore,
or boot
latency
B3 Legacy CardBus none No Power N/A full none none
Function (D3) context
restore,
or boot
latency
Notes:
* If PME is supported in this state
** This combination of function and bus power management states is not allowed.
*** Implies device specific, or slot specific power supplies which is outside the scope of this specification.
Additional Notes:
1. This condition is not typical. It specifies the case where the system software has programmed the
functionÕs PowerState field and then immediately decides to change its power state again. Typically the
state transition recovery time will have expired prior to a power state change request by software.
2. The more typical case where the bus must first be restored to B0 before being able access the function
residing on the bus to request a change of its power state. State transition recovery time begins from
the time of the last write to the functionÕs PowerState field. In this case the bus restoration time is
dictated by state transition recovery times incurred in programming the busÕs originating device to D0
which then transitions its bus to B0. Bus restoration time is typically the deciding factor in access delay
for this case. (see 6.5.6.1 State Transition Recovery Time Requirements)
When in D1, D2 or D3hot a CardBus function must not respond to CardBus transactions targeting its
I/O or memory spaces or assert a functional interrupt request.
A CardBus function cannot tell the state of its CardBus bus; therefore, it must always be ready to
accept a CardBus configuration access when in D1, D2 or D3hot.

6.5.6.1 State Transition Recovery Time Requirements

The following table shows the minimum recovery times (delays) that must be guaranteed, by
hardware in some cases and by system software in others, between the time that a function is
programmed to change state and the time that the function is next accessed (including CardBus
configuration space).
Table 6-19: CardBus Function State Transition Delays

Initial State Next State Minimum System Software Guaranteed Delays
D0 D1 0
D0 or D1 D2 200 µs
D0, D1 or D2 D3hot 10 ms
D1 D0 0
D2 D0 200 µs
D3hot D0 10 ms
6.6 CardBus Cards and Power Management

With power management under the direction of the operating system each class of devices (PCI and
CardBus functions) must have a clearly defined criteria for feature availability as well as what
functional context must be preserved when operating in each of the power management states.
Some example Device-Class specifications have been proposed as part of the Intel/Microsoft/Toshiba
ACPI Specification for various functions ranging from audio to network adapters. While defining
Device-Class specific behavioral policies for most functions is well outside of this specificationÕs
scope, defining the required behavior for the CardBus interface function is within the scope of this
specification. The definitions here apply to the PCI-to-CardBus cards.
The mechanisms for controlling the state of these function vary somewhat depending on which type
of originating device is present. The following sections describe how these mechanisms work for
CardBus cards.
This section details the power management policies for CardBus card functions. The CardBus card
function can be characterized as a CardBus bus load.
The shaded regions in the figure below illustrate what will be discussed in this section.

PCI
PCI to SCOPE
PCI Bus Segment CardBus
Bridge
Config Regs Config Regs Config Regs
CardBus Segment
Function Function Function
Figure 6-9: CardBus Card Power Management Diagram
The following table defines the relationship between a bridge functionÕs power management state,
and that of its secondary bus. Also detailed are the resultant attributes of the secondary bus. The
rightmost column of the table details a set of conditions that all "downstream" CardBus card
functions must be capable of withstanding when residing on a bus in a given state without their
application breaking in a way that cannot be gracefully recovered from.
It is the responsibility of the system software to ensure that only valid, workable combinations of
bus and downstream PCI-to-CardBus bridge and CardBus bus function power management states
are used for a given CardBus bus and the CardBus card functions residing on that bus.
Legend:
Bridge PM State Current CardBus function power management state of bridge function.
Secondary CardBus Bus State Current power management state of the originating deviceÕs CardBus bus segment.
Secondary CardBus Attributes The characteristics of the secondary bus for the current bus power management state.
Downstream Function Attributes Necessary attributes of a CardBus function residing on the secondary bus given the
secondary busÕs power management state.

Table 6-20: CardBus Card Power Management Policies

Present state Valid next states CardBus Card Requirements in Present State
D0 (unitialized) Software: Vcc: On
á D0 (active) Bus (including CCLK): Per PC Card Standard for appropriate card technology
á D3 Context (CardBus bus in B0)
Hardware: PME_En false
á D0 uninitialized via No context, power on defaults
CardBus bus segment PME_En true
reset
PME context
á Off
Power consumed by the CardBus card is < 70 mA if coming from no Vcc or VAUX, <
245mA if PME_En true and returning from D3cold state
D0 (active) Software: Vcc: On
á D1 Bus (including CCLK): B0
á D2 CardBus clock is running unless Clock Run is asserted. If clock run is not
functional in the PCI-to-CardBus bridge, clock is on
á D3
CardBus bus is fully functional
Hardware:
CardBus card functional and CardBusStatusChange interrupts are functional
á D0 uninitialized via
PCI bus segment reset All context, PCI and functional, is available.
á Off Card responds appropriately to all CardBus bus cycles
Power consumed by the CardBus card is as specified by the vendor for the D0 / B0
state
D1 Software: Vcc: On
á D0 Bus: B1
á D2 CardBus clock is running unless Clock Run is asserted. If clock run is not
functional in the PCI-to-CardBus bridge, clock is on
á D3
CardBus bus is idle
Hardware:
CardBus card functional and CardBusStatusChange interrupts are not available
PCI bus segment reset CardBus card PME# is available if PME_En is true
á Off CardBus Card responsibilities:
All context, PCI and functional, is preserved; CardBus card PCI configuration
space is readable; functional context is not available; only CardBus card Power
Management Control and Status Register PowerState bits are required to be
writeable
CardBus card only responds to CardBus type 0 cycles
Power consumed by the CardBus card is as specified by the vendor for the D1 / B1
state but must be lower than the < 200mA
D2 Software: Vcc: On
á D0 Bus: B2
á D3 CardBus clock is not running unless Clock Run is required by CardBus card. If
clock run is not functional in the PCI-to-CardBus bridge, clock is off
Hardware:
CardBus bus is idle
PCI bus segment reset CardBus card functional and CardBusStatusChange interrupts are not available
á Off CardBus card PME# is available if PME_En is true
CardBus card responsibilities:
All context, PCI and functional, is preserved; CardBus card PCI configuration
space is readable; functional context is not available
Power consumed by the PCI-to-CardBus bridge is as specified by the vendor
for the D2 / B2 state but must be lower than the D1 / B1 state

D3hot Software: Vcc: On

á D0 uninitialized Bus: B3
Hardware: CardBus clock is off
á D0 uninitialized via CardBus bus is indeterminate except CRST# and CCLK which must be low
PCI bus segment reset Interrupts are not available
á D3cold if VAUX supplied CardBus card PME# is available if PME_En is true
á Off CardBus card responsibilities:
Only PME context is preserved if PME_En is true; CardBus card PCI
configuration space is readable; functional PME context is not available; only
CardBus card Power Management Control and Status Register PowerState,
PME_En and PME_Status bits are required to be functional
Power consumed by the PCI-to-CardBus bridge is as specified by the vendor
for the D3 / B3 state but must be lower than the D2 / B2 state
D3cold Software: Vcc: Off, VAUX on if required
á None Bus: Off
Hardware: CardBus clock is off
á D0 uninitialized via CardBus bus is indeterminate except CRST# and CCLK which must be low
PCI bus segment reset Interrupts are not available
á Off Card PME# is available if PME_En is true
CardBus card responsibilities:
Only PME context is preserved if PME_En is true
Does not respond to any PCI cycles
Power consumed by the CardBus card is required to be < 200 mA
6.6.1 CardBus Card Context

CardBus does not define a PME# signal, however it does define a signal with similar intended
usage. The Card Status Change signal will be used as a source for power management events for a
CardBus card and /Status Change will be used for a PC Card. The PCI-to-CardBus Bridge will use
this event as one condition for assertion of PME#.
CardBus card CardBus PME context consists of the CardBus Function Event Register and the
CardBus Function Event Mask Register.
6.6.2 PME_En/PME_Status and CardBus Cards

A CardBus cardÕs PME_En has special requirements unlike a standard PCI device because there is
no CardBus device driver defined in an ACPI operating system. In order to support power
management events using an ACPI operating systemÕs PCI device driver, the PME_En bit must
support generating a CSTSCHG for a CardBus card.
When the operating system sets PME_En true, this action must set (1) the GWAKE (bit 4) and WKUP
(bit 14) bit fields in the CardBus Function Event Mask Register. Setting PME_En false must clear (0)
GWAKE and WKUP as well. The CardBus function must continue to target the GWAKE bit in the
Function Event Register as the function general wakeup event. When enabled (PME_En true), a
CSTSCHG event is latched into PME_Status and the CardBus cardÕs GWAKE bit in the Function
Event Register.
PME_En must make the CardBus card power management event functionality act as if the CardBus
card were a standard PCI device. PME_Status functionality maps to CardBusÕs CSTSCHG and
PME_En functionality maps to CardBusÕs GWAKE / WKUP. Clearing the GWAKE / WKUP mask

bits does not clear the PME_En bit in the PMCSR. If CSTSCHG is asserted, setting PME_En false
will prevent the CSTSCHG pin from being asserted and clear the GWAKE and WKUP bits in the
Function Event Mask Register. Writing a "1" to the PME_Status bit will clear the GWAKE bit in the
Function Event Register and clearing the GWAKE bit in the Function Event Register clears the
PME_Status bit in the PMCSR register.
Setting the Function Event Mask RegisterÕs READY (Ready/Busy), BVD1:2 (Battery Voltage detects)
and WP (Write Protect) may also generate a CSTSCHG event, however, these bits are not required
to track PME_En and BVD1, BVD2, READY and WP are not required to follow PME_Status. If
PME_En is false, changes in the CardBus card Function Event registers have no effect on PME_En /
PME_Status.
It is imperative that each hardware configuration set be controlled by the appropriate software
controller. It is expected that ACPI software configures power management in a CardBus card using
PME_En / PME_Status. Non-ACPI software should work with the CardBus Function Event registers.
Furthermore, it is expected that a CardBus card configured through PME_En / PME_Status generate
a PME# through the CardBusÕ bridge and a non-ACPI configured CardBus card generate a
CSTSCHG through the CardBusÕ bridge.
Table 6-21: PME_En / PME_Status Summary in a CardBus Card

ACPI Operating System
CardBus PCI Function Event Mask Register Function Event CardBus pin CardBus PCI
Configuration Register Configuration Space
Space
PME_En GWAKE WKUP GWAKE CSTSCHG PME_Status
Default 0 Default 0 Default 0 Default 0 Default 0 Default 0
Written 1 Follows PME_En 0 0 0
1 1 1 0 0 0
1 1 1 1 1 Latches CSTSCHG
change
Written 0 Follows PME_En 1 0 1
DonÕt care DonÕt care DonÕt care 0 0 Written 1
Non-ACPI Operating System
No effect Per Electrical Specification No effect
The setting of the CardBus cardÕs PME_En enables the CSTSCHG signal to be active in states other
than D0. Only if PME_En is true can the CardBus card assert CSTSCHG in device states D1, D2 and
D3. CSTSCHG can be asserted with or without PME_En true in device state D0. If PME_En is true,
then the assertion of CSTSCHG is latched into the CardBus cardÕs PCI Power Management
PME_Status bit. There may be additional PME function context which must be preserved, but that is
implementation specific and is not addressed in this specification.
6.7 Power Management Events

The Power Management Event (PME#) signal is defined as an open drain, active low signal that is
to be driven low by a PCI function to request a change in its current power management state
and/or to indicate that a power management event has occurred. Since CardBus does not have a pin
to dedicate to the PME# function, CardBusÕs CSTSCHG will implement the functionality. The level
and signal translation will be performed in the PCI-to-CardBus bridge.
. CardBus devices must be enabled by software before asserting this signal. Once asserted, the
device must continue to drive the signal low until software explicitly clears the PME_Status or

PME_En bit in the PMSCR register of the function. PME_STATUS and PME_En are only cleared
when written with a "1".
PCI bus power management aware software will enable its use by setting the PME_En bit in the
PMCSR. When a CardBus card function generates or detects an event which requires the system to
change its power state (e.g. the phone rings), the function will assert CSTSCHG. It must continue to
assert CSTSCHG until software either clears the PME_En bit or clears the PME_Status bit in the
PMCSR even if the source of the power management event is no longer valid (e.g. the phone stops
ringing). This requirement is true even though the operating system software may clear the Event
Register bits which caused the PME. Some devices which are powered by a battery or some external
power source may use this signal even when powered off. Such devices must maintain the value of
the PME_Status bit through reset (CRST#).
6.7.1 Auxiliary Power for D3cold Power Management Events

Power managed systems that support PME generation while in the D3cold state may require an
auxiliary power source. There are several ways to provide auxiliary power for any necessary "keep
alive" circuitry including but not limited to:
1. On-Board Battery
2. AC "Brick" adapter, externally provided power source
3. Auxiliary power supplied by the system
In the case of the CardBus card, the auxiliary supply provided for the controller will be limited to
200 mA provided via the Vcc pins as there are no pins available on the CardBus card connector that
can be designated VAUX. The CardBus card must not consume more than 200 mA Icc when:
1. The CardBus card is programmed to the D3 state and
2. The CardBus clock is stopped and
3. The CardBus bus is idle and
4. The PME_Support bit 15, D3cold, bit is set
The transition from Vcc to VAUX can occur only after the above three conditions are implemented.
Additionally, the transition from Vcc to VAUX must include the stable application of VAUX for a
minimum of 50 ms prior to transitioning Vcc off. Likewise, when transitioning from off to on, VAUX
must remain stable for 50 ms after Vcc is up and stable. See Figure 6-10: Vcc to VAUX Transitioning
for more information.

Vcc
CardBus
going
inactive
VAUX
50ms Vcc transitions to VAUX
Figure 6-10: Vcc to VAUX Transitioning
6.8 Software Support for PCI Power Management

The PCI Power Management specification for CardBus defines the requirements for PCI and
CardBus functions to be managed by an Operating System. The specification does not attempt to
define any sort of Power Management Policy. That is left up to the individual Operating System.
However, it is necessary to address some of the basic assumptions that have been made regarding
which aspects of power management are enforced by system software versus by hardware such that
the functions might react appropriately. These assumptions fall into four basic categories:
Identifying PCI and CardBus Function Capabilities, Placing PCI and CardBus Functions in a Low
Power State, Restoring PCI and CardBus Functions from a Low Power State, and Wake Events.
Within each of these areas, it has been assumed that the Operating System software will handle
certain power management functions in addition to itÕs basic power management policy. It must be
noted that in the context of this chapter references to the Operating System software include any
device drivers and other Operating System specific power management services.
6.8.1 Identifying CardBus Function Capabilities

The Operating System software is responsible for identifying all CardBus function power
capabilities by traversing the New Capabilities structure in CardBus cardÕs PCI Configuration space,
and reading the Power Management Capabilities Register (PMC). It is the Operating SystemÕs
responsibility to ensure that it does not attempt to place a function into a power management state
which the function does not support. If, for any reason, the Operating System software attempts to
put a function into a power management state that the function does not support, the function
should handle this gracefully31, and remain in whatever state it was in before the request. The
PowerState bits of the PMCSR will reflect the current state of the function, not the intended invalid
state which was written.
31 Finish the PCI transaction with normal completion and ignore the write data. This is NOT a hardware error
condition.

6.8.2 Placing CardBus Functions in a Low Power State

When attempting to place a CardBus function in a low power state D1 - D3, it is the Operating
SystemÕs responsibility to ensure that the function has no pending (host initiated) transactions, or in
the case of a Bridge device, that there are no CardBus functions behind the bridge that require the
bridge to be in the fully operational D0 state. Furthermore, it is the Operating SystemÕs
responsibility to notify any and all device drivers that are conducting peer-to-peer transfers to the
target function that the target function will no longer be accessible. In other words, it is the
Operating SystemÕs responsibility to ensure that no peer-to-peer activity occurs with the sleeping
CardBus function as the target. If the Operating System and the PCI function both support Wake
Events, the Operating System should enable the functionÕs Power Management Event ( PME# -
CardBus cardÕs CSTSCHG) line via the PME_En bit in the functionÕs Power Management Control
Register (PMCSR).
6.8.2.1 Buses
When attempting to place a CardBus Bus segment into a lower power management state (B1- B3)
the Operating System must first ensure that all CardBus functions on that bus have been placed in
an appropriate low power state.
6.8.2.2 D3 State
Prior to placing a CardBus function into D3, the Operating System must determine if it has the
capability to restore the function from this state. Restoration includes reinitializing the function. The
Operating System must make sure that it has the appropriate driver loaded for that function in
order to restore the functions to operation. If the Operating System is not capable of fully
reinitializing a device, then the Operating System should not put the device into D3. When placing
a function into D3, the Operating System Software is required to disable I/O and memory space as
well as Bus Mastering via the CardBus PCI Command Register.
6.8.3 Restoring PCI Functions From a Low Power State
6.8.3.1 Dx States and the DSI Bit

For support of the DSI (Device Specific Initialization) bit, consult the PCI Bus Power Management
Specification.
6.8.3.2 D1 and D2 States

Restoring a function from D1 or D2 simply requires the Operating System to update the PowerState
field of the PMCSR. System software must ensure that sufficient time elapses between when the
PMCSR is updated and when the first access targeting that PCI function may occur.
6.8.3.3 D3 State
Restoring a function from D3 requires the Operating System to reinitialize the function, beginning
with, for the case of D3cold, restoring power to the device and initiating a PCI Bus Segment Reset.
This is accomplished by either programming the hosting busÕs originating device to D0, or by other
ACPI-type control methods. Full context must be restored to the function before it is capable of
resuming normal operation. For example reintialization includes, but is not necessarily limited to
restoring the Base Address Registers, re-enabling the I/O and Memory spaces, re-enabling Bus

Master capabilities, and unmasking any IRQs or PCI Interrupts as well as restoring the INT Line
register. Furthermore, if the function has the DSI bit set, the Operating System is required to
execute whatever initialization code is necessary, either via the device driverÕs initialization code or
executing POST.
6.8.4 Wake Events
6.8.4.1 Wake Event Support

PCI Power Management supports Wake events generated by functions on the PCI bus in which the
CardBus cardÕs CSTSCHG becomes a PME# event. Assuming the Operating System supports Wake
Events, it is the system hardwareÕs responsibility to restore the Host processor subsystem to a state
which will permit the Operating System to function (through ACPI or some other architecture). If
the sub-system is already in a D0 state, then the system hardware does not need to take any special
action. The System is responsible for notifying the Operating System that a PCI Power Management
Event has occurred. It is expected that PME# will generate some form of System Configuration
Interrupt (SCI), but whether this interrupt is handled by a device driver or an Operating System
service routine, is left up to the individual Operating System architecture.
Once the Operating System has been notified that a PCI PME has occurred, it is the Operating
SystemÕs responsibility to restore power to the primary PCI and CardBus bus and to restore it to the
B0 state, then to restore power to any unpowered slots/devices, and finally query the PCI and
CardBus functions that have been configured with PME# enabled to determine which function, or
functions had generated PME#. If the generating device is a bridge device, the Operating System
should follow this procedure for any subsequent PCI bridges. Should PME# become deasserted
before the Operating System identifies the device which generated it, or before the PME# is
serviced, the Operating System must recover gracefully. Furthermore, the Operating System must
be able to handle multiple PME#s generated by different functions simultaneously. Upon
identifying the source or sources of the PME#, it is up to the Operating System Power Management
Policy to identify the correct course of action with regard to waking the functions and/or the rest of
the system.
6.8.4.2 The D0 "Initialized" State From a Wake Event

Before the Operating System returns a function to D0 which will require a re-initialization of the
function, it must ensure that the Operating System not only has the information necessary to re-
initialize the function, but also any information necessary to restore the function as well. This
information is often client specific. As an example, assume a modemÕs client has set up a modem
function in a specific state additional to default initialization (error correction, baud rate, modulation
characteristics, etc.). The client/function then goes unused for an extended amount of time which
may cause the power manager to place the modem in a D2 or perhaps even a D3 state.
When the client is called upon to interact with the modem (such as a ring-resume event), the
Operating System will have transitioned the modem function to the D0 initialized state. However
restoration of the modem function to D0 alone may not be sufficient for the function and client to
perform the indicated task. It is manifest upon Device-Class specifications to include sufficient
context save requirements for successful restoration of a function. The restoration must be
transparent to the extent that the host application is unaware that a power state transition and the
associated restoration occurred.
Transitioning from D0 unitialized to D0 active is defined when the appropriate memory and IO
windows and busmastering enable bits are set by the operating system.

6.8.5 Get Capabilities

The Get Capabilities operation is performed by the operating system as it is enumerating devices in
the system. Get Capabilities tells the Operating System information about what power management
features the device supports. This includes which power states the device supports, whether or not
the device supports waking the machine and from what power states it is capable of wakeup.
6.8.6 Set Power State

The Set Power State operation is used by the operating system to put a device into one of the four
power states. The operating system will track the state of all devices in the system.
6.8.7 Get Power Status

The Get Power Status operation is used by the operating system to determine the present state of
the power configuration (power states & features). This operation will read the PMC and PMCSR to
obtain this information. Software assumes that reported status information reflects the current state of
the function. Therefore functions should update status information bits ONLY after carrying out the
intended task.
6.9 Other Considerations

In addition to supporting the minimum set of required mechanisms defined in this specification,
designers of PCI devices and systems are encouraged to add additional power management
functionality, taking advantage of the optional headroom provided by this specification.
Designers are encouraged to design for low power consumption in all operating modes. The PCI
Mobile Design Guide makes several suggestions on designing for low power which are applicable
to all devices. Even simple things such as minimizing current drain through pull-up resistors can
add up to real power savings.
Additional power saving techniques while in D0 are also encouraged as long as they are
transparent to the operating system.

AP P E N D IX - A
7 . SP E C IAL CYC L E M E S S AGE S

Special cycle message encodings are defined in this appendix. The current list of defined encodings
is small, but it is expected to grow. Reserved encodings should not be used.
7.1 Message Encodings

CAD[15::0] Message Type
0000H SHUTDOWN
0001H HALT
0002H x86 Architecture Specific
0003H Ñ FFFFH Reserved
SHUTDOWN is a broadcast message indicating the processor is entering into a shutdown mode.
HALT is a broadcast message from the processor indicating it has executed a halt instruction.
The x86 Architecture Specific encoding is a generic encoding for use by x86 processors and chipsets.
CAD[31::16] determine the specific meaning of the special cycle message. Specific meanings are
defined by Intel Corporation and are found in product specific documentation.
7.2 Use of Specific Encodings

Use or generation of architecture-specific encodings is not limited to the requester of the encoding.
Specific encodings may be used by any vendor in any system. These encodings allow system
specific communication links between cooperating CardBus PC Card devices for purposes which
cannot be handled with the standard data transfer cycle types.

AP P E N D IX - B
8 . CAR D BU S PC CAR D CON N E C T OR TE S T

M E T H OD OL OGY
This appendix outlines a methodology which may be used to quantify the effect CardBus PC Card
and host connectors have on system noise levels. Connectors used for CardBus PC Card
implementations shall provide sufficient signal ground return paths to support 33 MHz operation.
The CardBus PC Card Electrical Specifications defines the criteria for 33 MHz operation, including
maximum ground bounce noise for the interface.
8.1 Background
There are many factors which contribute to overall signal quality and integrity across the CardBus
PC Card interface, of which the CardBus PC Card connector is one of the most significant. In
addition to the connector, several other factors may influence signal integrity across the interface.
These include:
1. The quality of local and bulk decoupling on the host system and CardBus PC Card.
2. The output edge rate transmitted across the interface.
3. The frequency of operation.
4. The number of outputs switching simultaneously.
In order to understand the effect of any one variable in a system the effect of other variables must
be minimized. The focus of this procedure is on the connector alone. This does not diminish the
importance of the other factors listed above, it just allows for a concise test procedure to be
documented for the connector. This procedure or methodology, in conjunction with in-system
testing, is intended to provide connector manufacturers with a standard for evaluation of their
product performance.
8.2 Test Hardware Recommendations

This section defines the test hardware recommended for evaluation of the CardBus PC Card
connector system. The CardBus PC Card connector system is comprised of a mated pair of CardBus
PC Card connectors as specified by the Physical Specification. The test hardware for this system
includes the connectors, mounting boards, interface circuitry and test/measurement equipment
necessary to perform the evaluation. The test hardware should provide sufficient flexibility to meet
the recommendations defined in this appendix.
8.2.1 General Recommendations

1. The test system should be on a stable platform and be capable of repeatable noise
measurements.
2. The design impedance of the boards should be matched to the CardBus PC Card drivers chosen,
75 ohms is typical.

CARDBUS PC CARD CONNECTOR TEST METHODOLOGY
8.2.2 Host-side Requirements

1. The power source should develop a clean VCC at voltages from 3.0 to 3.6 volts and have a
current rating of at least one ampere.
2. The test board should be capable of switching at least 45 outputs simultaneously into each
CardBus PC Card socket.
3. The test board should be capable of both driving and receiving signals.
4. It should be possible to measure ground bounce and VCC droop at all test points.
5. The output edge rate seen at the connector should be the maximum allowed by the CardBus PC
Card specification.
6. It is recommended that series damping resistors be used to tune edge rates across the interface.
7. Either on or off board signal generation capable of 33 MHz speeds should be provided to drive
the CardBus PC Card interface I/O devices.
8. Test board construction and design should be consistent with current mobile computer
methodology.
8.2.3 Card-side Recommendations

1. The test board should be capable of driving or receiving at least 45 signals simultaneously.
2. It should be possible to measure ground bounce and VCC droop at all test points.
3. The output edge rate seen at the connector should be the maximum allowed by the CardBus PC
Card specification.
4. It is recommended that series damping resistors be used to tune edge rates across the interface.
5. Either on or off board signal generation capable of 33 MHz speeds should be provided to drive
the CardBus PC Card interface I/O devices.
6. Test board construction and design should be consistent with current PC Card methodology.
7. The card boards should be capable of being stacked to accommodate 2 card vertical socket
arrangements.
8.2.4 Measurement Equipment Recommendations

The following test equipment considerations are recommended to support the test and measurement
activities:
Probe: Active FET probe 1.5 pF, 10X, 1 Megohm impedance
Probe GND: Less than 1" in length
Oscilloscope: HP54100 (or equivalent) Digitizing at 1 Gsample/S
8.3 Test Board Considerations

This section provides block diagram layouts for both test boards and identifies the major attributes
of each. The board layouts and features of each are provided as examples of a functional test setup.
Individual adaptations and variations are acceptable as long as the results produced are comparable
to those achievable with the described setup.

8.3.1 Host-side Implementation

The following features are descriptive of the test board used for the host side of the test setup
(reference Figure B-1: Host-side Test Board Layout):
• Surface mount series resistance on all signal lines.
• Utilizes HP8180, or equivalent, word generator to drive I/O devices.
• Test points designed to accommodate 1 GHz FET probe.
• Maximum capacitive decoupling provided at the connector, the power source, and for every
device.
• Matched trace lengths for simultaneous switching experimentation.
• Utilizes 16245, or equivalent, I/O drivers (24 mA output drive)
• Word wide control over OE# signals, allows for varied number of outputs switching.
• No vias between device pins and connector pins to maintain trace impedances which are
designed for 75 ohms.
• Corner mounting holes provide for sturdy platform mounting.
• Three (3) pin headers allow for static high or low noise measurements at each test point.
• Crosstalk measurement points may be terminated or unterminated.
• Eight (8) 16245, or equivalent, devices allow for greater than 45 outputs switching into each
socket at the same time.
I/O DRIVERS
I/O DRIVER POWER SUPPLY
DATA INPUT
CardBus PC Card
GROUND BOUNCE
MEASUREMENT
I/O DRIVER
DATA MONITOR
GROUND BOUNCE
MEASUREMENT
I/O DRIVER
TRANSMIT/RECEIVE
CARD 0 AND 1
GROUND BOUNCE
MEASUREMENT
I/O DRIVER Connector
GROUND BOUNCE
CONTROL
SERIES RESISTOR TERMINATION

I/O DRIVERS – AS REQUIRED
Figure 8Ð1 Host-side Test Board Layout

CARDBUS PC CARD CONNECTOR TEST METHODOLOGY
8.3.2 Card-side Implementation

The following features are descriptive of the test board used for the card side of the test setup (See
Figure 8Ð2 Card-side Test Board Layout.):
• Surface mount series resistance on all signal lines.
• Utilizes HP8180 or equivalent word generator to drive I/O devices.
• Test points designed to accommodate 1 GHz FET probe.
• Maximum capacitive decoupling provided at the connector and for every device.
• Matched trace lengths for simultaneous switching experimentation.
• Utilizes TI VHC245, or equivalent, I/O drivers (8 mA output drive)
• Byte-wide control over OE# signals, allows for varied number of outputs switching.
• No vias between device pins and connector pins to maintain trace impedances. which are
designed for 75 ohms
• Corner mounting holes provide for sturdy platform mount and board stacking capability.
• Three (3) pin headers allow for static high or low noise measurements at each test point.
• Crosstalk measurement points may be terminated or unterminated.
• Eight (8) TI VHC245, or equivalent, devices allow for greater than 45 outputs switching.
I/O DRIVERS
I/O DRIVER
DATA INPUT
CardBus PC Card
GROUND BOUNCE
MEASUREMENT
I/O DRIVER
DATA MONITOR
GROUND BOUNCE
MEASUREMENT
I/O DRIVER
TRANSMIT/RECEIVE
CARD 0 AND 1
GROUND BOUNCE
MEASUREMENT
I/O DRIVER
Connector GROUND BOUNCE
CONTROL
SERIES RESISTOR TERMINATION

– AS REQUIRED
I/O DRIVERS
Figure 8Ð2 Card-side Test Board Layout

8.4 Measurement Methodology

The ground bounce measurements should always be taken in reference to the "local" ground. This
"local" reference gives an accurate picture of what the receiving devices will "see" and respond to in
a system. In a two card vertically mounted host system, four singular Card-Host driver-receiver
pairings are possible, as follows:
Driver Receiver
Host Card 0
Host Card 1
Card 0 Host
Card 1 Host
8.4.1 Finding the Worst Case Ground Bounce

The technique for finding a "worst case" is simply to try all available alternatives and use the
measurement point that provides the highest ground bounce measurement. The most important
aspect of this is in the design of the test system itself. The test system should provide multiple
ground bounce test points positioned as far away as possible from connector power and ground
pins.
Host Conditions: Card conditions:
VCC = 3.6 V VCC = 3.6 V
Frequency = 1 MHz Frequency = 1 MHz
To find worst case ground bounce, all driver devices should be enabled. Then the data timing is
adjusted so all outputs are actively switching simultaneously at frequency. In this configuration, the
test system is supporting at least 45 outputs switching across the CardBus PC Card interface. Ground
bounce data may then be taken at each test point.
This technique may then be applied to each of the four singular combinations above. A true worst
case may be found by applying the two worst singular conditions for Cards 0 and 1 simultaneously
across the vertical CardBus PC Card connector and measuring as before. Now that the worst case
measurement point has been located, the frequency may be ramped to 33 MHz and the ground
bounce monitored to ensure proper operation to the maximum CardBus PC Card system frequency.

AP P E N D IX - C
9 . PC CAR D CU S T OM I N T E R F AC E S
9.1 Custom Interface Requirements

The features and capabilities of specific custom interfaces are described in this appendix. (See also
4.3.5 Custom Interfaces.) This section, 9.1 and its subordinates, list the headings and describe the
contents of each paragraph required.
The title of paragraph 9.x, where x is two (2) and above, is the name for the custom interface
followed by the custom interface identification number in parenthesis. For example, Ò9.2 ZV Port
(0141H).Ó
9.1.1 Purpose/Overview
Describe the custom interface giving the primary purpose and an operational overview of the
interface.
9.1.2 Compatibility
The addition of support for a custom interface does not relax any requirement in both the host and
the card associated with 16-bit PC Cards or CardBus PC Cards. PC Cards not using a custom
interface shall not be adversely affected by the presence or state of a custom interface capability
anywhere in the host.
Describe signals not available to cards using the custom interface while the custom interface is
enabled. For example, a custom interface that redefines the SPKR# signal does not allow a PC Card
to use the optional 16-bit PC Card Binary Audio signal.

Describe all pin assignments.
9.1.4 Features
Describe the features of the custom interface. As an example: ÒThis interface supports random access
to 16 Bytes of memory address per memory space using signals A[3::0].Ó
9.1.5 Signal Description

Describe each signal as used while the custom interface is active. Identify each custom interface
signal under one of four classifications: I (Input), O (Output), I/O (Bi-directional), and R (Reserved).
Input signals are driven by the host and output signals are driven by the card.

PC CARD CUSTOM INTERFACES
9.1.6 Functions
Describe the functions for any and all address spaces available while the custom interface is active.
9.1.7 Timing
Describe the access timing for any and all address spaces available while the custom interface is
active.
9.1.8 Electrical Interface

Identify the characteristics of the electrical interface while the custom interface is active. Include logic
levels and address decoding mechanisms in describing the electrical interface.
9.1.9 Specific Signals and Functions

Provide further discussion, as needed, of specific signals and functions available while the custom
interface is active.

9.2 ZV Port Custom Interface (0141H)

The ZV Port is a single-source uni-directional video bus between a PC Card socket 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. The ZV Port also uses an industry
standard mechanism for transferring digital audio PCM data to a low cost DAC for conversion to an
analog signal.
9.2.1 Overview
The following diagram shows the system level concept of the ZV Port. The diagram demonstrates
how TV in a window could be achieved in a portable computer with a low cost PC Card. An MPEG,
or a teleconferencing card could also be plugged into the PC Card slot.
TV LCD CRT
SPEAKERS
256Kx16
PCI DRAM
Local Bus
Analog
Encoder
Amp
VGA Audio
Codec PC Card Slot
PC Card
PCM
ZV Port
Audio 4 Audio
(Video) 19 Input
PCM
4 Converter Audio
PC Card
Host PC Card
Adapter Interface Video Video
Decoder
NTSC/PAL
Motherboard 19 RF Signal
Video & Control
Figure 9-1 Example ZV Port Implementation
9.2.2 Compatibility
The addition of support for the ZV Port interface does not relax any requirement associated with 16-
bit PC Cards or CardBus PC Cards in either the host or the card. PC Cards not using the ZV Port
interface shall be unaffected by the presence or state of the ZV Port interface capability anywhere in
the host.
PC Cards implementing the ZV Port interface shall present the 16-Bit PC Card memory only
interface following the application of VCC or the RESET signal. When either the 16-Bit PC Card
memory only interface or the ZV Port interface is active the card shall support direct access to 16

Bytes (signals A[3::0]) of attribute and common memory space and provide access to two 64 Mbyte
indirect memory spaces using registers in common memory. (See 4.16 Indirect Access to PC Card
Memory.) Direct access to any address beyond the first 16 Bytes of attribute or common memory is
undefined.
16-bit PC Card DMA operation shall not be supported in a socket when the ZV Port interface is
active because the entire set of pins over which the DREQ# signal can be routed, SPKR#,
INPACK# or IOIS16#, are in use.
The I/O Is 16 Bit Port (IOIS16#) signal is not available when the ZV Port interface is active. PC
Cards supporting I/O operations while using the ZV Port interface shall indicate eight or 16 bit I/O
access via the TPCE_IO field in the CISTPL_CFTABLE_ENTRY tuple.
The Input Port Acknowledge (INPACK#) signal is not available when the ZV Port interface is
active.
The Audio Digital Waveform (SPKR#) signal is not available when the ZV Port interface is active;
digital audio PCM is provided. (See 9.1.9 Specific Signals and Functions.)The Battery Voltage Detect
2 (BVD2) signal may be available in the cardÕs Pin Replacement register while the ZV Port
interface is active. (See 4.15.3 Pin Replacement Register.)


The following table shows the function of various PC Card signals when the ZV Port custom
interface mode is set in the PC Card Host Adapter. PC Card signals not mentioned in the table
below, remain unchanged from the 16-bit PC Card I/O and Memory interface.
Table 9-1 ZV Port Interface Pin Assignments

PC Card I/O and Memory I/O and ZV Port ZV Port Comments
Pin Interface Signal Memory Interface Signal I/O 1
Number Name I/O 1 Name
8 A10 I HREF O Horizontal Sync to ZV Port
10 A11 I VSYNC O Vertical Sync to ZV Port
11 A9 I Y0 O Video Data to ZV Port YUV:4:2:2 format
19 A16 I UV2 O Video Data to ZV Port YUV:4:2:2 format
22 A7 I SCLK O Audio SCLK PCM Signal
23 A6 I MCLK O Audio MCLK PCM Signal
24::25 A[5::4] I RESERVED RFU Put in three state by Host Adapter
No connection in PC Card
26::29 A[3::0] I ADDRESS[3::0] I Used for accessing PC Card
33 IOIS16# O PCLK O Pixel Clock to ZV Port
60 INPACK# O LRCLK O Audio LRCLK PCM signal
62 SPKR# O SDATA O Audio PCM Data signal
After HREF has started, the transfer of UV data always starts with the U component.
UV[7::0] starts with U[7::0] at the first pixel of the line, then V[7::0], then U[7::0], É

The following diagram shows the PC Card socket and the location of the signals that carry
video/audio signals when the PC Card and the Host Adapter are in ZV Port mode. This diagram
shows the rationale behind selecting these signals to maintain signal integrity and minimize noise.
1 35
2 36
GND GND
HREF
VSYNC
Y0 Y1
Y2
Y4
Y3
Y6 Y5
Y7
UV0
VCC VCC
VPP VPP
UV2 UV1
UV4 UV3
UV6
UV5
(SCLK) A7
UV7
(MCLK) A6
Reserved
A3 INPACK# (LRCLK)
A2
A1 SPKR# (SDATA)
A0
67
33 34 68
PCLK
GND GND
Figure 9-2 ZV Port Signals on PC Card Socket

9.2.4 Features
In the ZV Port interface mode, most of the host adapter control signals and data bus follow the same
data path to the card as it would for any other 16-bit PC Card in I/O and Memory mode. The
primary difference is that the address signals A[25::4] are put in three state by the PC Card Host
Adapter thereby restricting the Common Memory space address range to sixteen bytes and the
Attribute Memory space address range to eight valid bytes. The unused address pins are used to
define the 19 pin ZV Port data bus, control signals, and 4 wire digital audio interface.
Because ZV Port restricts PC Card memory access to four address lines, A[3::0], cards implementing
the ZV Port interface will also implement indirect memory access. (See 4.16 Indirect Memory Access
and see also the Metaformat Specification.)

This section describes the signal definitions of ZV Port. When the ZV Port custom interface is
selected in the PC Card Host Adapter, address lines A[25::4] to the PC Card are either put in three
state by the Host Adapter or become inputs to the Host Adapter. The address lines A[25::4],
BVD2/SPKR# and INPACK# signals are then replaced by ZV Port signals which carry
video/audio data from the PC Card to the ZV Port.
The ZV Port interface has the following unique signals detailed in the sections below.
9.2.5.1 PCLK
This signal is used to clock valid data and HREF signal into the ZV Port. The maximum rate is 16
MHz. During display time, rising edge of PCLK is used to clock the 16-bit pixel data into the ZV
Port.
9.2.5.2 VSYNC
This signal supplies the vertical synchronization pulse to the ZV Port that displays the video data.
9.2.5.3 HREF
This signal supplies the horizontal synchronization pulse to the ZV Port that displays the video
data.
9.2.5.4 Y[7::0]
These signals are 8 bits of luminance data that are input to the ZV Port from the PC Card.
9.2.5.5 UV[7::0]
These signals are the 8 bits of chrominance data that are input to the ZV Port from the PC Card.
9.2.5.6 LRCLK
This signal determines which audio channel (left/right) is currently being input on the audio Serial
Data input line. LRCLK is low to indicate the left channel and high to indicate the right channel.
Supported sample frequencies are shown in section 9.2.5.9 MCLK. For an MCLK frequency of 384Fs
the LRCLK to SCLK ration must be 48. For an MCLK frequency of 256Fs the LRCLK to SCLK ration
must be 32.

9.2.5.7 SDATA
This signal is the digital PCM signal that carries the audio information. Digital audio data is
transferred using the I2S format.
I2S Format
The I2S formats are shown below. The digital audio data is left channel-MSB justified to the high-to-
low going edge of the LRCLK plus one SCLK delay.
LRCLK Left Channel Right Channel
SCLK
SDATA 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Figure 9-3: 1A I2S Format - MCLK = 256fs
LRCLK Left Channel Right Channel
SCLK
SDATA 23 22 21 20 19 18 17 16 15 14 1312 11 10 9 8 7 6 5 4 3 2 1 0 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Figure 9-4: 1B I2S Format - MCLK = 384fs
9.2.5.8 SCLK
This signal is the serial digital audio PCM clock.
9.2.5.9 MCLK
This signal is the Master clock for the digital audio. MCLK is asynchronous to LRCLK, SDATA
and SCLK.
The MCLK must be either 256x or 384x the desired Input Word Rate (IWR). IWR is the frequency at
which words for each channel are input to the DAC and is equal to the LRCLK frequency. The
following table illustrates several standard audio word rates and the required MCLK and LRCLK
frequencies.
The ZV Port audio DAC should support a MCLK frequency of 256 times and 384 times the input
word rate. This results in the frequencies shown below.
LRCLK (Hz) SCLK (MHz) MCLK (MHz)

Sample Frequency 32xfs 256x
22050 0.7056 5.6448

32000 1.0240 8.1920
44100 1.4112 11.2896
48000 1.5360 12.2880

LRCLK (Hz) SCLK (MHz) MCLK (MHz)

Sample Frequency 48xfs 384x
22050 1.0584 8.4672

32000 1.5360 12.2880
44100 2.1168 16.9344
48000 2.3040 18.4320
9.2.6 Functions
There are no changes to the functions of the Common Memory and Attribute Memory areas when
the ZV Port custom interface mode is set in the PC Card Host Adapter. (See 4.6 Memory Function.)
The PC Card shall support direct access to 16 Bytes (signals A[3::0]) of attribute and common
memory space and provide access to two 64 Mbyte indirect memory spaces using registers in
common memory. (See 4.16 Indirect Access to PC Card Memory.) Direct access to any address
beyond the first 16 Bytes of attribute or common memory is undefined.
DMA Signals shall not replace I/O Interface Signals on a socket when the ZV Port custom interface
mode is set in the PC Card Host Adapter for that socket.
9.2.7 Timing
9.2.7.1 Video Interface Timing

The following timing diagram depicts the relationship amongst the ZV Port signals. The associated
video interface timing table shows the AC parameters associated with the ZV Port signals when the
ZV Port custom interface is in use.
Even Field Odd Field

VSYNC
t8 t8
HREF
t6 t7
t5
PCLK
t1 t2 t3 t4
t6 t7
Y[7:0] / UV[7:0] 0 1 2 3 END
Figure 9-5 Video Interface Timing

Table 9-2 AC Parameters for Video Signals

Symbol Parameter Minimum Maximum
t1 PCLK fall time 4 ns 8 ns
t2 PCLK low time 20 ns
t3 PCLK rise time 4 ns 8 ns
t4 PCLK high time 20 ns
t5 PCLK cycle time 62.5 ns
t6 Y[7::0] / UV[7::0] / HREF setup time 30 ns
t7 Y[7::0] / UV[7::0] / HREF hold time 10 ns
t8 VSYNC setup / hold time to HREF 100 ns
Note: All video signals have a minimum rise and fall time of 4 ns and a maximum rise and fall time of 8 ns.
Non-interlaced data asserts VSYNC at the Odd Field timing.
9.2.7.2 Audio Interface Timing
LRCLK
tslrs
tslrd t sclkl tsclkh
SCLK
tsdlrs tsdh
SDATA
Figure 9-6 Audio Interface Timing
Table 9-3 AC Parameters for Audio Signals

SYMBOL PARAMETER MIN
tslrd LRCLK delay 2ns
tslrs LRCLK setup 32ns
tsclkl bit clock low 22ns
tsclkh bit clock high 22ns
tsdlrs data setup 32ns
tsdh data hold 2ns

PC Card logic levels are unchanged when the ZV Port custom interface mode is set in the PC Card
Host Adapter. (See 4.9.1 Signal Interface and Table 4-18 PC Card Logic Levels.)

Table 9-4 ZV Port Electrical Interface

Item Signal Card Host
ZV Port Signals PCLK The card shall be able to drive a The host shall present
VSYNC load of 50 pF at a DC current of 4 a load of no more than
HREF mA in the low state and 700 µA in 50 pF at a DC current
Y[7::0] the high state. of 4 mA in the low state
UV[7::0] and 700 µA in the high
LRCLK state.
SDATA
SCLK
MCLK

The specific signals and functions of the ZV Port interface are discussed in the previous sections.
9.2.10 PC Card Connector Test Methodology

This section notes changes in test methodology that should be observed when quantifying the effect
of a ZV Port interface on system noise levels in a CardBus capable host. (See Appendix B: 8.
CardBus PC Card Connector Test Methodology.)
The testing methods outlined in the appendix are the same, the test conditions are different. In
addition to testing with the forty-five (45) CardBus signals that operate at 3.0 to 3.6 volts and a
frequency of 33 MHz, the forty-five (45) ZV signals are added to the Host-side and Card-side test
requirements. The ZV Port interface also operates at 5 volts in addition to the 3.3 volt signaling
environment used in CardBus and ZV has twenty-three (23) signals at 16.6 MHz and twenty-two
(22) signals at 5.5 MHz.
Worst case ground bounce evaluation is expanded to include the ZV Port interface active at
maximum VCC (5.25 volts) and interactions with the forty-five (45) ZV signals.
The ZV Port interface in a CardBus PC Card capable host may be implemented using stubbed
signal traces when the stubs are short avoiding transmission line effects; any stub shall have a
maximum length of 2 inches (50.8 mm). (See Figure 9-7 Host-side Test Board Layout.) Note that a
stubbed implementation allows vias between device pins and connector pins.

I/O DRIVERS INPUT BUFFER

I/O DRIVER
DATA INPUT
I/O DRIVERS
GROUND BOUNCE
MEASUREMENT
I/O DRIVER
DATA MONITOR
GROUND BOUNCE
MEASUREMENT
I/O DRIVER
TRANSMIT/RECEIVE
CARD 0 AND 1
STACKED
GROUND BOUNCE CARDBUS
MEASUREMENT CONNECTOR
I/O DRIVER
GROUND BOUNCE
CONTROL
SERIES RESISTOR TERMINATION MIXED VOLTAGE

I/O DRIVERS – AS REQUIRED POWER SUPPLY
Figure 9-7 Host-side Test Board Layout

9.3 DVB CI Port Custom Interface (0241h)

The DVB CI port is a bi-directional video and audio bus and a command control interface based on
the PC Card socket providing a DVB (Digital Video Broadcasting, European TV Standardization
body) compliant Conditional Access System built into a PC Card or a PC Card adapter module. The
module complements an IRD host system (Integrated Receiver Decoder) for receiving digital
encoded and scrambled TV applications. The Port complies with the specifications of EN 50221
(CENELEC) laid out for timing of the interface to allow DVB compliant decoders to daisy chain
scrambled data and to deliver unscrambled real-time MPEG-2 transport data streams straight into
the de-multiplexing and MPEG decoding process of the IRD.

9.3.1 Overview
The IRD receiver for Digital Video Broadcasting services receives a digital data multiplex,
structured according to the MPEG-2 specifications. Digital video data are received from a satellite
transponder, a cable system, from terrestrial transmitters or from telecommunications network.
After error correction this multiplex is fed via a descrambler, to recover scrambled services, to a de-
multiplexer where the desired services - video, audio and data - are extracted and fed to the
appropriate host decoder referred to as 'host' because of the variety of possible platforms which may
perform these operations. In the model of this process the descrambler and its associated control
functionality reside on a PC Card module which communicates with the host by means of the DVB
Common Interface which is defined on the PC Card physical layer as the DVB CI Port. The
following block diagrams shows the system level concept of the DVB CI Port integrated into an IRD
host environment and demonstrate how a DVB Conditional Access is operated in principal for
receiving data streams.
RGB Out
RF In
Tuner Demodulator MPEG Decoder
Audio Out
Microprocessor Verifier Demultiplexer

Remote
Host
Scrambled Descrambled Common Interface

Control Transport Stream Transport Stream
Descrambler
Microprocessor
Verifier
Module
Smart
Card
(Optional)
Figure 9-8: Example DVB CI Port Implementation

Two logical interfaces, to be included on the same physical interface, are defined. The first interface
is the MPEG-2 Transport Stream. The link and physical layers are defined in the Common Interface
specification of EN 50221 and the higher layers are defined by MPEG. The second interface, the
command interface, carries commands and data between the host and the module. Six layers are
defined in the Common Interface specification for this interface.
Note that a host can support more than one instance of this interface. In this case the MPEG-2
Transport Stream interface is daisy-chained through all DVB CI sockets, as shown in Figure 9-9, and
each command interface is a separate logical connection to the host.

Host
CA module 1
CA module 2
CA module n
Figure 9-9: Transport Stream Interface Chaining between Modules
9.3.2 Compatibility
The addition of support for the DVB CI Port interface does not relax any requirement associated with
16-bit PC Cards or CardBus PC Cards in either the host or the card. However in case the host is not
capable of operating with PC Cards in a non-custom interface mode the card shall be gracefully
rejected by the host. PC Cards not using the DVB CI Port interface shall be unaffected by the
presence or state of the DVB CI Port interface capability anywhere in the host.
PC Cards implementing the DVB CI Port interface shall present the 16-bit PC Card memory only
interface following the application of VCC or the RESET signal. When either the 16-bit PC Card
memory only interface or the DVB CI Port interface is active the card shall support direct access to 8
kBytes (signals A[13::0]) of attribute memory. Access to any address beyond the first 8 kBytes of
attribute or common memory is possible by indirect addressing.
When operating in this configuration D[7::0] are retained as a byte-oriented I/O port, and the
capability to read the Attribute Memory is retained.
In DVB Common Interface Specification only two address lines are required for four Bytes of register
space, but address lines A[13::0] are available to address Attribute Memory, if required. IOIS16# is
never asserted and the module ignores CE2#.
The Audio Digital Waveform (SPKR#) and the Status Changed (STSCHG#) signals are not
available when the DVB CI Port custom interface mode is active. BVD1 and BVD2 shall remain
ÓhighÓ, the CE2# signal shall be ignored and interpreted by the module as always being in the
ÓhighÓ state. The IOIS16# signal is never asserted.


The following table shows the function of various PC Card signals when the DVB CI Port custom
interface mode is set in the PC Card Host Adapter. PC Card signals not mentioned in the table
below, remain unchanged from the 16-bit PC Card I/O and Memory interface.
Table 9-5: DVB CI Port Interface Pin Assignments

PC Card I/O and Memory I/O and DVB CI Port DVB CI Port Comments
Pin Interface Signal Name Memory Interface Signal I/O1
Number I/O1 Name
56 A25 I MDI7 I MPEG Data In 7
46 A17 I MISTRT I MPEG Data In Start
19 A16 I MIVAL I MPEG Data In Valid
20 A15 I MCLKI I MPEG Data Clock Input
14 A14 I MCLKO O MPEG Data Clock Output
41 D15 I/O MDO7 O MPEG Data Out 7
63 BVD1 O MOSTRT O MPEG Data Out Start
62 BVD2 O MOVAL O MPEG Data Out Valid

The following diagram shows the PC Card socket and the location of the signals that carry digital
video-audio I/O-signals when the PC Card and the Host Adapter are set to the DVB CI Port custom
interface mode.
1 35
2 36
GND GND
MDO3
MDO4
MDO5 MDO6
MDO7
MISTRT
MCLKO
MDI0
MDI1
MDI2
MDI3
VCC VCC
VPP VPP
MIVAL MDI4
MCLKI MDI5
MDI6
MDI7
SPKR# (MOVAL)
MOSTRT MDO0
MDO1
MDO2
67
33 34 68
PCLK
GND GND
Figure 9-10: DVB CI Port Signals on PC Card Socket
9.3.4 Features
In the DVB CI Port custom interface mode, most of the host adapter control signals and data bus
follow the same signal path to the card as they would for any other 16-bit PC Card in I/O and
Memory mode. The primary difference is that the address signals A[25::14] and the data signals
D[15::8] are used by the PC Card Host Adapter thereby restricting the Common Memory space
(optional) address range to 16 kBytes and the Attribute Memory space address range to 8k valid
Bytes (8 bit even access only).


This section describes the signal definitions of DVB CI Port. When the DVB CI Port custom interface
mode is selected in the PC Card Host Adapter, address lines A[25::14] to the PC Card are put in
high impedance state by the Host Adapter. The address lines A[25::14], the data lines D[15::8],
BVD1/STSCHG# and BVD2/SPKR# signals are then replaced by DVB CI Port signals which carry
video-audio data to and from the PC Card to the DVB CI Port.
The Port interface has the following unique signals detailed in the sections below.
9.3.5.1 MDI[7::0]
This is the MPEG data input to the module. It utilizes the pins assigned to A[25::18].
9.3.5.2 MISTRT
This signal is active to indicate the first Byte of a MPEG Transport packet on MDI[7:0]. It uses the
pin assigned to A17.
9.3.5.3 MIVAL
This signal is active to indicate valid Bytes on MDI[7:0]. It uses the pin assigned to A16. As the
interface is clocked continuously, there is a need to indicate when valid data is present, as the way
the input is generated within the host means that there may be periods of non-valid data between
or even within MPEG Transport packets.
9.3.5.4 MDO[7::0]
This is the MPEG Transport data output from the module. It uses the pins assigned to D[15::8].
9.3.5.5 MOSTRT
This signal is active to indicate the first Byte of a MPEG Transport packet on MDO[7::0]. It uses the
pin assigned to BVD1.
9.3.5.6 MOVAL
This signal is active to indicate valid Bytes on MDO[7::0]. It uses the pin assigned to BVD2.
9.3.5.7 MCLKI
This signal is a continuously running clock input to the module during the period when the
interface is in this particular configuration. It clocks the MPEG Transport data into the module. It
uses the pin assigned to A15. The timing relationship between MCLKI and the input signal is
shown in Figure 9-11 and the timing limits are given in Table 9-6.
9.3.5.8 MCLKO
This signal is a continuously running clock output from the module during the period when the
interface is in this particular configuration. It clocks the MPEG Transport data out of the module. It
uses pin 14, assigned to A14. The timing relationships between MCLKO and the output signal is

shown in Figure 9-11 and the timing limits are given in Table 9-6. MCLKO may be a delayed copy
of MCLKI but it could also be an entirely different clock signal with no relationship with MCLKI.
9.3.6 Functions
There are no changes to the functions of the Attribute Memory areas when the DVB CI Port custom
interface mode is set in the PC Card Host Adapter. (See 4.6 Memory Function.) The PC Card shall
support direct access to 8 kBytes (signals A[13::0]) of attribute memory space and shall support
access to any address beyond the first 8 kBytes of attribute or common memory by indirect
addressing.
When operating in this configuration D[7::0] are retained as a byte-oriented I/O port, and the
capability to read the Attribute Memory is retained. Since the DVB CI Port custom interface is 8 bit
only interface the Attribute Memory Bytes are at consecutive even addresses (0,2,4, etc.).
DMA Signals shall not replace I/O Interface Signals on a socket when the DVB CI Port custom
interface mode is set in the PC Card Host Adapter for that socket. Common Memory space support
in the host is optional. There are changes to the functions of the I/O accesses. DVB CI Modules shall
use an independent I/O address window of 4 Bytes in space starting at address Ó00HÓ.
9.3.7 Timing
Transport Stream Interface Timing
The following timing diagram depicts the relationship for Transport Stream Interface signals Table
9-6 shows the AC parameters associated with the DVB CI Port signals when the DVB CI Port custom
interface is in use.

tclkp
tclkh
MCLKI
tsu th
tclkl
MDI [7::0],
MDI, MISTRT,
MISTRT MVAL
MIVAL
tclkp
tclkh
MCLKO
tclkl
tosu toh
MDO [7::0],
MDO, MOSTRT,
MOSTRT,
MOVAL MVAL
Figure 9-11: Transport Data Stream Interface Timing
Table 9-6: Timing Relationship Limits

SYMBOL PARAMETER MIN
tclkp Clock period 111 ns
tclkh Clock High time 40 ns
tclkl Clock Low time 40 ns
tsu Input Data Setup 15 ns
th Input Data Hold 10 ns
tosu Output Data Setup 20 ns
toh Output Data Hold 15 ns


PC Card logic levels are according to the specifications when the DVB CI Port custom interface mode
is set in the PC Card Host Adapter. (See 4.9.1 Signal Interface and Table 4-18 PC Card Logic
Levels.)

The specific signals of the DVB CI Port interface are addressed in the previous sections. Further
specifications addressing the operation and functions of a Conditional Access System and the
Command Interface hosted on the PC Card Module are laid down in the Standard of EN 50221.

Volume 3
Physical Specification
PCMCIA
JEIDA
+1-408-433-9558 (Fax) IMPORTANT:
+81-3-3433-1923 PCMCIA
and design are trademarks of JEIDA, EXPRESS OR IMPLIED, WITH
registered in Japan. RESPECT TO THE STANDARD,
INFRINGEMENT,
YOU ÒAS IS.Ó

PHYSICAL SPECIFICATION
CONTENTS
1. Introduction____________________________________________1
2. Related Documents _____________________________________3
3. Card Dimensions _______________________________________5
3.1 Write Protect Switch (WPS) ................................................................................................5
3.2 Battery Location ..................................................................................................................5
3.3 Labeling (Marking) ..............................................................................................................5
4. Connector______________________________________________7
4.1 Card Connector....................................................................................................................7
4.2 Host Connector....................................................................................................................7
5. PC Card Guidance ______________________________________9

6. Grounding/EMI Clips __________________________________11
6.1 Card/Ground Clip Contact Resistance Measurement Procedure ...................................11
6.1.1 Office Environment.................................................................................................................................................................1 2
6.1.2 Harsh Environment ................................................................................................................................................................1 2
6.1.3 Material Compatibility.........................................................................................................................................................1 2
7. Connector Reliability __________________________________13

7.1 Mechanical Performance....................................................................................................13
7.1.1 Office Environment.................................................................................................................................................................1 3
7.1.2 Harsh Environment ................................................................................................................................................................1 3
7.1.3 Total Insertion Force ..............................................................................................................................................................1 3
7.1.4 Total Pulling Force..................................................................................................................................................................1 3
7.1.5 Single Pin Pulling Force.........................................................................................................................................................1 4
7.1.6 Single Pin Holding Force ......................................................................................................................................................1 4
7.1.7 Single Socket Holding Force................................................................................................................................................1 4
7.1.8 Vibration and High Frequency...........................................................................................................................................1 4
7.1.9 Shock ............................................................................................................................................................................................1 5
7.1.10 Pin Connector Inverse Insertion .......................................................................................................................................1 5
7.2 Electrical Performance.......................................................................................................15

7.2.1 Contact Resistance (low level) ............................................................................................................................................1 5
7.2.2 Withstanding Voltage ...........................................................................................................................................................1 5
7.2.3 Insulation Resistance..............................................................................................................................................................1 5
7.2.4 Current Capacity......................................................................................................................................................................1 6
7.2.5 Insulation Material.................................................................................................................................................................1 6
7.2.6 Ground Return Inductance...................................................................................................................................................1 6

CONTENTS
7.3 Environmental Performance ..............................................................................................16

7.3.1 Operating Environment ........................................................................................................................................................1 6
7.3.2 Storage Environment .............................................................................................................................................................1 6
7.4 Environmental Resistance..................................................................................................17

7.4.1 Moisture Resistance................................................................................................................................................................1 7
7.4.2 Thermal Shock..........................................................................................................................................................................1 7
7.4.3 Durability (High Temperature)..........................................................................................................................................1 7
7.4.4 Cold Resistance ........................................................................................................................................................................1 7
7.4.5 Humidity (Normal Condition)...........................................................................................................................................1 7
7.4.6 Hydrogen Sulfide ....................................................................................................................................................................1 7
7.5 Approved Test Procedures ...............................................................................................18
8. Connector Durability __________________________________ 19

8.1 Office Environment............................................................................................................19
8.2 Harsh Environment............................................................................................................19
9. PC Card Environmental________________________________ 21
9.1 Reference Standards ..........................................................................................................21
9.2 Environmental Performance ..............................................................................................21
9.2.1 Operating Environment ........................................................................................................................................................2 1
9.2.2 Storage Environment .............................................................................................................................................................2 2
9.3 Environmental Resistance..................................................................................................22

9.3.1 High Storage Temperature...................................................................................................................................................2 2
9.3.2 Low Storage Temperature ...................................................................................................................................................2 2
9.3.3 High Operating Temperature..............................................................................................................................................2 2
9.3.4 Low Operating Temperature..............................................................................................................................................2 3
9.3.5 Thermal Shock..........................................................................................................................................................................2 3
9.3.6 Moisture Resistance................................................................................................................................................................2 3
9.3.7 Electrostatic Discharge .........................................................................................................................................................2 4
9.3.8 X-ray Exposure.........................................................................................................................................................................2 4
9.3.9 Ultraviolet Light Exposure..................................................................................................................................................2 4
9.3.10 Electromagnetic Field Interference.................................................................................................................................2 4
9.3.11 Card Inverse Insertion.........................................................................................................................................................2 5
9.3.12 Vibration and High Frequency ........................................................................................................................................2 5
9.3.13 Shock..........................................................................................................................................................................................2 5
9.3.14 Full-size PC Card Bend Test .............................................................................................................................................2 5
9.3.15 Small PC Card Bend Test...................................................................................................................................................2 6
9.3.16 Drop Test..................................................................................................................................................................................2 6
9.3.17 Full-size PC Card Torque Test .........................................................................................................................................2 6
9.3.18 Small PC Card Torque Test...............................................................................................................................................2 6
9.3.19 PC Card Warpage .................................................................................................................................................................2 7
9.3.19.1 Card Warpage.........................................................................................................................................................2 7
9.3.19.2 Method of Measuring Warpage.......................................................................................................................2 7
iv © 1999 PCMCIA/JEIDA
9.3.19.3 Recommended Value of Warpage Dimensions ..........................................................................................2 8

9.3.20 SRAM Data Retention .........................................................................................................................................................2 8
9.4 Approved Test Procedures ...............................................................................................29
10. PC Card Thermal Rating ______________________________31

10.1 Determination Using a Temperature Rise Method.........................................................31
10.1.1 Measuring the PC Card Temperature............................................................................................................................3 1
10.1.2 Procedure .................................................................................................................................................................................3 1
10.1.2.1 Thermal Rating vs. Temperature Rise............................................................................................................3 5
11. Figures ______________________________________________37
FIGURES
Figure 10-1: PC Card Thermal Environment Measurement Method...........................................32
Figure 10-2: Free Area Around Card Being Rated .......................................................................32
Figure 10-3: Location of Thermocouples - 5 Each Side................................................................33
Figure 10-4: Location of Thermocouples for Small PC Card - 5 Each Side ................................33
Figure 10-5: Thermal Rating vs. Temperature Rise......................................................................35
Figure 11-1: Grounding/EMI Clips Contact Resistance Measurement.......................................37
Figure 11-2: TYPE I PC Card Package Dimensions.....................................................................38
Figure 11-3: TYPE II PC Card Package Dimensions....................................................................40
Figure 11-4: Type III PC Card Package Dimensions ...................................................................41
Figure 11-5: Small PC Card Type I Package Dimensions............................................................42
Figure 11-6: Small PC Card Type II Package Dimensions ..........................................................43
Figure 11-7: Small PC Card Type III Package Dimensions.........................................................44
Figure 11-8: Type I PC Card (3D) ................................................................................................45
Figure 11-9: Type II PC Card (3D)...............................................................................................46
Figure 11-10: Type III PC Card (3D)............................................................................................46
Figure 11-11: Full-size PC Card Connector Socket ......................................................................48
Figure 11-12: Small PC Card Connector Socket ...........................................................................48
Figure 11-13: Full-size PC Card Pin/Socket Contact Length with Wipe....................................49
Figure 11-14: Small PC Card Pin/Socket Contact Length with Wipe.........................................49
Figure 11-15: Full-size PC Card Pin Connector............................................................................50
Figure 11-16: Small PC Card Pin Connector ................................................................................51
Figure 11-17: Full-size PC Card Host Connector, Pin Contacts..................................................52
Figure 11-18: Small PC Card Host Connector, Pin Contacts.......................................................53
Figure 11-19: Recommended Right Angle Connector PCB Footprint..........................................54
Figure 11-20: Recommended Straight Connector PCB Footprint ................................................54
Figure 11-21: Recommended Two Row Surface Mount Connector PCB Footprint ....................55
Figure 11-22: Recommended One Row Surface Mount Connector PCB Footprint .....................55
Figure 11-23: Full-size PC Card Guide Guidance ........................................................................56
Figure 11-24: Small PC Card Guide Guidance.............................................................................57
Figure 11-25: Connector Shock & Vibration Test Fixture.............................................................58
Figure 11-26: Electrostatic Discharge Test-1 Fixture ...................................................................58
Figure 11-27: Electromechanical Discharge Test-2 Fixture ..........................................................58
FIGURES
Figure 11-28: PC Card Shock and Vibration Test Fixture............................................................59

Figure 11-29: Full-size PC Card Bend Test Fixture......................................................................60
Figure 11-30: Small PC Card Bend Test Fixture ..........................................................................60
Figure 11-31: Full-size PC Card Torque Test Fixture ..................................................................61
Figure 11-32: Small PC Card Torque Test Fixture.......................................................................61
Figure 11-33: Warpage Measurement AÐInterconnect Area........................................................62
Figure 11-34: Warpage Measurement AÐSubstrate Area............................................................62
Figure 11-35: Warpage Measurement BÐThickness Measurements ............................................63
Figure 11-36: Warpage Measurement BÐMeasurements .............................................................63
Figure 11-37: Warpage Measurement BÐMeasurement Positions ...............................................64
Figure 11-38: Card Inverse Insertion Test Fixture........................................................................65
Figure 11-39: Card Inverse Insertion Push Block .........................................................................65
Figure 11-40: CardBus PC Card Recommended Connector Grounding Interface Dimensions..66
Figure 11-41: CardBus PC Card Recommended PCB Footprint.................................................67
Figure 11-42: CardBus PC Card Recommended Host Connector Grounding Interface
Dimensions ........................................................................................................................68
Figure 11-43: CardBus PC Card Recommended Right Angle PCB Footprint.............................68
Figure 11-44: CardBus PC Card Recommended Right Angle PCB Footprint (Stacked) ............69
Figure 11-45: CardBus PC Card Reference Shrouded Connector................................................70
Figure 11-46: CardBus PC Card Reference Shrouded Connector (Stacked Connector)..............71
Figure 11-47: Contact Resistance Measurement...........................................................................72
viii © 1999 PCMCIA/JEIDA

TABLES
Table 4-1: Host Connector Pin Configuration ................................................................................7
This section of the specification defines the PC CardÕs physical outline dimensions, connector system
and qualification test parameters for 5 volt, low voltage, Small PC Card, and CardBus PC Card
applications. The tests specified in the Connector Reliability Section, Connector Durability, and PC
Card Environmental Sections are the minimum parameters which must be met. Note that these tests
apply to all PC Cards, including Small PC Card, unless a different test is specified for a specific card.
Each manufacturer is responsible for qualification of their own products to this specification.
The CardBus PC Card interface requires the use of a grounded shroud CardBus PC Card connector
or PCMCIA/JEIDA approved equivalent for all CardBus PC Card applications.
INTRODUCTION
2 © 1999 PCMCIA/JEIDA
2 . R E L AT E D D O C U M E N T S
The following documents which comprise the PC Card Standard:
PC Card Standard Release 7.0 (February 1999), PCMCIA/JEIDA
Volume 1. Overview and Glossary
Volume 2. Electrical Specification
Volume 3. Physical Specification
Volume 4. Metaformat Specification
Volume 5. Card Services Specification
Volume 6. Socket Services Specification
Volume 7. Media Storage Formats Specification
Volume 8. PC Card ATA Specification
Volume 9. XIP Specification
Volume 10. Guidelines
Volume 11. PC Card Host Systems Specification
MIL-STD-202F, Military Standard, Test Methods for Electronic and Electrical Component Parts,
U.S. Department of Defense
MIL-STD-1344A, Military Standard, Test Methods for Electrical Connectors, U.S. Department of
Defense
ANSI/UL 94-1979, Standard for Tests for Flammability of Plastic Materials for Parts in Devices
and Appliances, November, 1979
EIA-364-B, Electrical/Socket Test Procedures Including Environmental Classifications, August,
1990, Electronic Industries Association
RELATED DOCUMENTS
3 . CAR D DIME N S ION S

There are six types of PC Cards in this specification. Three types of full-size PC Cards: Type I, Type
II, and Type III, and three types of Small PC Cards: also Type I, Type II, and Type III.
Connector location and pin numbers for Type I, Type II, and Type III full-size PC Cards are shown
in Figure 11-2: TYPE I PC Card Package Dimensions, Figure 11-3: TYPE II PC Card Package
Dimensions, and Figure 11-4: Type III PC Card Package Dimensions. Connector location and pin
numbers for Type I, Type II, and Type III Small PC Cards are shown in Figure 11-5: Small PC Card
Type I Package Dimensions, Figure 11-6: Small PC Card Type II Package Dimensions, and Figure
11-7: Small PC Card Type III Package Dimensions.
PC Card polarization technique and dimensions are also shown in Figure 11-2, Figure 11-3, and
Figure 11-4 for full-size PC Cards, and in Figure 11-5, Figure 11-6, and Figure 11-7 for Small PC
Cards.
PC Cards must be opaque (non see-through).
U N L E S S O T H E R WIS E S P E C IF IE D , A L L D IME N S IO N S A R E
IN MIL L IME T E R S (MM). D IME N S IO N S S H O WN D O N O T
IN C L U D E WA R P A G E A L L O WA N C E S .
3.1 Write Protect Switch (WPS)

The WPS, if installed, shall be located at the locations shown in Figure 11-2, Figure 11-3, Figure 11-5
and Figure 11-6.
The write-protected position of the WPS shall be the far-right position, and shall be indicated by an
arrow and the words ÒWrite ProtectÓ or ÒProtectÓ or ÒWPÓ. The arrow and indication may be on the
end of the PC Card, as shown in Figure 11-2, Figure 11-3, Figure 11-5, and Figure 11-6 or on the
bottom cover, or on both the end and bottom cover.
If a WPS is used, it is recommended that it pass all requirements, as applicable, in PC Card
Environmental. It is also recommended the WPS perform as specified for a minimum of 100 (Write
Protect/Write Enable) cycles.
3.2 Battery Location

The battery, if installed, shall be located at the locations shown in Figure 11-2, Figure 11-3, Figure
11-5 and Figure 11-6. The battery holder, if installed, shall be designed so that the positive (+) side
of the battery faces Surface A.
3.3 Labeling (Marking)

The thickness of labeling, if used, shall not cause the PC Card to exceed the thickness specified in
Figure 11-2, Figure 11-3, Figure 11-4, Figure 11-5, Figure 11-6, or Figure 11-7.
The label, if used, must withstand all environmental test specified the PC Card Environmental
Section.
The PC Card logo may be displayed by member company manufacturers as authorized.
CARD DIMENSIONS
4. CON N E C T OR
The specified PC Card interconnect system shall be a 68-position, 2-piece pin-and-socket. The socket
contacts shall be within the PC Card connector.
4.1 Card Connector

The socket contacts are located on the full-size PC Card as shown in Figure 11-2: TYPE I PC Card
Package Dimensions, Figure 11-3: TYPE II PC Card Package Dimensions, Figure 11-4: Type III PC
Card Package Dimensions, Figure 11-8: Type I PC Card (3D), Figure 11-9: Type II PC Card (3D),
and Figure 11-10: Type III PC Card (3D). The socket contacts for Small PC Card are located on the
Small PC Card as shown in Figure 11-5: Small PC Card Type I Package Dimensions, Figure 11-6:
Small PC Card Type II Package Dimensions, and Figure 11-7: Small PC Card Type III Package
Dimensions.
The PC Card connector socket shall be configured as shown in Figure 11-11: Full-size PC Card
Connector Socket or Figure 11-12: Small PC Card Connector Socket.
The PC Card connector socket layout shall match the host pin-connector layout as shown in Figure
11-15: Full-size PC Card Pin Connector or Figure 11-16: Small PC Card Pin Connector.
The CardBus PC Card connector (or PCMCIA/JEIDA approved equivalent) shall contain a top side
planar, electrically conductive, ground plate (Figure 11-40: CardBus PC Card Recommended
Connector Grounding Interface Dimensions) with eight (8) raised dimples 0.5 mm in height. This
ground plate is connected to the PC Card electrical system ground (Figure 11-41: CardBus PC Card
Recommended PCB Footprint), must be isolated from chassis ground, and shall meet Electrostatic
Discharge requirements as specified in the Electrostatic Discharge Section.
4.2 Host Connector

The full-size PC Card host pin connector shall be a 68-pin connector with opening, polarization,
keying, and pin location as shown in Figure 11-15: Full-size PC Card Pin Connector. The host
connector-pin configuration is shown in Figure 11-17: Full-size PC Card Host Connector, Pin
Contacts, and the host-pin lengths are shown in Figure 11-13: Full-size PC Card Pin/Socket Contact
Length with Wipe and Figure 11-17 and pin type, length, and number in Table 4-1: Host
Connector Pin Configuration.
The Small PC Card host pin connector shall be a 68-pin connector with opening, polarization,
keying, and pin location as shown in Figure 11-16: Small PC Card Pin Connector. The host
connector-pin configuration is shown in Figure 11-18: Small PC Card Host Connector, Pin
Contacts, and the host-pin lengths are shown in Figure 11-14: Small PC Card Pin/Socket Contact
Length with Wipe and Figure 11-18, and pin type, length, and number in Table 4-1: Host
Connector Pin Configuration.
Table 4-1: Host Connector Pin Configuration

Pin Type Pin Length (L) ±.0.10 mm Pin Number
Detect 3.50 36, 67
General 4.25 All Other Pins
Power/Ground 5.00 1, 17, 34, 35, 51, 68
CONNECTOR
The outermost plating of socket and pin contact area shall be gold or other plated materials
compatible with gold and shall meet the requirements specified in the Connector Reliability and
Connector Durability Sections.
The host pin connector for CardBus PC Card applications (or PCMCIA/JEIDA approved equivalent)
shall contain a top side planar electrically conductive, ground shroud (Figure 11-42: CardBus PC
Card Recommended Host Connector Grounding Interface Dimensions) with eight (8) fingers having
an effective minimum contact wipe length of 3.6 mm when mating with the CardBus PC Card
Connector (Figure 11-45: CardBus PC Card Reference Shrouded Connector and Figure 11-46:
CardBus PC Card Reference Shrouded Connector (Stacked Connector)). These eight (8) fingers
shall be recessed within the host pin connector protective dielectric shroud providing a 0.254 mm
minimum air gap when mating with 16-bit PC Cards.
The recommended host connector PCB footprints for: the right angle connector (Figure 11-19:
Recommended Right Angle Connector PCB Footprint), the straight connector (Figure 11-20:
Recommended Straight Connector PCB Footprint), two row surface mount connector (Figure 11-21:
Recommended Two Row Surface Mount Connector PCB Footprint), and one row surface mount
connector (Figure 11-22: Recommended One Row Surface Mount Connector PCB Footprint) are
shown without mounting or hardware hole locations.
The recommended CardBus PC Card host connector PCB footprints for the right angle connector
(Figure 11-43: CardBus PC Card Recommended Right Angle PCB Footprint and Figure 11-44:
CardBus PC Card Recommended Right Angle PCB Footprint (Stacked)) is shown with mounting
hole locations. The host connector ground shroud is connected to host system electrical ground
signals and must be isolated from chassis ground.
The interconnect system shall pass all requirements of the Connector Reliability Section and the
Connector Durability Section.
If a connector ejector mechanism is used, it is recommended the ejector mechanism pass all
requirements for reliability and durability, as applicable, in Section 7 Connector Reliability and
Section 8 Connector Durability.
5 . PC CAR D G U ID AN C E
The PC Card shall be guided by the host connector for a minimum distance of 10.0 mm before the
socket connector bottoms on the host (pin) connector (see Figure 11-23: Full-size PC Card Guide
Guidance or Figure 11-24: Small PC Card Guide Guidance).
To ensure alignment of the PC Card to connectors, the full-size PC Card shall be guided for a
minimum distance of 40.0 mm before engagement, and the Small PC Card shall be guided for a
minimum distance of 27.0 mm before engagement.
NOTE Figure 11-24 is a reference for the design of the guide. To ensure alignment
of the Small PC Card to the connectors, the guide shall be designed with G2
as large as possible and W2 as small as possible.
PC CARD GUIDANCE
6. G R OU N D IN G/ EM I CL IP S
PC Card manufacturers may use frame mounted grounding/EMI Clips to reduce the
Electromagnetic Emissions of PC Cards. The clips create a path of least resistance to ground so that
the external connection (e.g. RJ11 cable) through an I/O connector will not act like an antenna. With
the clips, the cardÕs emissions are directed back through the card and into the system to either the
Battery or AC input, instead of out the card into the surrounding area.
Grounding/EMI clips can be included on memory cards as well if needed.
Material(s) selected for the mating surfaces of the grounding clips must be compatible to prevent
corrosion resulting from galvanic action. The base alloy material(s) and mating surfaces for the
grounding clip(s) in host systems and on the mating surface(s) on the card must be compatible with
gold. The interface must not wear, after life cycle testing, to a level that is no longer suitable for the
application.
The recommendation is for the material, dimensions and location of the grounding/EMI clip. The
process of attaching the clip to the frame, cover or card PWB is left to the card designer.
The location of the grounding/EMI clip on different types of PC Cards is detailed in Figure 11-2:
TYPE I PC Card Package Dimensions, Figure 11-3: TYPE II PC Card Package Dimensions, Figure
11-4: Type III PC Card Package Dimensions, Figure 11-8: Type I PC Card (3D), Figure 11-9: Type
II PC Card (3D), Figure 11-10: Type III PC Card (3D), Figure 11-5: Small PC Card Type I Package
Dimensions, Figure 11-6: Small PC Card Type II Package Dimensions, and Figure 11-7: Small PC
Card Type III Package Dimensions.
S E E P CM CI A GRA NT OF I M M U NI T Y A ND S U B L I CE NS E
F OR E M I GROU ND CL I P S U B -L I CE NS E A GRE E M E NT ,
OR CONT A CT P CM CI A OF F I CE F OR A DDI T I ONA L
I NF ORM A T I ON.
6.1 Card/Ground Clip Contact Resistance Measurement

Procedure
The contact resistance between a PC Card ground clip and the host socket chassis attachment point
shall not degrade after life cycle testing (in both the harsh and office environments) by more than 20
mW from its initial resistance measurement.
The resistance of the PC Card ground clip to host interface shall be measured in accordance with
EIA 364-B, test procedure 23 with the following test conditions:
a) open circuit voltage equals 20 mV;
b) test current equals 100 mA maximum.
Refer to Figure 11-1: Grounding/EMI Clips Contact Resistance Measurement for lead connection.
6.1.1 Office Environment

Record the contact resistance of the ground clip interface then subject the card to life cycle testing
(10,000 insertion/extraction cycles). The ground clip to host contact resistance shall be measured
GROUNDING/EMI CLIPS
using the same procedure outlined above. The contact interface is acceptable if the resistance has
increased by no more than 20 mW from the initial value.
6.1.2 Harsh Environment

Record the contact resistance of the ground clip interface then subject the card to the harsh
environment test specification. The ground clip to host contact resistance shall be measured using
the contact resistance measurement procedure. The contact interface is acceptable if the resistance
has increased by no more than 20 mW from the initial value.
6.1.3 Material Compatibility

The material selected for the mating surfaces of the ground clip must be compatible to prevent
corrosion due to galvanic action. The material specification for the ground clip in the host and the
mating surface on the card must be compatible with gold. The interface must not wear to a point
where the metal contacts, after the life cycle testing, present a contact interface that is no longer
suitable for the application. A suitable mating interface is one that has a contact potential difference
of 0.3 Vdc or less.
7 . CON N E C T OR RE L IAB IL IT Y
The interconnect system as specified in the Connector Section shall meet or exceed all reliability test
requirements of this subsection. Unless otherwise specified, all test and measurements shall be
made at:
Temperature 15°C to 35°C

Air pressure 86 to 106 kPa
Relative humidity 25% to 85%
If conditions must be closely controlled in order to obtain reproducible results, the parameters shall
be:
Temperature 23°C ± 1°C

Relative humidity 50% ± 2%
See Section 7.5 Approved Test Procedures for approved test procedures.
7.1 Mechanical Performance

The interconnect system mechanical performance is specified in the following sections.
7.1.1 Office Environment

STANDARD TESTING
Guaranteed number of insertions/ejections =10,000 minimum See Office Environment Section, EIA 364-B Class 1.1
7.1.2 Harsh Environment

STANDARD TESTING
Guaranteed number of insertions/ejections = 5,000 minimum See Harsh Environment Section, EIA 364-B Class 1.3
7.1.3 Total Insertion Force

STANDARD TESTING
39.2 N maximum Insert at speed of 25 mm/minute
7.1.4 Total Pulling Force

STANDARD TESTING
6.67 N minimum and 39.2 N maximum Extract at speed of 25 mm/minute
CONNECTOR RELIABILITY
7.1.5 Single Pin Pulling Force

STANDARD TESTING
0.098 N minimum initial value Pull the gauge pin shown to left at speed of
25 mm/minute
0.2
Gauge pinÕs surface must be wiped clean of dirt and
lubrication oil
0.420 ±0.005 mm DIAMETER (FULL-SIZE PC CARD)

0.350 ±0.005 mm DIAMETER (SMALL PC CARD)
Gauge:
Material - Tool making steel
Hardness - HRC = 50 to 55
7.1.6 Single Pin Holding Force

STANDARD TESTING
Pin shall not push out of the insulator when 9.8 N minimum Push pin on the axis at speed of 25 mm/minute with
force is applied to the pin 9.8 N minimum force while holding insulator rigid.
Insulator
9.8 N
Min Force PIN
7.1.7 Single Socket Holding Force

STANDARD TESTING
Socket shall not be dislodged or damaged when 4.9 N minimum Push socket on the axis with 4.9 N minimum force at a
force is applied to the socket speed of 25 mm/minute while holding insulator rigid
INSULATOR
4.9 N
Min Force SOCKET
7.1.8 Vibration and High Frequency

STANDARD TESTING
a. No mechanical damage shall occur on the parts 147 m/s_ (15G) peak amplitude, 10 Hz to 2000 Hz, 20
minute sweep, 12 cycles per axis, 3 axis.
b. Must not cause current interruption greater than 100 ns
See Figure 11-25: Connector Shock & Vibration Test
Fixture
7.1.9 Shock
STANDARD TESTING
a. No mechanical damage shall occur on the parts Acceleration 490 m/s_ (50G)
b. Must not cause current interruption greater than 100 ns Standard holding time 11 ms, Semi-sine wave
Velocity change 3.44 m/s (11.3 ft/s)
See Figure 11-25: Connector Shock & Vibration Test
Fixture
7.1.10 Pin Connector Inverse Insertion

STANDARD TESTING
Measurements shall be made by putting aside a gauge card to a Maximum insertion force: 58.8 N or more
guide portion of two different pin connectors and right side Travel after contact to key of pin connector: 5 mm or less
measurement at another.
Since this requirement is for a single pin connector,
inverse insertion test method in Section 9.3.11 Card
Inverse Insertion is applied to test the performance at
actual use.
7.2 Electrical Performance

The interconnect system electrical performance is specified as follows.
7.2.1 Contact Resistance (low level)

STANDARD TESTING
a. Initially 40 mW maximum Open voltage 20 mV
b. After test 20 mW maximum change Test current 1 mA
a. Measure and record the initial resistance (Ri) of the
separate connector contact interface. See Figure 11-
47: Contact Resistance Measurement
Ri £ 40 mW
b. Measure and record resistance after test (Rf) of the
connector system. Resistance value after test:
Rf = Ri ± 20 mW
7.2.2 Withstanding Voltage

STANDARD
a. No shorting or other damages when 500 Vrms AC is applied
for 1 minute
b. Current leakage 1 mA maximum
7.2.3 Insulation Resistance

STANDARD TESTING
a. Initially 1000 MW minimum Measure within 1 minute after applying 500V DC
b. After test 100 MW minimum
7.2.4 Current Capacity

STANDARD TESTING
0.5 A per contact Based upon 30°C rise above ambient temperature
7.2.5 Insulation Material

STANDARD
Flame retardant material will not burn nor support combustion
7.2.6 Ground Return Inductance

Note: This requirement applies to CardBus PC Card applications.
STANDARD TESTING
18.0 nH maximum Inductance @ 1 MHz applies to both single Low level inductance
and stacked configurations
7.3 Environmental Performance
7.3.1 Operating Environment

STANDARD
Operating Temperature: -20°C to +60°C
Relative humidity: 95% maximum (non-condensing)
7.3.2 Storage Environment

STANDARD
Storage Temperature: -40°C to +70°C
Relative humidity: 95% maximum (non-condensing)
7.4 Environmental Resistance
7.4.1 Moisture Resistance

STANDARD TESTING
Per Contact Resistance (low level) Section, Part b Temperature Cycling
Per Insulation Resistance Section, Part b (excluding vibration);
10 cycles (1 cycle = 24 hours) with connectors engaged
7.4.2 Thermal Shock

STANDARD TESTING
No physical damage shall occur during testing -55°C to +85°C
Per Contact Resistance (low level) Section, Part b 5 minute transition time (max)
Per Insulation Resistance Section, Part b 5 cycles (1 cycle = 1 hour) with connectors engaged
7.4.3 Durability (High Temperature)

STANDARD TESTING
Per Contact Resistance (low level) Section, Part b 85°C, 250 hours with connectors engaged
Exclude load and insulation resistance measurements
7.4.4 Cold Resistance

STANDARD TESTING
Per Contact Resistance (low level) Section, Part b -55°C, 96 hours with connectors engaged
7.4.5 Humidity (Normal Condition)

STANDARD TESTING
Per Contact Resistance (low level) Section, Part b Steady State40°C, 90 to 95% RH 96 hours with
connectors engaged
Per Insulation Resistance Section, Part b
7.4.6 Hydrogen Sulfide

STANDARD TESTING
Per Contact Resistance (low level) Section, Part b 3 PPM hydrogen sulfide
40°C, approx. 80% RH
96 hours, with connectors engaged
7.5 Approved Test Procedures

Section Test Mil Std EIA TP IEC 512 Other
7.1.8 Vibration and High Frequency 202, Method 204 364-28 4-6d
7.1.9 Shock 202, Method 213 364-27 4-6c
7.2.1 Contact Resistance (low level) 1344, Method 3002.1 364-23 2-2a
7.2.2 Withstanding Voltage 202, Method 301 364-20 2-4a
7.2.3 Insulation Resistance 202, Method 302 364-21 2-3a
7.2.5 Insulation Material UL 94V-0
7.2.6 Ground Return Inductance 364-69
7.4.1 Moisture Resistance 202, Method 106 364-31
7.4.2 Thermal Shock 202, Method 107 364-32 6-11d
7.4.3 Durability (High Temperature) 202, Method 108 364-17 5-9b
7.4.4 Cold Resistance 364-59 6-11j JISC 00201
7.4.5 Humidity (Normal Condition) 202, Method 103 364-31 6-11c
7.4.6 Hydrogen Sulfide JEIDA 382
1. JIS = Japanese Industrial Standard
2. JEIDA = Japanese Electronic Industry Development Association
8 . CON N E C T OR DU R AB IL IT Y
The interconnect system as specified in Connector Section shall meet or exceed all durability
requirements of this subsection.
Test conditions for the mate/unmate cycles are:
Cycle Rate 400-600 cycles per hour

Relative Humidity 25% to 85%
Air Pressure 86 to 106 kPa
8.1 Office Environment

The office environment is defined in EIA-364-B Class 1.1 - year round air conditioning (non-filtered)
with humidity control.
Test Sequence:
Contact resistance per Contact Resistance (low level) Section, Part a

Mate and unmate the connector for a total of 10,000 cycles
Contact resistance per Contact Resistance (low level) Section, Part b
8.2 Harsh Environment

The harsh environment is defined in EIA-364-B Class 1.3Ñno air conditioning, no humidity control
with normal heating and ventilation:
Contact resistance per Contact Resistance (low level) Section, Part a

Mate and unmate the connector 1,000 cycles TOTAL CYCLES = 1,000
Humidity per Humidity (Normal Condition) Section
Hydrogen sulfide per Hydrogen Sulfide Section
Contact resistance per Contact Resistance (low level) Section, Part b
Note: Connector durability utilizing Moisture Resistance in lieu of Humidity is acceptable.
CONNECTOR DURABILITY
9 . P C CAR D E N V IR ON M E N TAL
The PC Card as specified in this Standard shall meet or exceed all environmental tests of the
Environmental Resistance Section. The Small PC Card shall meet or exceed all of the same
environmental tests in the Environmental Resistance Section with the exception of the following
tests, for which tests specific to Small PC Card have been developed:
· Bend Test
· Torque Test
The battery, if part of the PC Card, shall be installed for all tests. Unless otherwise specified, all test
and measurements shall be made at:

Relative Humidity 25% to 85%
be:
Temperature 23°C ± 1°C

Relative Humidity 50% ± 2%
See Section 9.4 Approved Test Procedures for approved test procedures.
9.1 Reference Standards

1. Electrical performance: Electrical performance must conform to these requirements after testing.
2. Form: The form and dimensions, including warpage, must conform to the physical use
requirements after testing. Scratches, color and other appearance items shall depend on the
specifications of the manufacturer for each card and are not a basis for evaluation here.
Note: Evaluation standards are limited and evaluations are to be within the
reliability of the connectors, if the connectors are used in the test.
9.2 Environmental Performance

The PC Card storage and operating environment are specified in this subsection. The storage and
operating environment test parameters are specified in
Environmental Resistance Section.
9.2.1 Operating Environment

Ambient temperature 0°C to 55°C
Relative humidity 95% maximum (non condensing)
SRAM data retention per Section 9.3.20 SRAM Data Retention
PC CARD ENVIRONMENTAL
9.2.2 Storage Environment

Storage temperature -20°C to 65°C
Relative humidity 95% maximum (non condensing)
SRAM data retention per Section 9.3.20 SRAM Data Retention
9.3 Environmental Resistance

The PC Card shall be tested per the Environmental Resistance specifications listed below. The
manufacturer shall ensure adequate testing in order to ensure the PC Card conforms to this
specification.
9.3.1 High Storage Temperature

STANDARD TESTING
PC Card to function as specified after test and all non-volatile Test Condition 65°C and 90-95% RH for 96 hours
memory to retain the data stored prior to test minimum, Vcc = 0
Data retention of SRAM and other battery powered solid state
memory per section 9.3.20 SRAM Data Retention
The form and dimensions, including warpage, must conform to
the physical use requirements of these specifications after
testing
Scratches, color and other appearance items shall depend on
the specifications of the manufacturer for each card and are not
a basis for evaluation here
9.3.2 Low Storage Temperature

STANDARD TESTING
PC Card to function as specified after test and all non- volatile Test Condition -20°C for 96 hours minimum, Vcc = 0
memory to retain the data stored prior to test
Data retention of SRAM and other battery powered solid state
testing
9.3.3 High Operating Temperature

STANDARD TESTING
PC Card to function as specified after test and all non-volatile Test Condition 55°C for 96 hours minimum
memory to retain the data stored prior to test Vcc = manufacturer specified
testing
9.3.4 Low Operating Temperature

STANDARD TESTING
PC Card to function as specified after test and all non-volatile Test Condition 0°C for 96 hours minimum
memory to retain the data stored prior to test. Vcc = manufacturer specified
testing
9.3.5 Thermal Shock

STANDARD TESTING
PC Card to function as specified after test and all non- volatile
memory to retain the data stored prior to test
Data retention of SRAM and other battery powered solid state TEST TEMP (°C) TIME
1 -20 30
2 25 <05
3 65 30
4 25 <05
The form and dimensions, including warpage, must conform to Repeat for 100 cycles Vcc = 0
the physical use requirements of these specifications after Card Connector disengaged
testing
Scratches, color and other appearance shall depend on the
specifications of the manufacturer for each card and are not a Time in minutes.
basis for evaluation here
9.3.6 Moisture Resistance

STANDARD TESTING
PC Card to function as specified after test and Maximum Temperature 55 °C.
all non-volatile memory to retain the data Minimum temperature 0 °C
stored prior to test
Steps 7a and 7b deleted from Method 106E MIL-STD 202.
The form and dimensions, including warpage,
must conform to the physical use Repeat test for 10 cycles (excluding vibration)
requirements of these specifications after Vcc = manufacturer specified, Card connector disengaged.
testing
Scratches, color and other appearance items
shall depend on the specifications of the
manufacturer for each card and are not a
basis for evaluation here
9.3.7 Electrostatic Discharge

STANDARD TESTING
PC Card to function as specified after test 1 and 2 and all non- TEST 1: Discharge two (2) times on Surface A
volatile memory to retain the data stored prior to test Repeat test on Surface B
TEST 1 and TEST 2 should not be done as a series test Total discharge cycles = 4 (See Figure 11-26:
Electrostatic Discharge Test-1 Fixture)
TEST 2: Discharge total twelve (12) times each side as
indicated in Figure 11-27: Electromechanical
Discharge Test-2 Fixture
Turn PC Card over and repeat test
Total discharge cycles = 24
9.3.8 X-ray Exposure

STANDARD TESTING
PC Card to function as specified after test and all non-volatile 140 kV @ 5 mA
memory to retain the data stored prior to test Intensity 0.1Gy minimum or 10 Roentgen minimum for 1
hour minimum
9.3.9 Ultraviolet Light Exposure

STANDARD TESTING
PC Card to function as specified after test and all non- volatile Wavelength 254 nm
memory to retain the data stored prior to test Intensity 15000 mW/cm2
Exposure time 20 minutes
9.3.10 Electromagnetic Field Interference

STANDARD TESTING
PC Card to function as specified after test and all non- volatile Place PC Card in uniform magnetic field of 1,000 Oersted
memory to retain the data stored prior to test Exposure time 10 seconds
For rotating media cards, the magnetic field is 100
Oersted Exposure time 10 seconds
9.3.11 Card Inverse Insertion

STANDARD TESTING
No electrical contact between the card and connector during the Provide a grooved metal block as shown in Figure 11-
test except for Vcc and GND pins 38: Card Inverse Insertion Test Fixture and fix it to a
load tester
Note: Host connector has pin (male) contacts. Align the center of host connector and pushing block as
shown in Figure 11-39: Card Inverse Insertion Push
Block
Manually insert a sample card into the pin connector until
the front end of card key slightly touches it
Press the pushing block in the X direction at a speed of 25
mm/minute until the pushing load reaches 58.8 N
Hold the status for 1 minute
Repeat the above test 5 times
Temperature: room temperature (15°CÐ35°C)
9.3.12 Vibration and High Frequency

STANDARD TESTING
PC Card to function as specified after test and all to retain the 147 m/s2 (15G) peak amplitude
data stored prior to test 10 to 2,000 Hz, 20 minute sweep, 12 cycles per axis, 36
cycles for 3 axes (12 hr)
Vcc = 0
With battery installed (Figure 11-28: PC Card Shock
and Vibration Test Fixture)
9.3.13 Shock
STANDARD TESTING
PC Card to function as specified after test and to retain the data Acceleration 490 m/s2 (50G)
stored prior to test Duration 11ms
Semi-sine wave, velocity change: 3.44 m/s (11.3 ft/s)
(Figure 11-28: PC Card Shock and Vibration Test
Fixture)
9.3.14 Full-size PC Card Bend Test

STANDARD TESTING
PC Card to function as specified after test and to retain the data Test 1: Clamp the connector end of the PC Card with
stored prior to test surface A facing upward. Apply 19.6 N to the unclamped
end using the force bar as shown in Figure 11-29: Full-
The dimensions must conform to the use requirements of these
size PC Card Bend Test Fixture. Time ³ 1 minute
specifications after testing
Test 2: Clamp the non-connector end of the PC Card with
surface A facing upward. Apply 19.6 N to the unclamped
end using the force bar as shown in Figure 11-29: Full-
size PC Card Bend Test Fixture. Time ³ 1 minute
Test 3 and 4: Repeat test 1 and 2 with surface B facing
upward
Total test must include all four procedures
9.3.15 Small PC Card Bend Test

STANDARD TESTING
PC Card to function as specified after test and to retain the data Test 1: Clamp the connector end of the Small PC Card
stored prior to test with surface A facing upward. Apply 19.6N to the
unclamped end using the force bar as shown in Figure
11-30: Small PC Card Bend Test Fixture. Time >= 1
specifications after testing
minute
Test 2: Clamp the non-connector end of the Small PC
Card with surface A facing upward. Apply 19.6N to the
unclamped end using the force bar as shown in Figure
11-30. Time >= 1 minute
Test 3 and Test 4: Repeat test 1 and 2 with surface B
facing upward.
Total test must include all four procedures.
9.3.16 Drop Test

STANDARD TESTING
PC Card to function as specified after test and to retain the data Drop PC Card two(2) times in three(3) mutually
stored prior to test exclusive axes from a height of 75 cm onto a non-
cushioning, vinyl-tile surface
The PC Card must conform to the use requirements of these
specifications after testing For rotating media cards:
Scratches, color and other appearance items shall depend on Drop PC Card (in a protective pouch) two(2) times in
the specifications of the manufacturer for each card and are not three (3) mutually exclusive axes from a height of 75 cm
a basis for evaluation here onto a non-cushioning vinyl-tile surface
Drop PC Card (in a protective pouch) two(2) times in
three (3) mutually exclusive axes from a height of 75 cm
onto a 0.635 cm nap industrial carpeted surface
9.3.17 Full-size PC Card Torque Test

STANDARD TESTING
PC Card to function as specified after test and to retain the data Apply clockwise torque to the unsupported end of the PC
stored prior to test Card (torque = 1.236 N-m maximum or angle = 10°
maximum, whichever occurs first)
specifications after testing Time = 5 minutes
Scratches, color and other appearance items shall depend on Repeat test applying counter-clockwise torque
the specifications of the manufacturer for each card and are not Repeat test five (5) times in each direction
See Figure 11-31: Full-size PC Card Torque Test
Fixture
9.3.18 Small PC Card Torque Test

STANDARD TESTING
PC Card to function as specified after test and to retain the data ISO 7816-1
stored prior to test Apply clockwise torque to the unsupported end of the
The dimensions must conform to the use requirements of these Small PC Card (torque = 1.236 N-m maximum and/or
specifications after testing angle = 10° maximum, whichever occurs first)
Scratches, color and other appearance items shall depend on Time = 5 minutes
the specifications of the manufacturer for each card and are not Repeat test applying counter-clockwise torque
Repeat test five (5) times in each direction
See Figure 11-32: Small PC Card Torque Test
Fixture.
9.3.19 PC Card Warpage

STANDARD TESTING
PC Card to function as specified after test and retain the data Measure the PC Card (Type I or II) interconnect and
stored prior to the test substrate thicknesses
The dimensions must conform to the use requirements of Then place the PC Card (Type I or II) on a flat plate and
these specification after testing measure the maximum warpage
Figure 11-33: Warpage Measurement
AÐInterconnect Area, Figure 11-34: Warpage
Measurement AÐSubstrate Area, Figure 11-35:
Warpage Measurement BÐThickness Measurements,
Figure 11-36: Warpage Measurement
BÐMeasurements, and Figure 11-37: Warpage
Measurement BÐMeasurement Positions
9.3.19.1 Card Warpage

Card warpage dimensions are an important element in assuring that the connector engages. It is
recommended that warpage dimensions be controlled as follows at the time of manufacturer
shipment. This applies only to Type I and Type II PC Cards.
9.3.19.2 Method of Measuring Warpage

Measurement methods A and B are prescribed for measuring warpage. When measuring warpage,
avoid using a large load that would damage the card.
(1) Warpage Measurement Method A
a) Measuring warpage at interconnect area
Place a parallel plate against the interconnect area. The interconnect area warpage measurement
is the maximum open space dimension (W) measured by a projector.
See Figure 11-33: Warpage Measurement AÐInterconnect Area.
b) Measuring substrate area warpage
Place a parallel plate against the entire substrate area. Measure the thickness of the card (T)
including warpage. This is the control value.
See Figure 11-34: Warpage Measurement AÐSubstrate Area.
(2) Warpage Measurement Method B
Measure the interconnect areaÕs thickness T(i) and substrate areaÕs thickness T(s) within the
ranges shown.
See Figure 11-35: Warpage Measurement BÐThickness Measurements.
Next, use a dial gauge, micrometer or other measuring instrument which can measure the
height from the horizontal plane, and slide the card or the measuring instrument to measure
the height.
a) Measuring warpage at interconnect area
Read the maximum value T(MAX) measuring after sliding.
Warpage dimension = T(MAX)-T(i).
See Figure 11-36: Warpage Measurement BÐMeasurements.
b) Measuring substrate area warpage

Read the maximum value T(MAX) measured after sliding. When measuring, slide in the long-
side direction, and measure at least 3 locations, in the center and at both sides. Warpage
dimension equals T(MAX)-T(s).
See Figure 11-36: Warpage Measurement BÐMeasurements.
Recommended positions for warpage measurement are indicated in Figure 11-37: Warpage
Measurement BÐMeasurement Positions.
9.3.19.3 Recommended Value of Warpage Dimensions

(1) Interconnect area:
Width (short side) 0.15 mm maximum
Length (long side) 0.35 mm maximum
(2) Substrate area (card thickness including warpage):
a) For warpage measurement method A:
Type I: 3.80 mm maximum
Type II: 5.35 mm maximum
Type III: To be defined
b) For warpage measurement method B
Type I: 0.50 mm maximum
Type II: 0.50 mm maximum
Type III: To be defined
9.3.20 SRAM Data Retention

STANDARD TESTING
SRAM PC Card to retain all data after each test (1 and 2) Test 1: Test condition 55°C for 24 hours minimum Vcc =
0
Test 2: Test condition 0°C for 24 hours minimum Vcc = 0
9.4 Approved Test Procedures

Section Test Mil Std EIA TP IEC 512 Other
9.3.1 High Storage Temperature 202, Method 103 364-31 6-11c
9.3.2 Low Storage Temperature 364-59 6-11j JIS C 00201
9.3.3 High Operating Temperature 202, Method 108 364-17 5-9b
9.3.4 Low Operating Temperature 364-59 6-11j JIS C 00201
9.3.5 Thermal Shock 202, Method 107 364-32 6-11d
9.3.6 Moisture Resistance 202, Method 106 364-31
9.3.7 Electrostatic Discharge ISO 7816-1
9.3.8 X-ray Exposure ISO 7816-1
9.3.9 Ultraviolet Light Exposure ISO 7816-1
9.3.10 Electromagnetic Field Interference ISO 7816-1
9.3.12 Vibration and High Frequency 202, Method 204 364-28 4-6d
9.3.13 Shock 202, Method 213 364-27 4-6c
9.3.17 Full-size PC Card Torque Test ISO 7816-1
1. JIS = Japanese Industrial Standard
1 0 . P C C A R D T H E R M A L R AT I N G
10.1 Determination Using a Temperature Rise Method

Like the host system, the PC Card must also have a thermal rating. The following is a low cost
optional method to determine the thermal rating derived from the temperature gradient produced
by the operating card. This temperature rise is then converted to the PC CardÕs thermal rating. In a
balanced system, the heat energy above 65¡C generated by the PC Card is removed by the host
system thus maintaining the PC Card at a temperature at or below 65¡C. This method shall be
made in a draft free environment under the following conditions:
Temperature 24¡C ± 1¡C

Relative Humidity 50% ± 10%
Note that alternative methods, such as an electrical summation of all power dissipated within the PC
Card, if performed correctly, will yield acceptable results.
10.1.1 Measuring the PC Card Temperature

It is important when measuring the PC Card temperature to ensure that only heat generated within
the PC Card physical space is determined. Any heat generated external to the PC Card envelope
must not influence the PC Card temperature measurement. Any heat generated by external input
must be accounted for.
10.1.2 Procedure
The PC Card shall be removed from the host test system using a card type specific extender (PC
Card 16 or CardBus PC Card type extender) and any external heat loads produced by the PC Card
in order to isolate external influence of the measurement as in Figure 10-1: PC Card Thermal
Environment Measurement Method. The PC Card shall be free of external influences for a
quartersphere of 304.8 millimeters and 25.4 - 38.1 millimeters above a dielectric (non-conductive)
table surface as indicated in Figure 10-2: Free Area Around Card Being Rated. The card shall be in a
free air environment on both sides. Place five thermocouples or similar temperature measuring
devices on each side of the PC Card as indicated by the template in Figure 10-3: Location of
Thermocouples - 5 Each Side or Figure 10-4: Location of Thermocouples for Small PC Card - 5
Each Side.
PC CARD THERMAL RATING
Thermocouples 1
To Thermal
Measuring Device
External Dongle
(or other external load)
PC Card Thermal Environment
1. See Figure 10-3: Location of Thermocouples - 5 Each Side
Figure 10-1: PC Card Thermal Environment Measurement Method
304.8 mm
End of Card Connector
Card Centerline
End view of card
304.8 mm
Edge view of card 25.4 - 38.1 mm

Dielectric Table Surface
Top/Bottom view of card
Figure 10-2: Free Area Around Card Being Rated
63.5
43.18
12.7
21.59
38.1
40.64
PC Card
Card Host Connector Edge
Note: All Notes: Allindimensions

dimensions millimeters in millimeters
Tolerance = ± 2.54 mm
Tolerance = +/- 2.54mm
Figure 10-3: Location of Thermocouples - 5 Each Side
38.1
25.4
12.7
10.16
21.4
32.64
Card Host
Connector Edge
SmallPC Card
Note: All dimensions in millimeters
Tolerance = ±1.27 mm
Figure 10-4: Location of Thermocouples for Small PC Card - 5 Each Side
From a host system, a program must be run in order to realistically exercise the card at its extremes.
When the temperature of the PC CardÕs surface is stable within ± 1¡C over thirty minutes, the card
has reached its thermal rating.
PC CARD THERMAL RATING
Determine the average temperature rise from the total number of thermocouples or similar
temperature measuring devices. Obtain the PC CardÕs Thermal Rating by using the averaged
temperature rise and Figure 10-5: Thermal Rating vs. Temperature Rise. The Thermal Rating is
characterized by the equation Thermal Rating (X.Y) = 0.05DT1.26 + 1.1E-7DT4. This is the value that is
recorded in the PC CardÕs CIS thermal entry (see TPCE_MI: Miscellaneous Features Field in the
Metaformat Specification).
Below is the list of items used to determine this Thermal Rating curve and equation:
· T30-2-506 Thermocouple Wire (30 Gauge, Type T)
· Hot Spot TC Welder (welded thermocouples)
· Fluke Hydra Data Acquisition Unit (2620A Module)
· 3M Copper Electrical Tape, 25.4 mm, H813441E181R, 12.7 mm 3M 230 Drafting Tape
Used to match the IR emissivities of the card surface to the thermocouple wire mounting area.
The copper tape's optical properties do not match, because it is a conductor and not a dielectric.
The copper tape provides a good stiff bond of the wire to the card and it provides a good
thermal interface of the card to the wire. When married to the drafting tape as an overlay, we
achieved very good agreement between the IR image and the thermocouple readouts. This
implies minimal test-induced error.
10.1.2.1 Thermal Rating vs. Temperature Rise
Thermal Rating (X.Y) = 0.05 D T + 1.1E D T

1.26 -7 4
5
Thermal Rating
0
20
24
28
0
40
44
48
4
12
16
32
36
Temperature Rise, D T (TFINAL - T AMB), C

o
Figure 10-5: Thermal Rating vs. Temperature Rise
11. FIGU R E S
V POWER
SUPPLY
A
GROUND CLIP
HOST SOCKET CHASSIS

ATTACHMENT POINT
Figure 11-1: Grounding/EMI Clips Contact Resistance Measurement
FIGURES
WPS 1
BATTERY
PROTECT
Surface A
2x H
L
2x G
SUBSTRATE AREA
3
C INTERCONNECT AREA P
2x S CONNECTOR 2x R 4
2x T
W
6
X X
Surface A
#34 #1 X
5 volt key
#68 Surface B #35
X X
Surface A
#34 #1 Z
low voltage key
#68 Surface B #35
L ± 0.20 4 6 W ± 0.10 X ± 0.05 Y ± 0.05 Z ± 0.05 G ± 0.60 H ± 0.60

C MIN P MIN 3 R ± 0.10 S MIN T
10.0 85.60 10.0 0.60 3.0 1.65 54.00 1.00 1.60 2.10 65.60 79.60
1 RECOMMENDED BATTERY LOCATION. THE BATTERY HOLDER SHOULD BE DESIGNED SO THAT THE
POSITIVE SIDE OF THE BATTERY IS UP (TOWARD SURFACE A)
2 THE PC CARD SHALL BE OPAQUE (NON SEE THRU)
3 POLARIZATION KEY LENGTH

4 DIMENSION R CORNER RADIUS
5 GROUND CLIP LOCATION
6 FOR CARDBUS PC CARDS DIMENSION T IS INCREASED BY 0.50 ± 0.05 mm OVER DIMPLES
(REFER TO Figure 11-40: CardBus PC Card Recommended Connector Grounding Interface Dimensions)
INTERCONNECT AREA TOLERANCE = ± 0.05 mm
SUBSTRATE AREA TOLERANCE = ± 0.10 mm
Figure 11-2: TYPE I PC Card Package Dimensions
WPS 1
BATTERY
PROTECT
Surface A
2x H
2x G
L
SUBSTRATE AREA
3
C INTERCONNECT AREA P
2x R 4
2x S CONNECTOR
2x T1
W
6
2x T2
X X
Surface A
#34 #1 X
5 volt key
#68 #35
Surface B
Y
X X
Surface A
#34 #1 Z
low voltage key
#68 #35
Surface B
Y
L ± 0.20 4 6 W ± 0.10 X ± 0.05 Y ± 0.05 Z ± 0.05 G ± 0.60 H ± 0.60

C MIN P MIN 3 R ± 0.10 S MIN T1 ± 0.05 T2 MAX
10.0 85.60 10.0 0.60 3.0 1.65 2.50 54.00 1.00 1.60 2.10 65.60 79.60
1 RECOMMENDED BATTERY LOCATION. THE BATTERY HOLDER SHOULD BE DESIGNED SO THAT THE
POSITIVE SIDE OF THE BATTERY IS UP (TOWARD SURFACE A)

6 FOR CARDBUS PC CARDS DIMENSION T1 IS INCREASED BY 0.50 ± 0.05 mm OVER DIMPLES
Figure 11-3: TYPE II PC Card Package Dimensions
FIGURES
Surface A
2x H
L 2x G
SUBSTRATE AREA
2
INTERCONNECT AREA P 2x C
CONNECTOR 2x R 3
2x T1
2x S
W1
5 T2
X X
W2
Surface A
#34 #1 T3 T4
Y X 5 volt key
#68 Surface B #35
X X
W2
Surface A
#34 #1 T3 T4
low voltage key
Y #68 #35 Z
Surface B
C MIN L ± 0.20 P MIN 2 5 T2 MAX T3 MAX T4 REF G ± 0.60

T1 ± 0.05
10.0 85.60 10.0 1.65 2.50 8.00 10.50 65.60
W1 ± 0.10 W2 MAX X ± 0.05 Y ± 0.05 Z ± 0.05 R ± 0.10 3 S MIN H ± 0.60
54.00 51.0 1.00 1.60 2.10 0.60 1.50 79.60


5 FOR CARDBUS PC CARDS DIMENSION T1 IS INCREASED BY 0.50 ± 0.05 mm OVER DIMPLES
Figure 11-4: Type III PC Card Package Dimensions
WPS 1
BATTERY
PROTECT
Surface A
2x H
SUBSTRATE AREA
2x G
3
C
P
INTERCONNECT AREA
CONNECTOR 2x R
2x S
W
2x T
5
Surface A
#34 #1
5 volt key
Y
#68 #35
X Surface B X
Surface A
#34 #1
low voltage key
Y
Z
#68 #35
Surface B X
X
C MIN L ± 0.2 P MIN R ± 0.10 S MIN 6 X ± 0.05 Y ± 0.05 Z ± 0.05 G ± 0.60 H ± 0.60
T W
5
10.0 45.00 10.0 0.60 3.0 1.65 42.80 1.00 1.55 2.40 25.00 39.00
1 RECOMMENDED BATTERY LOCATION. THE BATTERY HOLDER SHOULD BE DESIGNED SO

THAT THE POSITIVE SIDE OF THE BATTERY IS UP (TOWARD SURFACE A)

5 INTERCONNECT AREA TOLERANCE = ± 0.05 mm
SUBSTRATE AREA TOLERANCE = ± 0.10 mm
6 TOLERANCE OF ENGAGEMENT AREA C = +0.10/-0.05 mm
TOLERANCE OF OTHER AREA = ± 0.10 mm
Figure 11-5: Small PC Card Type I Package Dimensions
FIGURES
WPS 1
BATTERY
PROTECT
Surface A
2x H
SUBSTRATE AREA
2x G
3
C
P
INTERCONNECT AREA
CONNECTOR 2x R
2x S
W
2x T1
Surface A 2x T2
#34 #1
5 volt key
Y
#68 #35
X Surface B X
Surface A
#34 #1
low voltage key

Y
Z
#68 #35
Surface B X
X
C MIN L ± 0.20 P MIN R ± 0.10 S MIN T1 ± 0.05 T2 MAX 5 X ± 0.05 Y ± 0.05 Z ± 0.05 G ± 0.60 H ± 0.60
W
10.0 45.00 10.0 0.60 3.0 1.65 2.50 42.80 1.00 1.55 2.40 25.00 39.00
1 RECOMMENDED BATTERY LOCATION. THE BATTERY HOLDER SHOULD BE DESIGNED SO

THAT THE POSITIVE SIDE OF THE BATTERY IS UP(TOWARD SURFACE A)
2 THE PC CARD SHALL BE OPAQUE(NON SEE THRU)

Figure 11-6: Small PC Card Type II Package Dimensions
T4
T3
Surface A
2x H
SUBSTRATE AREA
2x G
2
C
P
INTERCONNECT AREA
CONNECTOR 2x R
2x S
W
T1
Surface A
T2
#34 #1
5 volt key
Y
#68 #35
X Surface B X
Surface A
#34 #1
low voltage key
Y
Z
#68 #35
Surface B X
X
C MIN L ± 0.20 P MIN R ± 0.10 S MIN T1 ± 0.05 T2 MAX T3 MAX T4 REF
10.0 45.00 10.0 0.60 3.0 1.65 2.50 8.00 10.50
W 4 X ± 0.05 Y ± 0.05 Z ± 0.05 G ± 0.60 H ± 0.60
42.80 1.00 1.55 2.40 25.00 39.00
1 THE PC CARD SHALL BE OPAQUE(NON SEE THRU)

Figure 11-7: Small PC Card Type III Package Dimensions
FIGURES
C
O
N
N
E
C
TO
R
P D
C
C
A
BA
TT
ER R
Y
B
A
TT
E
R
Y
PR
OT
EC
T
G
R
O
U
N
W
D
P
C
S
LI
P
Figure 11-8: Type I PC Card (3D)
C
O
N
N
E
C
TO
R
P D
C
C
A
R
BA
TT
ER
Y
B
A
TT
E
R
Y
PR
OT
EC
T
G
R
O
U
N
D
W
C
P
LI
S
Figure 11-9: Type II PC Card (3D)
C
O
N
N
E
C
TO
R
P D
C
C
A
R
G
R
O
U
N
D
C
LI
P
Figure 11-10: Type III PC Card (3D)
FIGURES

, PIN INSERTION
0.94 MIN
Figure 11-11: Full-size PC Card Connector Socket
0.85 MIN
PIN INSERTION
Figure 11-12: Small PC Card Connector Socket
L3
L1 L4
L2
2
PIN SOCKET CONTACT
1 PIN/SOCKET CONTACT AREA
2 L4 IS THE POINT OF FIRST ENGAGEMENT FOR MATING WITH THE SOCKET

CONTACTS/HOUSING MOUNTED WITHIN THE CARD
L ± 0.1 L1 MAX L2 REF L3 ± 0.10 L4
POWER 5.00 0.50 4.50 0.50 0.50 ~ 2.50
GENERAL 4.25 0.50 3.75 0.50 0.50 ~ 2.50
DETECT 3.50 0.50 3.00 0.50 0.50 ~ 2.50
Figure 11-13: Full-size PC Card Pin/Socket Contact Length with Wipe
L3
L1 L4
L2
2
PIN SOCKET CONTACT
1 PIN/SOCKET CONTACT AREA
2 L4 IS THE POINT OF FIRST ENGAGEMENT FOR MATING WITH THE SOCKET

CONTACTS/HOUSING MOUNTED WITHIN THE CARD
L ± 0.1 L1 MAX L2 REF L3 (+0.15/-0.10) L4
POWER 5.00 0.50 4.60 0.40 0.50 ~ 2.50
GENERAL 4.25 0.50 3.85 0.40 0.50 ~ 2.50
DETECT 3.50 0.50 3.10 0.40 0.50 ~ 2.50
Figure 11-14: Small PC Card Pin/Socket Contact Length with Wipe
FIGURES
33 EQ SP = L1
P
P
PIN LAYOUT
2 ROW - 68 PINS
T Y
W
#1 #34
5 volt key
#35 #68
X
T
L2
T FRONT VIEW
Y
W
#1 #34
low voltage key
#35 #68
Z
T
L2
FRONT VIEW
L1 ± 0.15 L2 ± 0.08 P ± 0.10 T ± 0.05 W ± 0.08 X ± 0.05 Y ± 0.05 Z ± 0.05
41.91 54.20 1.27 0.90 3.50 1.20 1.40 2.30
Figure 11-15: Full-size PC Card Pin Connector
33 EQ SP = L1
P1
P2 P3 P4
PIN LAYOUT
2 ROW - 68 PINS
T T
W
#1 #34 X
5 volt key
X #35 #68
L2
FRONT VIEW
T T
W Y
#1 #34
low voltage key
#35 #68
X
L2
FRONT VIEW
L1 ± 0.15 L2 ± 0.08 P1 ± 0.10 P2 ± 0.10 P3 ± 0.10 P4 ± 0.10 T ± 0.05 W ± 0.07 X ± 0.05 Y ± 0.05
33.00 43.00 1.27 1.00 1.00 0.50 0.90 3.50 1.75 2.60
Figure 11-16: Small PC Card Pin Connector
FIGURES
PIN LENGTH L PIN LENGTH L
0.5 MIN 0.5 MIN
2.5 MAX PLATING AREA
MATED CONTACT ENGAGEMENT AREA: MINIMUM PLATING AREA:

THE SOCKET-CONNECTOR PIN CONTACT FOR THE PIN CONNECTOR, THE EFFECTIVE
POSITION MUST BE WITHIN THE SHADED CONTACT AREA (SHADED AREA) IS SHOWN
AREA WHEN THE PIN AND SOCKET CONNECTORS ABOVE.
ARE FULLY MATED.
110˚ MIN (CONTACT AREA)
0.50 ± 0.10
10˚ - 15˚
RADIUS INCLUDED
0.44 ± 0.02
(PIN DIAMETER)
0.46 MAX
PIN-CONNECTOR PIN CROSS-SECTION PIN-CONNECTOR PIN-TIP FORM

FORM AND DIMENSIONS AND DIMENSIONS
Figure 11-17: Full-size PC Card Host Connector, Pin Contacts
PIN LENGTH L PIN LENGTH L
0.5 MIN 0.5 MIN
2.5 MAX PLATING AREA
MATED CONTACT ENGAGEMENT AREA: MINIMUM PLATING AREA:

THE SOCKET-CONNECTOR PIN CONTACT FOR THE PIN CONNECTOR, THE EFFECTIVE
POSITION MUST BE WITHIN THE SHADED CONTACT AREA (SHADED AREA) IS SHOWN
AREA WHEN THE PIN AND SOCKET CONNECTORS ABOVE.
ARE FULLY MATED.
+0.15
0.40 -0.10
(1)
110˚ MIN (CONTACT AREA)
10˚ - 15˚
RADIUS INCLUDED
+0.15
0.40 -0.10
(2) 0.25 MAX
0.37 ± 0.02
(PIN DIAMETER)
0.39 MAX
PIN-CONNECTOR PIN CROSS-SECTION PIN-CONNECTOR PIN-TIP FORM

FORM AND DIMENSIONS AND DIMENSIONS ((1) or (2))
Figure 11-18: Small PC Card Host Connector, Pin Contacts
FIGURES
INSERT CARD
#36
#68 #35
#67
W2
#34
#33 #2 #1 3x W1
L2
L1
L1 ± 0.08 L2 ± 0.05 W1 ± 0.05 W2 REF
41.91 1.27 1.91 5.72
Figure 11-19: Recommended Right Angle Connector PCB Footprint
#33
#1 #34
#2
W2
#35
#36 #67 #68 3x W1
L2
L1
L1 ± 0.08 L2 ± 0.05 W1 ± 0.05 W2 REF
41.91 1.27 1.91 5.72
Figure 11-20: Recommended Straight Connector PCB Footprint
INSERT CARD
#68 #35
#34 #1
L2 TYP L3
2x L1
L1 ± 0.10 L2 ± 0.05 L3 REF
41.91 1.27 0.64
Figure 11-21: Recommended Two Row Surface Mount Connector PCB Footprint
INSERT CARD
#34 #35
#68 #1
L1 TYP
L2
(L1 X 67)
L1 ± 0.050 L2 ± 0.080
0.635 42.545
Figure 11-22: Recommended One Row Surface Mount Connector PCB Footprint
,,
FIGURES
G3
3
P
KEYS
1
W2
POLARIZATION
W1
2
2
G1
G2
G1 MIN G2 MIN G3 ± 0.30 P MAX W1 ± 0.08 W2 ± 1.4
10.0 40.0 9.70 5.10 54.20 55.6
1 THE PC CARD SHOULD BE GUIDED FOR A MINIMUM

DISTANCE OF 40.0 mm
2 THE CONNECTOR SHALL GUIDE THE PC CARD FOR A
MINIMUM DISTANCE OF 5.0 mm BEFORE ENGAGEMENT
3 THE CONNECTOR POLARIZATION KEYS ARE DEFINED IN
Figure 11-15: Full-size PC Card Pin Connector
Figure 11-23: Full-size PC Card Guide Guidance
,, G3 3
P
KEYS
W2
W1
1
POLARIZATION
2
2
G1
G2
G1 MIN G2 MIN G3 ± 0.3 P MAX W1 ± 0.08 W2 ± 0.6
10.0 27.0 9.70 5.10 43.00 43.6
1 THE SMALL PC CARD SHOULD BE GUIDED FOR A MINIMUM

DISTANCE OF 27.0 mm
2 THE CONNECTOR SHALL GUIDE THE SMALL PC CARD FOR A
MINIMUM DISTANCE OF 5.0 mm BEFORE ENGAGEMENT
3 THE CONNECTOR POLARIZATION KEYS ARE DEFINED IN
Figure 11-16: Small PC Card Pin Connector
Figure 11-24: Small PC Card Guide Guidance

FIGURES
0.50
Pin Connector 0.295 N MIN PC Card Stop
with Card Guide PC Card or Dummy Card
PCB
Mounting Rack
Figure 11-25: Connector Shock & Vibration Test Fixture
1.5 kW
1.5 kV 100 pF
25 mm2 max
GND Contact Area
1
PC Card
Insulator
1 Connect to the four (4) ground contacts (Pin No’ s 1, 34, 35 and 68)
Figure 11-26: Electrostatic Discharge Test-1 Fixture
1.5 kW
C C
15 kV 100 pF
C
GND
C
P
C
C
A
R
D
CO TE
NN
EC P LA
TO
R ING TE
CT LA
N DU P
CO T ING
U LA
INS
Notes: 1. PC Card to make contact with the conducting plate. Discharge to top cover, left side, non-connector end and right side
three times each. Total discharge cycles = 12 on each side.
2. The PC Card cover facing the conducting plate, should make mechanical contact with the conducting plate during test.
Figure 11-27: Electromechanical Discharge Test-2 Fixture
55
mm
Clamping
Device
RD
CO CA
NN PC
EC
TO
R
mm
86
1. The PC Card shock and vibration test fixture shall entrap the PC Card such that all shock
and vibration shall be transmitted into the sample card
Figure 11-28: PC Card Shock and Vibration Test Fixture

,,
FIGURES
19.6 N
Static Load
12.70 MAX
CLAMP 60.20 MIN 1 12.70 MAX

,,
FULL-SIZE PC CARD
1 THE CONTACT RADIUS FORCE BAR IS 5.0° ± 1.0°
2 THE FORCE BAR SHALL APPLY A UNIFORM FORCE ACROSS THE END OF THE PC CARD
Figure 11-29: Full-size PC Card Bend Test Fixture
19.6 N
Static Load
12.70 MAX
CLAMP 19.60 MIN 1 12.70 MAX
SMALL PC CARD
1 THE CONTACT RADIUS FORCE BAR IS 5.0° ± 1.0°

2 THE FORCE BAR SHALL APPLY A UNIFORM FORCE ACROSS THE END OF THE SMALL PC
CARD
Figure 11-30: Small PC Card Bend Test Fixture
,,,


,,
12.70 MAX 12.70 MAX
CLAMP 60.20 MIN 10˚

1
FULL-SIZE PC CARD 1 10˚
1 APPLY TORQUE TO UNCLAMPED END OF PC CARD. THE TORQUE AND ANGLE MAX ARE:
TORQUE 1.236 Nm OR 10°, WHICHEVER OCCURS FIRST
Figure 11-31: Full-size PC Card Torque Test Fixture
12.70 MAX 12.70 MAX
CLAMP 19.60 MIN 10˚

1
SMALL PC CARD 1 10˚
1 APPLY TORQUE TO UNCLAMPED END OF SMALL PC CARD. THE TORQUE AND ANGLE MAX ARE:
TORQUE 1.236 Nm OR 10°, WHICHEVER OCCURS FIRST
Figure 11-32: Small PC Card Torque Test Fixture
,,, ,,,,
FIGURES
,,,,
, ,,,,
INTERCONNECT AREA
(SHORT SIDE 10.0, LONG SIDE 3.0)
, , ,,,,
,,,
PARALLEL PLATES
W
NOTE: CARD ENLARGED FOR ILLUSTRATIVE PURPOSES
0.35 MAX
LONG SIDE 3.0
0.15 MAX
.0
10
DE
SI
RT
O
SH
CONNECTOR SIDE
Figure 11-33: Warpage Measurement AÐInterconnect Area
,,,,
,, ,, ,,,,
,, ,
,,,, ,, ,
,,,,
PARALLEL PLATES
T
,,,, ,,,, NOTE: CARD ENLARGED FOR ILLUSTRATIVE PURPOSES

Figure 11-34: Warpage Measurement AÐSubstrate Area
,,
10.0
CONNECTOR SIDE
T(i)
10.0
,,
,,
,,
10.0
T(s)
10.0
Figure 11-35: Warpage Measurement BÐThickness Measurements
T (MAX)
SLIDE
CARD
,,,,,,,
HORIZONTAL PLATE
,,,,,,,
© 1999 PCMCIA/JEIDA
Figure 11-36: Warpage Measurement BÐMeasurements
61
FIGURES
MEASUREMENT POSITION
CONNECTOR SIDE
10.0 MIN
10.0 10.0 10.0
,,
,,
,,
,,,
,
,,
,,
,,
,,,
,
,,
,,
,, ,
,,,
3.0 MIN 3.0 MIN
Figure 11-37: Warpage Measurement BÐMeasurement Positions
X
Z

,,,
Figure 11-38: Card Inverse Insertion Test Fixture
Host Connector
Figure 11-39: Card Inverse Insertion Push Block
FIGURES
54.00 ± 0.10
-A- 2.15
+0.20
-0.10
36.83 ± 0.15
0.60 S A S
6.35 ± 0.10
5.08 ± 0.10
6 PLC
5.38 ± 0.30
R 0.50 ± 0.10
SURFACE A
Figure 11-40: CardBus PC Card Recommended Connector Grounding Interface Dimensions
¢ X
0.64
0.41 ± 0.05 2.01 TYP
TYP 1.27
TYP
0.64
8 PLC
TOP SURFACE
41.91
REF
1.27 REF
BOTTOM SURFACE
Figure 11-41: CardBus PC Card Recommended PCB Footprint
FIGURES
POSN #34
POSN #1
POSN #35
POSN #68
1. ASSEMBLY KEYED FOR LOW VOLT CARDS (3.3V)
Figure 11-42: CardBus PC Card Recommended Host Connector Grounding Interface

Dimensions
POSITIONS FOR GROUND SHROUD FEATURE

16 PLC, FOR GROUNDING TO PCB
POSN #33
POSN #34
POSN #1
POSN #2 1.91
TYP
POSN #35
7.62 REF
POSN #36
POSN #67
1.27 2.36 REF
TYP POSN # 68 2 PLC
INSERT CARD
41.91 REF
51.26
Figure 11-43: CardBus PC Card Recommended Right Angle PCB Footprint
POSN #2 POSITIONS FOR GROUND SHROUD FEATURE POSN #34

POSN #1 32 PLC, FOR GROUNDING TO PCB 1.91
POSN #36 POSN #33 TYP
POSN #35
POSN #1
POSN #2
POSN #35 POSN #68

17.14 REF
POSN #67
POSN #33
POSN #34
POSN #36
2.36 REF 1.27 POSN #67
INSERT CARD 4.62
2 PLC TYP POSN #68 REF
41.91 8.13 REF
REF
44.70 GROUND PAD TO BE

REF LOCATED WITHIN
AREA SHOWN
51.26 2 PLC
60.95
REF
Figure 11-44: CardBus PC Card Recommended Right Angle PCB Footprint (Stacked)
FIGURES
5.38 mm
3.6 mm WIPE 0.5 mm DIMPLES (8)
FINGERS (8) GROUND SHROUD FOR

HOST CONNECTOR
GROUND PLATE FOR

CARD CONNECTOR
FOR REFERENCE ONLY
Figure 11-45: CardBus PC Card Reference Shrouded Connector
5.38 mm
3.6 mm WIPE 0.5 mm DIMPLES (8) 2x
FINGERS (8) 2x GROUND SHROUD FOR

HOST CONNECTOR
GROUND PLATE FOR
CARD CONNECTOR
FOR REFERENCE ONLY
Figure 11-46: CardBus PC Card Reference Shrouded Connector (Stacked Connector)
FIGURES
A POWER
SUPPLY
SOCKET
PC CARD
TERMINATION RESISTANCE
MEASUREMENT POINTS
Figure 11-47: Contact Resistance Measurement
Volume 4
Metaformat Specification
PCMCIA
JEIDA
+1-408-433-9558 (Fax) IMPORTANT:
+81-3-3433-1923 PCMCIA
INFRINGEMENT,
YOU ÒAS IS.Ó

METAFORMAT SPECIFICATION
CONTENTS
1. Introduction ___________________________________________ 1
1.1 Purpose................................................................................................................................1
1.2 Scope....................................................................................................................................1
1.3 Related Documents .............................................................................................................1
2. Overview ______________________________________________ 3
2.1 Metaformat Overview .........................................................................................................3
2.2 Metaformat Requirements...................................................................................................3
2.3 Metaformat Architecture.....................................................................................................4
2.3.1 Basic Tuple Format and Tuple Chain Structure.............................................................................................................4
2.3.2 Byte Order Within Tuples ......................................................................................................................................................4
2.3.3 Byte Order on Wide Cards ....................................................................................................................................................4
2.3.4 16-bit PC Card Metaformat in Attribute Memory Space ...........................................................................................5
2.3.5 16-bit PC Card Metaformat in Common Memory Space...........................................................................................5
2.3.6 16-bit PC Card Metaformat for Multiple Function Cards.........................................................................................6
2.3.7 CardBus PC Card Metaformat.............................................................................................................................................7
2.3.8 16-bit PC Card Tuple Chain Processing ............................................................................................................................7
2.3.9 CardBus PC Card Tuple Chain Processing ......................................................................................................................8
2.3.10 Tuple Processing Recommendations............................................................................................................................... 8
2.3.10.1 Tuple Code Known..................................................................................................................................................8
2.3.10.2 Processing Longlink Tuple ...................................................................................................................................9
2.3.10.3 Longlink Pointing to Invalid Tuple Chain......................................................................................................9
2.3.11 16-bit PC Card CIS with Indirect Access PC Card Memory ...................................................................................9
2.4 Metaformat Summary.......................................................................................................10

2.4.1 Metaformat Layer Hierarchy .............................................................................................................................................1 0
2.4.2 Tuple Code Summary ............................................................................................................................................................1 0
2.5 Special Considerations ......................................................................................................15

2.5.1 Vendor-Specific Information ..............................................................................................................................................1 5
2.5.2 System Rejection of Unsupported Cards.........................................................................................................................1 5
3. Basic Compatibility (Layer 1) ___________________________ 17

3.1 Control Tuples...................................................................................................................17
3.1.1 CISTPL_CHECKSUM: The Checksum Tuple ................................................................................................................1 8
3.1.2 CISTPL_END: The End Of Chain Tuple..........................................................................................................................1 9
3.1.3 CISTPL_INDIRECT: Indirect Access PC Card Memory ...........................................................................................2 0
3.1.4 CISTPL_LINKTARGET: The LinkTarget Tuple..........................................................................................................2 1
3.1.5 CISTPL_LONGLINK_A, CISTPL_LONGLINK_C: The 16-bit PC Card LongLink Tuples.........................2 2
3.1.6 CISTPL_LONGLINK_CB: The CardBus PC Card LongLink Tuple.....................................................................2 3
3.1.7 CISTPL_LONGLINK_MFC: The Multiple Function 16-bit PC Card Link Tuple............................................2 5

CONTENTS
3.1.8 CISTPL_NO_LINK: The No-Link Tuple .........................................................................................................................2 6

3.1.9 CISTPL_NULL: The Null Tuple .........................................................................................................................................2 7
3.2 Basic Compatibility Tuples...............................................................................................28

3.2.1 CISTPL_ALTSTR: The Alternate Language String Tuple........................................................................................2 8
3.2.2 CISTPL_DEVICE, CISTPL_DEVICE_A: The 5 volt Device Information Tuples.............................................2 9
3.2.2.1 Device Info Fields (For Tuples CISTPL_DEVICE, CISTPL_DEVICE_A)............................................3 0
3.2.2.1.1 Device ID Fields ..............................................................................................................................................3 0
3.2.2.1.1.1 Device Type Code Field...................................................................................................................3 1
3.2.2.1.1.2 WPS Field..............................................................................................................................................3 1
3.2.2.1.1.3 Address Space Indicator Field (CardBus PC Card only) ...................................................3 1
3.2.2.1.1.4 Device Speed Field (16-bit PC Card only).................................................................................3 2
3.2.2.1.2 The Device Size Byte (For Tuples CISTPL_DEVICE, CISTPL_DEVICE_A)............................3 3
3.2.3 CISTPL_DEVICE_OC, CISTPL_DEVICE_OA: The Other Conditions Device information Tuples.........3 4
3.2.3.1 Other Conditions Info Field..................................................................................................................................3 4
3.2.4 CISTPL_DEVICEGEO, CISTPL_DEVICEGEO_A: Device Geometry Tuples..................................................3 6
3.2.5 CISTPL_EXTDEVICE: The Extended Common Memory Device Information Tuple...................................3 8
3.2.5.1 Memory Paging Info Field ....................................................................................................................................3 8
3.2.5.2 Device Info fields (for tuple CISTPL_EXTDEVICE)....................................................................................3 9
3.2.5.2.1 Device ID fields ...............................................................................................................................................4 0
3.2.5.2.2 The Device Size Byte(s) (For Tuple CISTPL_EXTDEVICE)............................................................4 0
3.2.5.2.2.1 Device Memory Size £ 64 MBytes ...............................................................................................4 0
3.2.5.2.2.2 Device Memory Size > 64 MBytes ...............................................................................................4 1
3.2.5.3 Tuple Examples for Memory Device Size > 64 MBytes.............................................................................4 3
3.2.6 CISTPL_FUNCE: Function Extension Tuple..................................................................................................................4 5
3.2.6.1 Function Extension Tuples for Serial Ports.....................................................................................................4 5
3.2.6.1.1 Serial Port Interface Function Extension................................................................................................4 6
3.2.6.1.2 Function Extension Tuple for Modem and ISDN Interface.............................................................4 8
3.2.6.1.3 Function Extension Tuple for Data Modem.........................................................................................4 9
3.2.6.1.4 Function Extension Tuple for Document Facsimile ...........................................................................5 3
3.2.6.1.5 Function Extension Tuple for Voice Function ......................................................................................5 6
3.2.6.1.6 Function Extension Tuple for ISDN Terminal Adapter ...................................................................5 8
3.2.6.2 Function Extension Tuple for Disk.....................................................................................................................6 3
3.2.6.3 Function Extension Tuple for LAN ....................................................................................................................6 6
3.2.6.3.1 LAN_TECH Function Extension Tuple ..................................................................................................6 7
3.2.6.3.2 LAN_SPEED Function Extension Tuple................................................................................................6 7
3.2.6.3.3 LAN_MEDIA Function Extension Tuple...............................................................................................6 7
3.2.6.3.4 LAN_NID Function Extension Tuple ......................................................................................................6 8
3.2.6.3.5 LAN_CONN Function Extension Tuple .................................................................................................6 8
3.2.6.4 Function Extension Tuple for ISDN...................................................................................................................6 8
3.2.6.4.1 ISDN_TECH Function Extension Tuple .................................................................................................6 9
3.2.6.5 Function Extension Tuple for Serial I/O Bus Adapter...............................................................................6 9
3.2.7 CISTPL_FUNCID: Function Identification Tuple ........................................................................................................7 2
3.2.8 CISTPL_JEDEC_C, CISTPL_JEDEC_A: The JEDEC Identifier Tuples................................................................7 4
3.2.9 CISTPL_MANFID: Manufacturer Identification Tuple............................................................................................7 6
3.2.10 CISTPL_VERS_1: The Level 1 Version / Product Information Tuple ..............................................................7 7
3.3 Configuration Tuples ........................................................................................................78

3.3.1 CISTPL_BAR: CardBus PC Card Base Address Register Tuple............................................................................7 9
3.3.2 CISTPL_CFTABLE_ENTRY: 16-bit PC Card Configuration Table Entry Tuple ............................................8 0
3.3.2.1 TPCE_INDX: The Configuration Table Index Byte......................................................................................8 0
3.3.2.2 TPCE_IF: Interface Description Field................................................................................................................8 1
3.3.2.3 TPCE_FS: Feature Selection Byte ........................................................................................................................8 2
3.3.2.4 TPCE_PD: Power Description Structure ..........................................................................................................8 4
3.3.2.5 TPCE_TD: Configuration Timing Information.............................................................................................8 6
3.3.2.6 TPCE_IO: I/O Space Addresses Required For This Configuration.......................................................8 7
3.3.2.6.1 I/O Space Encoding Guidelines................................................................................................................8 9
3.3.2.7 TPCE_IR: Interrupt Request Description Structure......................................................................................9 1
3.3.2.8 TPCE_MS: Memory Space Description Structure ........................................................................................9 2
3.3.2.9 TPCE_MI: Miscellaneous Features Field.........................................................................................................9 3
3.3.2.10 TPCE_ST: Additional information in subtuple format...........................................................................9 4
3.3.2.10.1 STCE_EV: Environment Descriptor Subtuple...................................................................................9 4
3.3.2.10.2 STCE_PD: Physical Device Name Subtuple........................................................................................9 5
3.3.2.10.3 Additional I/O Feature Definitions within Entry...........................................................................9 5
3.3.3 CISTPL_CFTABLE_ENTRY_CB: CardBus PC Card Configuration Table Entry Tuple..............................9 6
3.3.3.1 TPCE_INDX: The Configuration Table Index Byte......................................................................................9 6
3.3.3.2 TPCE_CBFS: Feature Selection Byte ..................................................................................................................9 7
3.3.3.3 TPCE_PD: Power Description Structure ..........................................................................................................9 8
3.3.3.4 TPCE_CBIO: I/O Base Address Registers Used...........................................................................................9 8
3.3.3.5 TPCE_IR: Interrupt Request Description Structure......................................................................................9 8
3.3.3.6 TPCE_CBMS: Memory Base Address Registers Used...............................................................................9 8
3.3.3.7 TPCE_CBMI: CardBus PC Card Miscellaneous Features Field..............................................................9 9
3.3.3.8 TPCE_ST: Additional information in subtuple format ..........................................................................100
3.3.4 CISTPL_CONFIG: 16-bit PC Card Configuration Tuple........................................................................................101
3.3.4.1 TPCC_SZ: Size of Fields Byte............................................................................................................................102
3.3.4.2 TPCC_LAST: Card Configuration Table Last Entry Index...................................................................102
3.3.4.3 TPCC_RADR: Configuration Registers Base Address in Attribute Space .......................................102
3.3.4.4 TPCC_RMSK: Configuration Register Presence Mask Field for Interface Tuple...........................103
3.3.4.5 TPCC_SBTPL: Configuration tuple Sub-tuples...........................................................................................103
3.3.4.5.1 CCSTPL_CIF: Custom Interface Subtuples.........................................................................................103
3.3.5 CISTPL_CONFIG_CB: CardBus PC Card Configuration Tuple.........................................................................105
3.3.5.1 TPCC_SZ: Size of Fields Byte............................................................................................................................105
3.3.5.2 TPCC_LAST: Card Configuration Table Last Entry Index...................................................................105
3.3.5.3 TPCC_ADDR: CardBus PC Card Status Register Pointer......................................................................106
3.3.5.4 TPCC_SBTPL: Additional Information Stored in Tuple Format........................................................106
3.3.6 CISTPL_PWR_MGMNT: Function State Save/Restore Definition....................................................................106
4. Data Recording Formats (Layer 2) ______________________ 109

4.1 Card Information Tuples ................................................................................................109
4.1.1 CISTPL_BATTERY: The Battery-Replacement Date Tuple ..................................................................................110
4.1.2 CISTPL_DATE: The Card Initialization Date Tuple ..............................................................................................111
4.1.3 CISTPL_VERS_2: The Level-2 Version and Information Tuple.........................................................................112
CONTENTS
4.2 Data Recording Format Tuples.......................................................................................114

4.2.1 CISTPL_BYTEORDER: The Byte-Order Tuple.........................................................................................................115
4.2.2 CISTPL_FORMAT, CISTPL_FORMAT_A: The Format Tuples.........................................................................116
4.2.2.1 The Format Tuple for Disk-like Regions.......................................................................................................117
4.2.2.2 The Format Tuple for Memory-like Regions...............................................................................................118
4.2.2.3 Arithmetic Checksums As Error-Detection Codes....................................................................................120
4.2.2.4 CRC Error-Detection Codes............................................................................................................................... 120
4.2.2.5 Byte Mapping for Disk-Like Media ...............................................................................................................120
4.2.3 CISTPL_GEOMETRY: The Geometry Tuple..............................................................................................................121
4.2.4 CISTPL_SWIL: Software Interleave Tuple..................................................................................................................122
4.3 Standard Data Recording Formats.................................................................................123

4.4 Mixed Data Formats .......................................................................................................123
5. Data Organization (Layer 3) ___________________________ 125

5.1 Data Organization Tuples ..............................................................................................125
5.1.1 CISTPL_ORG: The Organization Tuple.......................................................................................................................126
6. System-Specific Standards (Layer 4)____________________ 129

6.1 System-Specific Standard Tuples...................................................................................129
6.1.1 CISTPL_SPCL: Special Purpose Tuple ..........................................................................................................................129
7. Compatibility Issues _________________________________ 131

7.1 Buffer Pages.....................................................................................................................131
7.2 Media Storage Formats ...................................................................................................131
vi © 1999 PCMCIA/JEIDA
TABLES
Table 2-1 Basic Tuple Format.........................................................................................................4
Table 2-2 Global CIS for Multiple Function PC Cards...................................................................6
Table 2-3 Function-specific CIS for Multiple Function PC Cards .................................................6
Table 2-4: Minimal CIS for Indirect Memory Access PC Cards ....................................................9
Table 2-5 Tuple Summary Table ..................................................................................................12
Table 2-6 Tuple Summary Table (Numerically by Tuple Code) .................................................14
Table 3-1 CISTPL_CHECKSUM: Checksum Tuple.....................................................................18
Table 3-2 CISTPL_END: End of Chain Tuple..............................................................................19
Table 3-3: CISTPL_INDIRECT: Indirect Access PC Card Memory............................................20
Table 3-4 CISTPL_LINKTARGET: Link Target Tuple ................................................................21
Table 3-5 CISTPL_LONGLINK_A and CISTPL_LONGLINK_C: 16-bit PC Card LongLink
Tuples ................................................................................................................................22
Table 3-6 CISTPL_LONGLINK_CB: The CardBus PC Card LongLink Tuple...........................23
Table 3-7 CISTPL_LONGLINK_MFC: The Multiple Function 16-bit PC Card Link Tuple.......25
Table 3-8 CISTPL_NO_LINK: The No-Link Tuple......................................................................26
Table 3-9 CISTPL_NULL: The Null Tuple...................................................................................27
Table 3-10 CISTPL_ALTSTR: The Alternate Language String Tuple.........................................28
Table 3-11 CISTPL_DEVICE, CISTPL_DEVICE_A: The 5 volt Device information Tuples.....29
Table 3-12 CISTPL_DEVICE_OC, CISTPL_DEVICE_OA: The Other Conditions Device
information Tuples............................................................................................................34
Table 3-13 CISTPL_DEVICEGEO and CISTPL_DEVICEGEO_A: Device Geometry Tuples ...36
Table 3-14 CISTPL_EXTDEVICE: The Extended Common Memory Device information Tuples
............................................................................................................................................38
Table 3-15 CISTPL_FUNCE: Function Extension Tuple .............................................................45
Table 3-16 CISTPL_FUNCE: Serial Port Interface Function Extension Tuple............................47
Table 3-17 CISTPL_FUNCE: Modem and ISDN Interface Function Extension Tuple...............48
Table 3-18 CISTPL_FUNCE: Data Modem Function Extension Tuple ......................................50
Table 3-19 CISTPL_FUNCE: TPCID_FF: Document Facsimile Function Extension Tuple .......54
Table 3-20 CISTPL_FUNCE: Voice Function Extension Tuple ...................................................56
Table 3-21: CISTPL_FUNCE: ISDN Function Extension Tuple ..................................................59
Table 3-22 CISTPL_FUNCE: Disk Function Extension Tuple.....................................................64
Table 3-23 CISTPL_FUNCE: Combined PC Card ATA Function Extension Tuple...................64

TABLES
Table 3-24 CISTPL_FUNCE: Dual-Drive Card PC Card ATA Function Extension Tuple........66
Table 3-25 CISTPL_FUNCE: LAN Function Extension Tuple....................................................66
Table 3-26 CISTPL_FUNCE: LAN_TECH Function Extension Tuple........................................67
Table 3-27 CISTPL_FUNCE: LAN_SPEED Function Extension Tuple ......................................67
Table 3-28 CISTPL_FUNCE: LAN_MEDIA Function Extension Tuple.....................................67
Table 3-29 CISTPL_FUNCE: LAN_NID Function Extension Tuple...........................................68
Table 3-30 CISTPL_FUNCE: LAN_CONN Function Extension Tuple ......................................68
Table 3-31: CISTPL_FUNCE: ISDN Function Extension Tuple ..................................................69
Table 3-32: CISTPL_FUNCE: 1394 Serial I/O Bus Adapter Function Extension Tuple ...........69
Table 3-33: CISTPL_FUNCE: USB Serial I/O Bus Adapter Function Extension Tuple ............70
Table 3-34 CISTPL_FUNCID: Function Identification Tuple .....................................................72
Table 3-35 CISTPL_JEDEC_C and CISTPL_JEDEC _A: JEDEC Identifier Tuples...................74
Table 3-36 CISTPL_MANFID: Manufacturer Identification Tuple ............................................76
Table 3-37 CISTPL_VERS_1: Level 1 Version / Product Information Tuple .............................77
Table 3-38 CISTPL_BAR: CardBus PC Card Base Address Register Tuple ..............................79
Table 3-39 CISTPL_CFTABLE_ENTRY: Configuration Table Entry Tuple ...............................80
Table 3-40 CISTPL_CFTABLE_ENTRY_CB: CardBus PC Card Configuration Table Entry
Tuple..................................................................................................................................96
Table 3-41 CISTPL_CONFIG : 16-bit PC Card Configuration Tuple .......................................101
Table 3-42 CISTPL_CONFIG_CB: CardBus PC Card Configuration Tuple ............................105
Table 3-43 CISTPL_PWR_MGMNT: Function State Save/Restore Definition .........................107
Table 4Ð1 CISTPL_BATTERY: Battery Replacement Date Tuple.............................................110
Table 4Ð2 CISTPL_DATE: Card Initialization Date Tuple.......................................................111
Table 4Ð3 CISTPL_VERS_2: Level-2 Information Tuple...........................................................112
Table 4Ð4 CISTPL_BYTEORDER: Byte Order Tuple.................................................................115
Table 4Ð5 CISTPL_FORMAT and CISTPL_FORMAT_A: Format Tuples...............................116
Table 4Ð6 Format Tuple for Disk-like Regions...........................................................................117
Table 4Ð7 Format Tuple for Memory-like Regions.....................................................................119
Table 4Ð8 CISTPL_GEOMETRY: Geometry Tuple ....................................................................121
Table 4Ð9 CISTPL_SWIL: Software Interleave Tuple................................................................122
Table 5Ð1 CISTPL_ORG: Data Organization Tuple..................................................................126
Table 6Ð1 CISTPL_SPCL: Special Purpose Tuple .....................................................................129
viii © 1999 PCMCIA/JEIDA

1.1 Purpose
This specification provides information necessary for implementing the Card Information Structure
(CIS), or Metaformat, on PC Cards and for interpreting the metaformat for the purposes of
configuring and utilizing PC Cards.
1.2 Scope
It is recommended that all aspects of a PC Card which can be described in CIS be so described. Full
disclosure of a PC CardÕs characteristics in the CIS is a basic component of compatibility and
interchangeability.
1.3 Related Documents

PC Card Standard Release 7.0 (February 1999), PCMCIA /JEIDA
Volume 11: PC Card Host System Specification
IEEE 1394-1995 Specification, IEEE
2. O V E R V IE W
2.1 Metaformat Overview

Metaformat goals include the ability to handle numerous, somewhat incompatible data-recording
formats and data organizations. As is done with networking standards, the Metaformat is a
hierarchy of layers. Each layer has a number, which increases as the level of abstraction gets
higher. Below the Metaformat is the physical layer, the electrical and physical interface
characteristics of PC Cards. (See the Physical Specification and the Electrical Specification.)
The Metaformat layers are:
1. The Basic Compatibility Layer Ñ specifies a minimal level of card-data organization. Tuples at
this level provide fundamental information about the PC Card including supported
configurations, manufacturer, and individual device characteristics, such as size, speed, and
programming information.
2. The Data Recording Format Layer Ñ includes tuples which describe partitioning information
and provide card initialization information.
3. 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).
4. 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 any tuple in the vendor-unique range is not documented
within the Standard.
2.2 Metaformat Requirements

The PC Card Standard has the following Card Information Structure (CIS) requirements:
· All PC Cards shall have a CIS that describes the functionality and characteristics of the card.
· The CIS of a 16-bit PC Card shall be readable whenever the card is powered, the card is
asserting READY and the card has been reset by the host after power-up in accordance with the
PC Card Standard. This includes after the PC Card is configured and when the PwrDwn bit is
set in the Card Configuration and Status Register. (See the Electrical Specification.)
· The CIS of a CardBus PC Card shall be readable whenever the card is powered and the power
up process has been completed. (See the Electrical Specification.)
· All linear memory PC Cards shall describe how they are partitioned, even if the entire PC Card
is used as a single partition. (See the Media Storage Formats Specification.)
· All ATA PC Cards shall be formatted with a Master Boot Record (MBR) in the first physical
sector of the media. The MBR shall contain a partition table describing how the media is
partitioned. (See the Media Storage Formats Specification.)
OVERVIEW
2.3 Metaformat Architecture
2.3.1 Basic Tuple Format and Tuple Chain Structure

The Card Information Structure is one or more chains (or linked lists) of data blocks or tuples.
Longlink and linktarget tuples are used to connect chains (See 3.1 Control Tuples.) All tuples have
the format shown below.
Table 2-1 Basic Tuple Format

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE Tuple code: CISTPL_xxx.
1 TPL_LINK Offset to next tuple in chain. This is the number of bytes in the tuple body. (n)
2áá(n + 2) The tuple body. (n bytes)
Byte 0 of each tuple contains a tuple code. A tuple code of FFH is a special mark indicating that
there are no more tuples in the chain. Byte 1 of each tuple contains a link to the next tuple in the
chain. If the link field is zero, then the tuple body is empty. If the link field of a 16-bit PC Card
contains FFH, then this tuple is the last tuple in its chain.
There are two ways of marking the end of a tuple chain for 16-bit PC Cards: a tuple code of FFH, or
a tuple link of FFH. There is only one way of marking the end of the tuple chain for CardBus PC
Cards: A tuple code of FFH. (See also 2.3.8 16-bit PC Card Tuple Chain Processing and 2.3.9
CardBus PC Card Tuple Chain Processing.)
The use of an FFH link value is allowed in 16-bit PC Cards for backward compatibility, but it is
recommended to use the End of Chain tuple. System software must use the link field to validate
tuples. No 16-bit PC Card tuple can be longer than 257 bytes: 1 byte TPL_CODE + 1 byte
TPL_LINK + FFH byte tuple body (and this 257 byte tuple ends the chain). No CardBus PC Card
tuple can be longer than 256 bytes: 1 byte TPL_CODE + 1 byte TPL_LINK + FEH byte tuple body.
Some tuples provide a termination or stop byte that marks the end of the tuple. In this case, the
tuple can effectively be shorter than the value implied by its link field. However, software must not
scan beyond the implied length of the tuple, even if a termination byte has not been seen.
2.3.2 Byte Order Within Tuples

Within tuples, all multi-byte numeric data shall be recorded in little-endian order. That is, the least-
significant byte of a data item shall be stored in the first byte of a given field.
Within tuples, all character data shall be stored in the natural order. That is, the first character of the
field shall be stored in the first byte of the field. Fixed-length character fields shall be padded with
null characters, if necessary.
2.3.3 Byte Order on Wide Cards

If a card has a data path wider than 8-bits, one must assign a byte order to the data path. This
applies to all CardBus PC Card CISÕs and to those fields within a 16-bit PC Card CIS that are
recorded in Common Memory space. At present, Attribute Memory Space is byte-wide only; only
the even bytes are present. This standard requires that the low-order byte of word 0 be used to
record byte 0 of the CIS. Ascending bytes of each word shall be used to sequentially record bytes
from the CIS. When the first word is filled, the same process shall be repeated on subsequent words
until the entire CIS is recorded. On x86 architecture machines, this byte order is equivalent to the
native order; other machines may need to reorder the bytes when reading or writing the CIS.
The basic compatibility layer does not impose any particular byte order on non-header portions of
the card. However, some data-format layers impose further requirements.
2.3.4 16-bit PC Card Metaformat in Attribute Memory Space

16-bit PC Cards have two address spaces: Attribute Memory space and Common Memory space.
The electrical specification for 16-bit PC Cards requires that information be placed only in even-byte
addresses of Attribute Memory space. The contents of odd-byte addresses of Attribute Memory
space are not defined.
For simplicity, this specification describes the tuples of the Metaformat as if the bytes of each tuple
were recorded consecutively. When a tuple is recorded in Common Memory space of a 16-bit PC
Card, the bytes will indeed be recorded consecutively. However, when a tuple is recorded in
Attribute Memory space, the data will be recorded in even bytes only.
Link fields of tuples stored in Attribute Memory space are handled as follows. If only the even bytes
are read, and the tuples are packed into consecutive bytes in system memory, the link fields shall
be set appropriately for byte addressing. This means that the link-field values are conceptually the
same whether a tuple resides in Common or in Attribute memory. However, this does mean that if
Attribute Memory is directly addressed, the offset to the next tuple in Attribute Memory is two
times the link field.
2.3.5 16-bit PC Card Metaformat in Common Memory Space

For cost reasons, many 16-bit PC Cards, such as ROM cards, will not implement a separate Attribute
Memory space. On these cards, regardless of the state of the REG# line, memory cycles always
access Common Memory. These cards provide an Attribute Memory-style CIS starting at byte zero
of the card, and recorded in even bytes only. If, for space reasons, the manufacturer wants to switch
to a Common Memory-style CIS (packed into ascending bytes), a long link to Common Memory
shall be embedded in the CIS. The Common Memory CIS may be stored immediately following the
Attribute Memory CIS.
It is important to distinguish between Attribute Memory space and Attribute Memory. All 16-bit PC
Cards will have Attribute Memory space, accessed by asserting the REG# pin. In addition, some 16-
bit PC Cards will have a distinct physical Attribute Memory. In this case, the contents of location 0
in Attribute Memory space will be different and distinct from the contents of location 0 in Common
Memory space. However, some 16-bit PC Cards will not have Attribute Memory distinct from
Common Memory. Here, memory-read operations from a given location in Attribute Memory space
will return the same data as read operations from the same location in Common Memory space.
Data accessed from Attribute Memory space must be stored in the even bytes only, even if
Attribute Memory is not distinct from Common Memory. Regardless of the presence or absence of
Attribute Memory, the CIS for 16-bit PC Cards always begins at location 0 of Attribute Memory
space.
This standard allows attribute information to be stored both in Attribute Memory and Common-
Memory space. Tuples stored in Common Memory space are recorded in sequential bytes. Both the
card's even and the odd bytes are used to record data.
OVERVIEW
Note: The use of odd bytes to represent tuple data is controlled by the logical-
address space in which the tuple resides, not by the type of memory
actually used to record the tuple. If the tuple is intended to be accessed in
Attribute Memory space, it must be stored only in the even bytes. If it is
intended to be accessed in Common Memory space, it must be stored in
both even and odd bytes following a longlink target.
2.3.6 16-bit PC Card Metaformat for Multiple Function Cards

Multiple function 16-bit PC Cards shall contain multiple Card Information Structures (CIS). The first
or global CIS on a 16-bit PC Card shall identify the card as containing multiple functions by the
presence of a CISTPL_LONGLINK_MFC tuple. The 16-bit PC Card shall also contain a separate
function-specific CIS for each set of Configuration Registers on the card.
The starting location of each function-specific CIS is given in a single CISTPL_LONGLINK_MFC
tuple in the global CIS. Each function-specific CIS begins with a CISTPL_LINKTARGET tuple.
The global CIS on a multiple function 16-bit PC Card shall contain the following tuples.
Note: A CISTPL_FUNCID with a TPLFID_FUNCTION field reset to zero (0) shall
not be placed in the CIS of a Multiple Function PC Card. This tuple is
reserved for vendor-specific multiple function PC Cards that do not follow
the multiple function PC Card definitions in this specification.
Table 2-2 Global CIS for Multiple Function PC Cards

Tuple Code Presence
CISTPL_DEVICE 01H Mandatory (if PC Card has 5 volt key)
CISTPL_EXTDEVICE 09H Mandatory (if PC Card has > 64
MBytes of common memory)
CISTPL_DEVICE_OC 1CH Recommended
CISTPL_LONGLINK_MFC 06H Mandatory
CISTPL_VERS_1 15H Mandatory
CISTPL_MANFID 20H Mandatory
CISTPL_END FFH Mandatory
There is a function-specific Card Information Structure for each function on a Multiple Function PC
Card. The following tuples are contained in each function-specific CIS.
Table 2-3 Function-specific CIS for Multiple Function PC Cards

Tuple Code Presence
CISTPL_LINKTARGET 13H Mandatory
CISTPL_CONFIG 1AH Mandatory
CISTPL_CFTABLE_ENTRY 1BH Mandatory
CISTPL_FUNCID 21H Recommended
CISTPL_FUNCE 22H Recommended
CISTPL_END FFH Mandatory
2.3.7 CardBus PC Card Metaformat

There is one CIS per card function, which may consist of multiple tuple chains in different spaces.
Tuple chains may be located in any of the card space with the exception of I/O space. All tuple
chains must start with a CISTPL_LINKTARGET tuple aligned on a four word boundary, but
subsequent tuples within a chain need not be so aligned. The beginning of the function's CIS is
pointed to by the CIS Pointer in the function's configuration space header. If the functionÕs CIS does
not complete in the current chain, the location of the next tuple chain is indicated by a
CISTPL_LONGLINK_CB. Tuple chains can be located in the following card spaces:
· Configuration Space. Tuple chains in configuration space may only be placed in the device
dependent region.
· Memory Space. Tuple chains may be located anywhere within memory space.
· Expansion ROM. Tuple chains may appear in any of the images in an expansion ROM, but no
single chain shall span multiple images. The formats of the CIS Pointer and the Address-Space-
Offset field of the CISTPL_LONGLINK_CB allow specifying a twenty-eight bit offset from the
base of any of the first sixteen images in the expansion ROM. The chain need not be located in
the image on which the offset is based, allowing chains to be placed in images beyond the first
sixteen.
Multi-function CardBus PC Cards have an independent configuration space and CIS for each
function. Requiring a CIS for each function allows each function to be generically described and
helps in delivering such things as function specific executables in the expansion ROM associated
with the function. This also allows functions to be individually manufactured, independent of their
eventual placement on a CardBus PC Card.
2.3.8 16-bit PC Card Tuple Chain Processing

The information block must be located such that it can be easily found by low-level software. This
Standard requires that the primary CIS of a 16-bit PC Card be recorded in Attribute Memory
starting at address zero (00H).
The first tuple in the primary CIS chain of a 16-bit PC Card with a 5 volt key must be either a
CISTPL_DEVICE (tuple code 01H), a CISTPL_NULL (tuple code 00H), or an CISTPL_END (tuple code
FFH, see 3.1.2 CISTPL_END: The End Of Chain Tuple for processing). The CISTPL_DEVICE (tuple
code 01H) must be the first non-control tuple found when traversing the chain(s).
It is recommended that 16-bit PC Cards using a low voltage key begin the primary CIS chain with a
CISTPL_LINKTARGET (tuple code 13H). Low voltage keyed cards shall omit the CISTPL_DEVICE
(tuple code 01H) or shall include a CISTPL_DEVICE with NULL Device Info fields.
Cards with > 64 MBytes of Common Memory must contain the tuple CISTPL_EXTDEVICE (tuple
code 09H).
For flexibility, the CIS of a 16-bit PC Card can be extended into Common Memory. To facilitate
automatic identification of ÒblankÓ cards, Attribute Memory can be read-only memory.
It is expected that the CIS will be written once when the card is manufactured (or formatted) and
then infrequently updated. On any PC Card that expects or requires the CIS to be erased (for
example a Flash or EEPROM technology card that erases the CIS area when it is reorganized), it is
suggested that problems of process interruption and disaster recovery be addressed. These issues
are beyond the scope of the Standard.
Note that most implementations will be limited to reading cards of a specific format, or at most, of a
few different formats. Thus, many combinations of values available in the tuples will be non-
OVERVIEW
portable. It is recommended that implementers restrict themselves to the suggested low-level

formats defined in the Media Storage Formats Specification.
2.3.9 CardBus PC Card Tuple Chain Processing

The recommended method of traversing a CardBus PC Card CIS is to use the Card Services
GetFirstTuple/GetNextTuple interface. When a client does this, Card Services will decode any long
link tuples for the client. The beginning of each function's CIS is indicated by the CIS Pointer in
that function's configuration space header. The Address Space Indicator field indicates in which space
the CIS begins and the Address Space Offset field gives the offset into that space for the memory
spaces and the expansion ROM space. For the configuration space, the Address Space Offset field
gives the absolute address in device-dependent configuration space. (See also the Electrical
Specification and 3.1.6 CISTPL_LONGLINK_CB: The CardBus PC Card LongLink Tuple.)
Each tuple chain on a CardBus PC Card must begin with a CISTPL_LINKTARGET (tuple code 13H).
It may contain one CISTPL_LONGLINK_CB (tuple code 05H) to another tuple chain in the current
space or another space. The CISTPL_LONGLINK_CB tuple allows the placement of tuple chains in
configuration space, memory space, or the expansion ROM.
Traversing a CardBus PC Card's CIS(s) is the same as traversing that of a 16-bit PC Card, with the
following exceptions:
1. There is a separate CIS for each card function.
2. For a given function, the beginning of the CIS is pointed to by the CIS Pointer.
3. All tuple chains, including the first one, begin with a CISTPL_LINKTARGET tuple.
4. The encoding of the CISTPL_LONGLINK_CB address matches that of the CIS Pointer.
The client requests tuples from each function's CIS by specifying the logical function number (0
through 7).
2.3.10 Tuple Processing Recommendations

This standard requires that system software be carefully coded in order to prevent incompatibilities
from one system to another. The following are some specific recommendations.
The routine that reads a given tuple should be coded to start by examining the tuple code. If the
tuple code is not recognized by the routine (e.g. if the code is vendor specific or represents an
extension under a future standard), then the tuple should be ignored. If the code is not recognized,
it is safe to read the code byte and the link byte. However, other bytes within the tuple may
represent active registers.
2.3.10.1 Tuple Code Known

If the tuple code is known, and if the tuple does not contain active registers (which is the case for all
standard tuples), then the routine should copy bytes into a buffer in main storage. Bytes should be
copied from the code byte up to the last byte before the next tuple. If the link field is FF H (which
also means end-of-chain and is only allowed for a 16-bit PC Card) then a maximum of 257 bytes Ñ
the code byte, the link byte and as many as 255 bytes of tuple data Ñ should be copied from the
card to the main store.
2.3.10.2 Processing Longlink Tuple

When processing a longlink tuple (CISTPL_LONGLINK_A, _C, _CB), software should merely record
the target address and address space. The software should not validate the target address, nor
should it immediately begin processing of tuples from the target address. Similarly, when a no-link
tuple (CISTPL_NO_LINK) is found, that fact should be recorded for later use.
Longlink and no-link tuples should be processed after reaching the end of the tuple chain. At that
time, if a longlink is to be processed, software should validate the target address (by checking for a
CISTPL_LINKTARGET tuple) and begin processing the target chain if it appears to be valid.
2.3.10.3 Longlink Pointing to Invalid Tuple Chain

A longlink that points to an invalid tuple chain should not usually cause any diagnostic messages to
be displayed to the user. This situation may result from an uninitialized card, from a card which
was initialized for some unanticipated use, or from corrupted data. Since only the corrupted data
case merits a diagnostic message, it is better to assume either that the card is uninitialized, or that it
is initialized in some non-conforming way.
2.3.11 16-bit PC Card CIS with Indirect Access PC Card Memory

16-bit PC Cards with very limited Attribute and Common Memory spaces can utilize an optional,
Common Memory register-based indirect access mechanism. (See the Electrical Specification.) Using
this indirect access method these cards provide full disclosure of their capabilities and attributes by
extending their CIS into the indirect space(s). In all cases, a minimal legal CIS must be placed in the
standard Attribute and Common Memory spaces.
The CISTPL_INDIRECT tuple is used to indicate the presence of indirect access registers. After
processing tuple chains in the Attribute and Common memory spaces, tuple processing follows the
implied link indicated by the CISTPL_INDIRECT tuple to the indirect Attribute and indirect
Common spaces. Once tuple processing begins in the indirect spaces there is no return link to the
direct access spaces. This means that all longlink tuples placed in the indirect spaces refer to the
indirect spaces, i.e. a CISTPL_LONGLINK_A refers to indirect Attribute memory.
Tuple processing in the indirect spaces follows the previously stated rules for processing tuples on
all 16-bit PC Cards. For example, the implied link goes first to the indirect Attribute space where a
CISTPL_LINKTARGET should be located at indirect Attribute address zero. There is an implied link
to indirect Common address zero if there is no tuple chain at indirect Attribute address zero.
An example of a minimal, but legally sufficient, Card Information Structure is shown in the table
below.
Table 2-4: Minimal CIS for Indirect Memory Access PC Cards

Address Space / Offset Tuple Values
Attribute / 00H CISTPL_DEVICE 01H 02H 00H FFH
Attribute / 08H CISTPL_INDIRECT 03H 00H
Attribute / 0CH CISTPL_END FFH
Common / 00H CISTPL_END FFH
OVERVIEW
2.4 Metaformat Summary
2.4.1 Metaformat Layer Hierarchy

1. The Basic Compatibility Layer Ñ Fundamental information about the card's physical devices
and configurations.
2. The Data Recording Format Layer Ñ Specifies how data on a card which is used for data
storage is organized at the lowest level.
3. The Data Organization Layer Ñ Specifies how data on a card which is used for data storage is
logically organized.
4. The System-Specific Layer Ñ Includes tuples that by their nature are specific to a particular
operating environment or vendor implementation.
2.4.2 Tuple Code Summary

The following table provides a summary of all curent tuples and an indicator of the types of cards or
the classes of functions where they are used.
The columns are:
Tuple Code the numeric code assigned to the tuple.
Name the name which uniquely identifies the tuple.
Description a brief statement of the tuple's intended use.
First Pub First Published - reference indicates when this tuple definition was first published.
CardBus notes for CardBus PC Cards.
16-bit PC Card
all notes applying to 16-bit PC Cards in general Ñ NA here applies also to all other 16-bit PC
Card columns.
MEM Memory - 16-bit PC Cards providing either disk-like or memory-like data storage.
CFG Configurable - 16-bit PC Cards having configuration and status registers.
MFC Multiple Function PC Card - notes for Multiple Function 16-bit PC Cards.
5 Volt Key notes for 16-bit PC Cards which operate at 5 Volts VCC.
Low Volt Key Low Voltage - notes for 16-bit PC Cards which operate at 3.3 Volts or X.X Volts VCC.
Column Entries:
R Ñ Recommended
M Ñ Mandatory
NA Ñ Never, Not Applicable
S Ñ Single Instance Only per Function-Chain; or Main-Chain in 16-bit MFC; or per region/partition definition;
or base address register description
1 Ñ first published PCMCIA 1.0 / JEIDA 4.0
4 Ñ first published PC Card Standard, February 1995
5 Ñ recommended for use as appropriate
6 Ñ required in cards capable of operating at voltages other than 5 V VCC
7 Ñ recommended for use when applicable values (IDs and extensions) exist
8 Ñ not recommended, requires NULL Device Info fields
9 Ñ first published PC Card Standard, November 1995

10 Ñ first published PC Card Standard March 1997
11 Ñ first published PC Card Standard February 1999
12 Ñ mandatory for cards with >64 Mbytes of Common Memory
OVERVIEW
Table 2-5 Tuple Summary Table

16-bit PC Card
Tuple Tuple Name Description 1st Card M C M 5 Low
Code Pub Bus all E F F Volt Volt
PC M G C Key Key
Card
Layer 1: Basic Compatibility Tuples
Control Tuples
10H CISTPL_CHECKSUM Checksum control. 1
FFH CISTPL_END The end-of-chain tuple. 1 M, 4 R, 3
03H CISTPL_INDIRECT Indirect Access PC Card Memory 9 S S
13H CISTPL_LINKTARGET Link-target-control. 1 M,4,S S M, 4 R, 4
11H CISTPL_LONGLINK_A Longlink to Attribute Memory. 1 NA S
12H CISTPL_LONGLINK_C Longlink to Common Memory. 1 NA S
02H CISTPL_LONGLINK_CB Longlink to next chain on a CardBus 4 NA
PC Card.
06H CISTPL_LONGLINK_MFC Longlink to function specific chain(s) 4 NA S M, 4
on a Multiple Function PC Card.
14H CISTPL_NO_LINK No-link to Common Memory. 1 NA S
00H CISTPL_NULL Null tuple - ignore. 1
Basic Compatibility Tuples
16H CISTPL_ALTSTR Alternate-language-string. 1
01H CISTPL_DEVICE Common Memory device 1 NA S M,3 8
information.
17H CISTPL_DEVICE_A Attribute Memory device information. 1 NA S R,3 8
1DH CISTPL_DEVICE_OA Other operating conditions device 2 NA 5 5
information for Attribute Memory.
1CH CISTPL_DEVICE_OC Other operating conditions device 2 M, 4 5,6 M,4,
information for Common Memory. 6
1EH CISTPL_DEVICEGEO Device geometry information for 3 5,S S 5
Common Memory devices.
1FH CISTPL_DEVICEGEO_A Device geometry information for 3 5,S S 5
Attribute Memory devices.
09H CISTPL_EXTDEVICE Extended Common Memory device 11 NA 12
information
22H CISTPL_FUNCE Function Extensions. 3 7 7
21H CISTPL_FUNCID Function class identification. 3 7,S S 7
19H CISTPL_JEDEC_A JEDEC programming information for 1 NA 5,S
Attribute Memory.
18H CISTPL_JEDEC_C JEDEC programming information for 1 5,S 5,S
Common Memory.
20H CISTPL_MANFID Manufacturer Identification string. 3 M,4,S R,3,
M,4,
S
15H CISTPL_VERS_1 Level 1 version/product-information. 1 M,4,S M,4,
S
Table 2-5 Tuple Summary Table - Continued
Tuple 1st Card 16-bit PC Card

Code Tuple Name Description Pub Bus M C M 5 Low
PC all E F F Volt Volt
Card M G C Key Key
Layer 1: Basic Compatibility Tuples
Configuration Tuples
07H CISTPL_BAR Base Address Register definition 4 M,4,S NA
tuple for a CardBus PC Card.
1BH CISTPL_CFTABLE_ENTRY A Configuration-Table-Entry. 2 NA R,3, M,4
M,4
05H CISTPL_CFTABLE_ENTRY_CB A Configuration-Table-Entry for a 4 M,4 NA
CardBus PC Card function.
1AH CISTPL_CONFIG Configuration tuple for a 16-bit PC 4 NA S R,3, M,4
Card. M,4
04H CISTPL_CONFIG_CB Configuration tuple for a CardBus PC 4 M,4,S NA
Card function.
08H CISTPL_PWR_MGMNT Function state save/restore definition. 10 NA S
Layer 2: Data Recording Format Tuples
Card Information Tuples
45 H CISTPL_BATTERY Battery replacement date. 1 S S
44H CISTPL_DATE Card initialization date. 1 S S
40H CISTPL_VERS_2 Level-2 version tuple. 1 S S
Data Recording Format Tuples
43H CISTPL_BYTEORDER Byte ordering for disk-like partitions. 1 S S R,3
41H CISTPL_FORMAT Data recording format for Common 1 5,S 5,S
Memory
47H CISTPL_FORMAT_A Data recording format for Attribute 4 NA 5,S
Memory
42H CISTPL_GEOMETRY Partition geometry. 1 5,S 5,S
23H CISTPL_SWIL Software interleaving. 3 S S
Layer 3: Data Organization Tuples
46H CISTPL_ORG Partition organization. 1 5,S 5,S
Layer 4: System-Specific Standard Tuples
90H CISTPL_SPCL Special Purpose 4
80Háá8FH Vendor unique tuples 1
Available Tuple Codes
0AHáá0FH Reserved for future Layer 1 tuples.
24Háá3FH Reserved for future Layer 2 tuples.
91HááFEH Reserved for future Layer 4 tuples.
OVERVIEW
Table 2-6 Tuple Summary Table (Numerically by Tuple Code)

Code Name Description Metaformat Layer
00H CISTPL_NULL Null tuple - ignore. Layer 1: Control
01H CISTPL_DEVICE Common Memory device information. Layer 1: Basic Compatibility
02H CISTPL_LONGLINK_CB Longlink to next chain on a CardBus PC Card. Layer 1: Control
03H CISTPL_INDIRECT Indirect Access PC Card Memory. Layer 1: Control
04H CISTPL_CONFIG_CB Configuration tuple for a CardBus PC Card Layer 1: Configuration
function.
05H CISTPL_CFTABLE_ENTRY_CB A Configuration-Table-Entry for a CardBus PC Layer 1: Configuration
Card function.
06H CISTPL_LONGLINK_MFC Longlink to next chain on a Multiple Function card. Layer 1: Control
07H CISTPL_BAR Base Address Register definition tuple for a Layer 1: Configuration
CardBus PC Card.
08H CISTPL_PWR_MGMNT Function state save/restore definition. Layer 1: Configuration
09H CISTPL_EXTDEVICE Extended Common Memory device information Layer 1: Basic Compatibility
0AHáá0FH Reserved for future Layer 1 tuples.
10H CISTPL_CHECKSUM Checksum control. Layer 1: Control
11H CISTPL_LONGLINK_A Longlink to Attribute Memory. Layer 1: Control
12H CISTPL_LONGLINK_C Longlink to Common Memory. Layer 1: Control
13H CISTPL_LINKTARGET Link-target-control. Layer 1: Control
14H CISTPL_NO_LINK No-link to Common Memory. Layer 1: Control
15H CISTPL_VERS_1 Level 1 version/product-information. Layer 1: Basic Compatibility
16H CISTPL_ALTSTR Alternate-language-string. Layer 1: Basic Compatibility
17H CISTPL_DEVICE_A Attribute Memory device information. Layer 1: Basic Compatibility
18H CISTPL_JEDEC_C JEDEC programming information for Common Layer 1: Basic Compatibility
Memory.
19H CISTPL_JEDEC_A JEDEC programming information for Attribute Layer 1: Basic Compatibility
Memory.
1AH CISTPL_CONFIG Configuration tuple for a 16-bit PC Card. Layer 1: Configuration
1BH CISTPL_CFTABLE_ENTRY A Configuration-Table-Entry. Layer 1: Configuration
1CH CISTPL_DEVICE_OC Other operating conditions device information for Layer 1: Basic Compatibility
Common Memory.
1DH CISTPL_DEVICE_OA Other operating conditions device information for Layer 1: Basic Compatibility
Attribute Memory.
1EH CISTPL_DEVICEGEO Device geometry information for Common Layer 1: Basic Compatibility
Memory devices.
1FH CISTPL_DEVICEGEO_A Device geometry information for Attribute Memory Layer 1: Basic Compatibility
devices.
20H CISTPL_MANFID Manufacturer Identification string. Layer 1: Basic Compatibility
21H CISTPL_FUNCID Function class identification. Layer 1: Basic Compatibility
22H CISTPL_FUNCE Function Extensions. Layer 1: Basic Compatibility
23H CISTPL_SWIL Software interleaving. Layer 2: Data Recording
Format
40H CISTPL_VERS_2 Level-2 version tuple. Layer 2: Card Information
41H CISTPL_FORMAT Data recording format for Common Memory Layer 2: Data Recording
Format
Tuple Summary Table (Numerically by Tuple Code) - continued

Code Name Description Metaformat Layer
42H CISTPL_GEOMETRY Partition geometry. Layer 2: Data Recording
Format
43H CISTPL_BYTEORDER Byte ordering for disk-like partitions. Layer 2: Data Recording
Format
44H CISTPL_DATE Card initialization date. Layer 2: Card Information
45 H CISTPL_BATTERY Battery replacement date. Layer 2: Card Information
46H CISTPL_ORG Partition organization. Layer 3: Data Organization
47H CISTPL_FORMAT_A Data recording format for Attribute Memory Layer 2: Data Recording
Format
80Háá8FH Vendor unique tuples Layer 4: System-Specific
Standard
90H CISTPL_SPCL Special Purpose Layer 4: System-Specific
Standard
90HááFEH Reserved for future Layer 4 tuples.
FFH CISTPL_END The end-of-chain tuple. Layer 1: Control
2.5 Special Considerations
2.5.1 Vendor-Specific Information

Vendor-specific information allows card and software vendors to implement proprietary functions
while remaining within the general framework of this Standard.
Vendor-specific information is of two kinds:
· Vendor-specific fields are areas reserved in the data structures for free use by vendors. These
fields have no meaning to the standard software.
· Vendor-specific codes are encoding values reserved to represent non-standard values in
standard fields. In the absence of other information, standard software must interpret vendor-
specific codes as meaning Òthe information in this field is not specified.Ó
The card-manufacturer field in the CIS gives (knowledgeable) system software enough information
to interpret vendor-specific fields and code values in the card Physical-Description tuples.
Similarly, the OEM and INFO fields in the CISTPL_VERS_2 tuple give (knowledgeable) system
software enough information to interpret vendor-specific fields and code values in the card Logical-
Format tuples.
In general, a system will not be able to interpret all possible vendor-specific fields or code values.
2.5.2 System Rejection of Unsupported Cards

This standard requires the following behavior when a system encounters an unrecognized vendor-
specific field:
· If the unrecognized field itself is vendor-specific, the system shall ignore that field.
If a standard field contains an unrecognized vendor-specific code, the system must refuse to perform any
operation that requires the information encoded in that field.
3 . B A S I C C O M P AT I B I L I T Y ( L AY E R 1 )
This layer is the cornerstone of the Standard. All PC Cards shall have at least a rudimentary Card
Information Structure.
The CIS on 16-bit PC Cards must start at address zero of the card's Attribute Memory space.
Each function of a CardBus PC Card has a CIS Pointer field in configuration space which points to a
CISTPL_LINKTARGET tuple which begins the CIS for that function. (See also the Electrical
Specification.)
3.1 Control Tuples

Multiple instances of a tuple are allowed unless otherwise specified.
BASIC COMPATIBILITY (LAYER 1)
3.1.1 CISTPL_CHECKSUM: The Checksum Tuple

For additional reliability, the CIS can contain one or more checksum tuples. This tuple has three
fields:
· The relative address of the block of CIS memory to be checked;
· The length of the block of CIS memory to be checked; and
· The expected checksum.
The checksum algorithm is a straight modulo-256 sum. Relative addressing is used to make the CIS,
as a whole, position independent. The checksum tuple can only validate memory in its own address
space.
Table 3-1 CISTPL_CHECKSUM: Checksum Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_CHECKSUM (10H)
1 TPL_LINK Link to next tuple (at least 5).
2áá3 TPLCKS_ADDR Offset to region to be checksummed, stored with LSB first.
4áá5 TPLCKS_LEN Length of region to be checksummed, given with LSB first.
6 TPLCKS_CS The checksum of the region.
The checksum is calculated by summing the bytes of the selected region using modulo 256. The
result must match the value stored in byte 6 of the checksum tuple.
TPLCKS_ADDR contains the offset, relative to the start address of this tuple, of the region to be
checksummed. The address is a signed, 2-byte integer. Negative values indicate locations prior to
the checksum tuple; positive values indicate locations after the checksum tuple. The exact
interpretation depends on the address space containing the tuple.
TPLCKS_LEN contains the number of bytes to be checksummed. The number is expressed as an
unsigned, 2-byte integer.
If the tuple appears in the Common Memory space of a 16-bit PC Card or in any of the spaces of a
CardBus PC Card, the checksum is calculated in the obvious way. The contents of TPLCKS_ADDR
(as a signed integer) are added to the base address of the tuple, yielding the target address. Starting
at the target address, the algebraic sum is calculated of all the bytes included in the range. Then,
the low-order 8-bits of this sum are compared to the value stored in TPLCKS_CS. If identical, the
region of tuple memory covered by the checksum passes the checksum test.
If the tuple appears in the Attribute Memory space of a 16-bit PC Card, the checksum operation is a
bit more complicated. Again, the data structures are recorded in such a way as to minimize the
differences between Attribute space representation and Common Memory representation. To form
the target address, 2 * offset is added to the base byte target address of the tuple. Then, the algebraic
sum is formed of the even bytes in the address range [i.e., target, target + 2 * length-1], ignoring the
odd bytes. The low-order 8-bits of this sum is then compared to the value stored in TPLCKS_CS.
3.1.2 CISTPL_END: The End Of Chain Tuple

The end of chain tuple marks the end of a tuple chain. It has a non-standard form and consists solely
of the code byte. All CardBus PC Card tuple chains are required to be terminated with a
CISTPL_END tuple. No other method of terminating a tuple chain is permissible for CardBus PC
Cards.
Table 3-2 CISTPL_END: End of Chain Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_END (FFH): end of this tuple chain.
Upon encountering this tuple, system software shall take one of the following actions.
· If a longlink tuple was encountered previously in this chain, continue tuple processing at the
location specified in the longlink tuple.
· If processing a tuple chain (other than the primary CIS tuple chain of a 16-bit PC Card), and no
longlink tuple was seen in this chain, then no tuples remain to be processed.
· If processing the primary CIS tuple chain of a 16-bit PC Card (the chain starting at address 0 in
Attribute Memory space), and a CISTPL_NO_LINK tuple was encountered previously in this
chain, no tuples remain to be processed.
· If processing the primary CIS tuple chain of a 16-bit PC Card (the chain starting at address 0 in
Attribute Memory space), and neither a longlink nor a no-link tuple were seen in this chain,
then continue tuple processing as if a longlink to address 0 of Common Memory space were
encountered. For validation of the implied longlink to Common Memory, as with an explicit
CISTPL_LONGLINK_C tuple, the tuple chain in Common Memory must begin with a valid
CISTPL_LINKTARGET tuple.
3.1.3 CISTPL_INDIRECT: Indirect Access PC Card Memory

16-bit PC Cards providing indirect access to memory spaces through registers placed in Common
Memory shall indicate the presence of these registers with this tuple. (See the Electrical
Specification.) When processing software encounters this tuple in either Attribute or Common
Memory it shall assume the presence of an additional chain beginning at address zero (0) of either
the indirect Attribute or the indirect Common Memory space. Tuple processing in the indirect
spaces follows processing of all tuples in the direct spaces. All tuple chains in indirect spaces begin
with CISTPL_LINKTARGET tuples.
Table 3-3: CISTPL_INDIRECT: Indirect Access PC Card Memory

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_INDIRECT (03H)
1 TPL_LINK Link to next tuple (may be zero).
Note: The body of this tuple is always empty.
This tuple chain shall appear at most once in a Card Information Structure and always in a tuple
chain present in direct accessed Attribute or Common Memory space.
3.1.4 CISTPL_LINKTARGET: The LinkTarget Tuple

The linktarget tuple is used for robustness. Every longlink tuple must point to a valid linktarget
tuple. The linktarget tuple has one fieldÑ the string ÒCISÓ. It is recommended that the link field of
the link target point to the next byte after the CISTPL_LINKTARGET tuple. Processing software is
required to check that the linktarget tuple is correct before deciding to process the tuple chain at the
new target address. This tuple must be at the beginning of every tuple chain present on a CardBus
PC Card and the beginning of any secondary chain(s) on a 16-bit PC Card. It is recommended that
16-bit PC Cards using a low voltage key begin their primary CIS chain with this tuple.
Table 3-4 CISTPL_LINKTARGET: Link Target Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_LINKTARGET (13H)
2 TPLTG_TAG ÒCÓ (43H)
3 ÒIÓ (49H)
4 ÒSÓ (53H)
3.1.5 CISTPL_LONGLINK_A, CISTPL_LONGLINK_C: The 16-bit PC

Card LongLink Tuples
A given tuple chain for a 16-bit PC Card shall contain at most one longlink tuple (_A, _C or _MFC).
The longlink tuples are used to jump beyond the limits of the 1-byte link field, from one tuple chain
to another. The target tuple chain may be in Attribute Memory or Common Memory space, as
indicated by the tuple code.
WA R N IN G
The 16-bit PC Card longlink tuples (_A, _C and _MFC) are not applicable to,
and must never be used by, CardBus PC Cards.
Table 3-5 CISTPL_LONGLINK_A and CISTPL_LONGLINK_C: 16-bit PC Card LongLink Tuples

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE LongLink tuple code (CISTPL_LONGLINK_A, 11H; or CISTPL_LONGLINK_C, 12H)
2áá5 TPLL_ADDR Target address; stored as an unsigned long, low-order byte first.
Note: A given tuple chain shall contain at most one longlink tuple (_A, _C, _CB or _MFC).
The tuple code byte selects the new address space. For example, CISTPL_LONGLINK_A indicates
that the target is in Attribute Memory space; CISTPL_LONGLINK_C indicates Common Memory
space.
A given tuple chain shall contain at most one longlink tuple. The longlink tuple need not appear as
the last tuple in a given chain because all remaining tuples in the current chain will be processed
before the link is honored.
Software shall verify that the longlink tuple points to a linktarget tuple before processing the target
chain. Because a longlink tuple may point to uninitialized RAM, it is important that software simply
reject target tuple chains that do not begin with a linktarget tuple.
The TPLL_ADDR field of a CISTPL_LONGLINK_A tuple is interpreted in the same manner as its
TPL_LINK field, only even bytes in the address range are counted. To compute the address of the
linktarget in the cardÕs Attribute Memory space, multiply the value in the TPLL_ADDR field by
two.
3.1.6 CISTPL_LONGLINK_CB: The CardBus PC Card LongLink

Tuple
This gives the location of a tuple chain in a function's address space, whether device dependent
configuration space, memory space, or the expansion ROM. This tuple may also occur in tuple
chains in any of these spaces, as well.
Table 3-6 CISTPL_LONGLINK_CB: The CardBus PC Card LongLink Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_LONGLINK_CB (02H)
1 TPL_LINK Link to next tuple (at least 4)
2áá5 TPLL_ADDR Indicates the location of a tuple chain in a function's address space. The encoding is the same as
for the CIS Pointer. (See the Electrical Specification.)
TPLL_ADDR points to a tuple chain in one of the following spaces:

· configuration space - must begin in device dependent configuration space at or after location
40H.
· memory space - may be in any of the (up to) six (6) spaces. Note that this cannot be an I/O
space.
· Expansion ROM space - may be in any of the images.
The encoding for this pointer is given below:
TPLL_ADDR field
DWORD 31 É 28 27 É 8 7 É 3 2 1 0
Address Space Offset Address Space
Indicator
Config Reserved, must be 0 offset within Config Space replace with 0s
Space
Memory offset within Base Address Register memory space replace with 0s
Space
Exp ROM image number offset from image base replace with 0s
The Address Space Indicator field indicates in which of this function's address spaces the tuple chain is
located. The encoding for this field is given below:
Address Space Indicator field
Value Meaning
0 Tuple chain is in device dependent configuration space.
1-6 The tuple chain is in the memory address space governed by one of the six Base Address
Registers. For example, if the value is 2, then the tuple chain is in the memory address space
governed by Base Address Register 2.
7 The tuple chain is in the Expansion ROM space.
The offset into the address space indicated by the Address Space Indicator field is given by the 32 bit
value where the three low order bits, 0 through 2, are zero and the high order bits, 3 through 31,
are given by the Address Space Offset field. An address at which a tuple chain begins will have an 8
byte alignment. Appropriate values for the various spaces are given below:
Address Space Offset field

Address Space Space Type Address Space Offset
Indicator
0 configuration space 40H £ value £ F8H. The address in device dependent
configuration space at which the tuple chain starts.
x; 1 £ x £ 6 memory space 0 £ value £ FFFFFFF8H. This is the offset into the memory
address space governed by Base Address Register x.
Adding this value to the value in the Base Address Register
gives the location of the start of the tuple chain.
7 expansion ROM 0 £ image £ FH,
0 £ value £ 0FFFFFF8H. This is the offset into the
expansion ROM address space governed by the Expansion
ROM Base Register. The image number is in the
uppermost nibble of the Address Space Offset. The value
consists of the remaining bytes.
The image is the image number used as the location
reference for the tuple chain. The value is the offset of the
tuple chain from the base of that image. Adding this offset
value plus the starting offset of the image to the value in the
Expansion ROM Base Register gives the location of the
start of the tuple chain.
3.1.7 CISTPL_LONGLINK_MFC: The Multiple Function 16-bit PC

Card Link Tuple
This longlink tuple indicates the number of sets of configuration registers on a Multiple Function 16-
bit PC Card. This tuple does not apply to and must never be used by a CardBus PC Card. This
tuple also describes the location of the each function-specific CIS describing the function provided by
a specific set of configuration registers.
When a TPLMFC_TASn field is 00H, indicating a longlink to Attribute Memory space, the
associated TPLMFC_ADDRn field is interpreted in the same manner as its TPL_LINK field in a
tuple placed in Attribute Memory space, only even bytes in the address range are counted. To
compute the address of the linktarget in the cardÕs Attribute Memory space, multiply the value in
the TPLMFC_ADDRn field by two.
Table 3-7 CISTPL_LONGLINK_MFC: The Multiple Function 16-bit PC Card Link Tuple
Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_LONGLINK_MFC (06H)
1 TPL_LINK Link to next tuple (at least 6, 1 plus 5 bytes per function)
2 TPLMFC_NUM Number of sets of configuration registers for individual functions
3 TPLMFC_TAS1 CIS Target address space for first function on the 16-bit PC Card
(00 = Attribute, 01 = Common)
4áá7 TPLMFC_ADDR1 Target address, stored as an unsigned long, low order byte first
8 TPLMFC_TAS2 CIS Target address space for second function on the 16-bit PC Card
9áá12 TPLMFC_ADDR2 Target address, stored as an unsigned long, low order byte first
13áán Additional TPLMFC_TASn and TPLMFC_ADDRn entries for any additional functions on the 16-
bit PC Card. If there are only two (2) sets of configuration registers, only the prior fields shall be
present.
3.1.8 CISTPL_NO_LINK: The No-Link Tuple

To save Attribute Memory space on 16-bit PC Cards, processing software shall assume the presence
of a CISTPL_LONGLINK_C tuple to address 0 of Common Memory as part of the primary tuple
chain. The primary tuple chain starts at address 0 of Attribute Memory space. This assumption can
be overridden either by placing an explicit longlink tuple (CISTPL_LONGLINK_A or
CISTPL_LONGLINK_C) or a no-link tuple (CISTPL_NO_LINK) in the primary tuple chain.
Table 3-8 CISTPL_NO_LINK: The No-Link Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_NO_LINK (14H)
1 TPL_LINK Link to next tuple (may be zero).
Note: The body of this tuple is always empty.
A given tuple chain shall contain at most one no-link tuple. No-link tuples and longlink tuples are
mutually exclusive. A given chain may contain either a no-link tuple, or a longlink tuple, but not
both.
3.1.9 CISTPL_NULL: The Null Tuple

The null tuple is simply a place holder. It has a non-standard form and consists solely of the code
byte.
Table 3-9 CISTPL_NULL: The Null Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_NULL (00H): ignore this tuple.
Note: Software shall ignore these tuples. The next tuple begins at the next byte in sequence.
3.2 Basic Compatibility Tuples

Multiple instances of a tuple are NOT allowed unless otherwise specified.
3.2.1 CISTPL_ALTSTR: The Alternate Language String Tuple

Several tuples contain character strings which are intended to be displayed to the user only under
certain circumstances. Some international applications need the ability to store strings for a number
of different languages. Rather than having various languages used in the tuples, this standard
provides alternate string tuples. Strings in the primary tuples are always recorded in ISO 646 IRV
code using characters in the range 20Háá7EH. Multiple instances of this tuple are allowed; each
associates with most recent (previous) ÒNON-ALT STRINGÓ tuple. Tuple codes affected are 15H
(CISTPL_VERS_1) and 40H (CISTPL_VERS_2).
Alternate string tuples contain two kinds of information:
· A code representing the language (an ISO-standard escape sequence), and
· A series of strings.
These strings are to be substituted for the primary strings when operating in a different language
environment.
Table 3-10 CISTPL_ALTSTR: The Alternate Language String Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_ALTSTR (16H)
1 TPL_LINK Link to next tuple (at least p-1).
2áá(m-1) TPLALTSTR_ESC ISO-standard escape sequence to select the character set for these strings. Indicates which
character set is associated with these strings. The leading ESCAPE is not recorded.
Terminated by a NULL (00H).
A special escape sequence denotes the PC Extended ASCII character set.
máá(n-1) Alternate string 1 translation for first string in most recent non-ALTSTR tuple. Terminated by 00H.
náá(o-1) Alternate string 2 translation for second string in most recent non-ALTSTR tuple. Terminated by 00H.
É Etc.
p FFH - marks end of strings.
3.2.2 CISTPL_DEVICE, CISTPL_DEVICE_A: The 5 volt Device

Information Tuples
The 5 volt device information tuples contain information about the card's devices. The tuples
contain: device speed, device size, device type, and address space layout information for either
Attribute Memory, CISTPL_DEVICE_A, or Common Memory, CISTPL_DEVICE, space. PC Cards
with a 5 volt key shall present a device information tuple for Common Memory space,
CISTPL_DEVICE, as the first non-control tuple in Attribute Memory. (See 2.3.8 16-bit PC Card
Tuple Chain Processing). It is recommended that the device information tuple for Attribute
Memory, CISTPL_DEVICE_A, be provided.
16-bit PC Cards that operate at both 5 volts VCC and 3.3 volts VCC shall use the Device Info fields in
CISTPL_DEVICE and CISTPL_DEVICE_A to describe the characteristics when operating at 5 volts
VCC. One or more Other Conditions Tuples, CISTPL_DEVICE_OC and CISTPL_DEVICE_OA, shall
exist to describe the 3.3 volts VCC operating characteristics. Whenever both CISTPL_DEVICE and
CISTPL_DEVICE_OC tuples are present, there must be a one-to-one correspondence between their
Device Info entries. This one-to-one correspondence shall also exist between Device Info entries in
the CISTPL_DEVICE_A and CISTPL_DEVICE_OA tuple(s). Null devices are counted in the
matching process.
Table 3-11 CISTPL_DEVICE, CISTPL_DEVICE_A: The 5 volt Device information Tuples

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_DEVICE (01H) or CISTPL_DEVICE_A (17H)
1 TPL_LINK Link to next tuple (at least m-1)
n Device Info 1 (2 or more bytes)
Device Info 2 (2 or more bytes)
É (etc.)
Device Info n (2 or more bytes)
m FFH (marks end of Device Info field)
The tuple code CISTPL_DEVICE indicates that this tuple describes Common Memory space. The
code CISTPL_DEVICE_A indicates that this tuple describes Attribute Memory space.
See section 3.2.2.1 Device Info Fields, for the Device Info field definition.
3.2.2.1 Device Info Fields (For Tuples CISTPL_DEVICE, CISTPL_DEVICE_A)

The device information tuples are composed of a sequence of Device Info fields. Each field is further
composed of two variable length byte sequences Ñ the Device ID and the Device Size. Each Device
Info field defines the characteristics of a group of addresses in the appropriate memory space.
Device Info fields
Byte 7 6 5 4 3 2 1 0
n Device ID one or more bytes of Device ID fields
n+m Device Size one byte indicating the device size
# of address units - 1 Size Code
3.2.2.1.1 Device ID Fields

The device ID indicates the device type and the access time for a block of memory.
Device ID fields
Byte 7 6 5 4 3 2 1 0
n Device Type Code WPS Address Space Indicator
or
Device Speed
n+1 Extended Device Speed If Device Speed Code equals 7H, otherwise omitted.
EXT Speed Mantissa Speed Exponent
(n+2)áá(o-1) Additional Extended Device Speed While EXT of previous byte is set.
EXT Reserved for future use.
o Extended Device Type If Device Type Code equals EH, otherwise omitted.
EXT Extended Device Type Code
(o+1)áá Additional Extended Device Type While EXT of previous byte is set.
EXT Additional Extended Device Type Code
3.2.2.1.1.1 Device Type Code Field

The Device Type Code field in bits 4 through 7 of byte 0 of the Device ID sequence indicates the
device type. The following codes are defined:
Device Type Code field
Code Name Meaning
0 DTYPE_NULL No device. Generally used to designate a hole in the address space. If used for 16-bit
PC Cards, the Device Speed field should be set to 0H.
1 DTYPE_ROM Masked ROM
2 DTYPE_OTPROM One Time Programmable ROM
3 DTYPE_EPROM UV EPROM
4 DTYPE_EEPROM EEPROM
5 DTYPE_FLASH Flash EPROM
6 DTYPE_SRAM Static RAM
7 DTYPE_DRAM Dynamic RAM
8ááCH Reserved
DH DTYPE_FUNCSPEC Function-specific memory address range. Includes memory-mapped I/O registers,
dual-ported memory, communication buffers, etc., which are not intended to be used
as general-purpose memory.
Accesses to function-specific address ranges may be configuration dependent
EH DTYPE_EXTEND Extended type follows.
FH Reserved
Note: Device Type Codes are used to describe only devices which are fixed in their memory address, not
dynamically relocatable devices. Relocatable devices are described by the configuration tuples.
If there are no devices in a 16-bit PC Card's common memory space, the Device Type Code shall be
DTYPE_NULL. If the devices at offset zero in the 16-bit PC Card's common memory space are
intended for function specific use, such as memory mapped I/O registers or communications
buffers, the Device Type Code shall be DTYPE_FUNCSPEC.
The extended device type, if specified, is reserved for future use. Bit 7, if set, indicates that the next
byte is also an extended type byte. The chain of extended type bytes can continue indefinitely. The
end is marked by an extended device type byte with bit 7 reset.
3.2.2.1.1.2 WPS Field

The WPS bit indicates whether the Write Protect Switch is in control of the device(s) in this address
range. When the WPS bit is reset (0), the Write Protect Switch and WP signal indicate whether or
not the device(s) is(are) writable. When the WPS bit is set (1), the device is always writable unless
the device code is DTYPE_ROM, in which case this address range is never writable. (See the
Electrical Specification.)
3.2.2.1.1.3 Address Space Indicator Field (CardBus PC Card only)

The Address Space Indicator field indicates the memory or Expansion ROM Base Address Register
associated with the devices described in the CISTPL_DEVICE_OC tuple. The Address Space
Indicator field used here has the same format and interpretation as the field used in the CIS Pointer
and the CISTPL_LONGLINK_CB tuple. An Address Space Indicator value of zero (0) is illegal since it
would indicates that the device(s) is(are) in CardBus PC Card Configuration Space. (See 3.1.6
CISTPL_LONGLINK_CB: The CardBus PC Card LongLink Tuple.)
3.2.2.1.1.4 Device Speed Field (16-bit PC Card only)

If the device speed/type byte is 00H, there is no device at this address. If the device size information
is valid, the address range shall be treated as a NULL device.
Bits 0 through 2, and up to one or two additional bytes, represent the speed of the devices associated
with this part of the address space. The speed value indicates the external card access time to this
address range (See the Electrical Specification.) The device speed field contains one of the values in
the table below.
Device Speed Codes
Code Name Meaning
0 DSPEED_NULL Use when device type = NULL
1 DSPEED_250NS 250 nsec
5áá6 (Reserved)
7 DSPEED_EXT Use extended speed byte.
Note: The values given in the Device Speed fields of CISTPL_DEVICE and
CISTPL_DEVICE_A tuples must define the worst case cycle time required
by a 16-bit PC Card without the use of the WAIT# signal. This is required
by PCMCIA 1.0 / JEIDA 4.0 host platforms that pre-date the definition of
the WAIT# signal. 16-bit PC Cards that support the use of the WAIT#
signal shall include the CISTPL_DEVICE_OC tuple to define 5 volt device
speed with the WAIT# signal honored.
If the extended speed byte is zero, then the byte should be ignored.
The EXT bit, if set, indicates that an additional extended speed byte follows. The meaning of that
byte is not presently defined. However, the string of extended speed bytes may be arbitrarily long.
It extends through (and includes) the first byte with bit 7 reset.
The extended device speed mantissa and exponent specify the speed of the device, as follows:
Extended Device Speed Codes
Mantissa Exponent part
Code Meaning Code Meaning
0H Reserved 0H 1 ns
1H 1.0 1H 10 ns
2H 1.2 2H 100 ns
3H 1.3 3H 1 ms
4H 1.5 4H 10 ms
5H 2.0 5H 100 ms
6H 2.5 6H 1 ms
7H 3.0 7H 10 ms
8H 3.5
9H 4.0
AH 4.5
BH 5.0
CH 5.5
DH 6.0
EH 7.0
FH 8.0
3.2.2.1.2 The Device Size Byte (For Tuples CISTPL_DEVICE, CISTPL_DEVICE_A)

Within the device information tuple fields, following the device speed/type information, is the
Device Size byte. The indicated size describes the total memory address range of the specified device
type.
Device Size Codes
Code Units Max Size
0 512 bytes 16 KBytes
1 2 KBytes 64 KBytes
2 8 KBytes 256 KBytes
3 32 KBytes 1 MByte
4 128 KBytes 4 MBytes
5 512 KBytes 16 MBytes
6 2 MBytes 64 MBytes
7 Reserved Reserved
Bits 3 through 7 represent the number of address units. A code of zero indicates 1 unit; a code of 1
indicates 2 units; and so on.
For a device size > 64 MBytes the device size byte shall indicate a size of 64 MBytes. The tuple
CISTPL_EXTDEVICE shall indicate the exact divice size when device size exceeds 64 MBytes.
If the device size byte is FFH, then this entry should be treated as an end marker for the device
information tuple. The device type and speed information encoded for this entry should be ignored.
3.2.3 CISTPL_DEVICE_OC, CISTPL_DEVICE_OA: The Other

Conditions Device information Tuples
The Other Conditions device information tuples contain information about the card's devices under
a set of operating conditions. The tuples are identical in format to the device information Common
and Attribute Memory tuples except that an Other-Conditions-Info field precedes the first Device Info
field. (See 3.2.2 CISTPL_DEVICE, CISTPL_DEVICE_A: The 5 volt Device Information Tuples.)
There may be several CISTPL_DEVICE_OC and CISTPL_DEVICE_OA tuples in the CIS Ñ one to
describe the card under each set of alternative operating conditions.
There shall be a one-to-one correspondence between entries of each related tuple that describes
operating characteristics. If a CISTPL_DEVICE tuple is present, there must be a one-to-one
correspondence between entries in the CISTPL_DEVICE tuple and each CISTPL_DEVICE_OC tuple.
All CISTPL_DEVICE_OC tuples have corresponding entries. If a CISTPL_DEVICE_A tuple is
present, there must be a one-to-one correspondence between entries in the CISTPL_DEVICE_A tuple
and each CISTPL_DEVICE_OA tuple. All CISTPL_DEVICE_OA tuples have corresponding entries.
Null devices are counted in the matching process.
CardBus PC Cards shall use the CSTPL_DEVICE_OC tuple to describe memory space devices.
Table 3-12 CISTPL_DEVICE_OC, CISTPL_DEVICE_OA: The Other Conditions Device

information Tuples
Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_DEVICE_OC (1CH) and CISTPL_DEVICE_OA (1DH).
1 TPL_LINK Link to next tuple (m-1, 3 or more).
2 Other Conditions Info 1 or more bytes
n Device Info 1 2 or more bytes
Device Info 2 2 or more bytes
É (etc.)
Device Info n 2 or more bytes
m FFH (marks end of Device Info fields).
3.2.3.1 Other Conditions Info Field

The Other-Conditions-Info field is a sequence of one or more bytes each with up to seven condition
fields and one extension bit. The condition fields indicate the set of defined conditions which apply
to the device information in the tuple. There are two condition fields defined Ñ the VccUsed and the
MWAIT fields. All undefined fields are reserved for future standardization and must be zero. Bit 7
of each byte is the extension bit which indicates that another byte of conditions follows the present
byte.
Other-Conditions-Info field
7 6 5 4 3 2 1 0
EXT Reserved, must be 0. VccUsed MWAIT
EXT Additional Bytes Each is present only if EXT bit is set in previous byte
The MWAIT field is ignored by CardBus PC Cards.

When the MWAIT field is set (1), the timings given are intended for PCMCIA 2.0 / JEIDA 4.1 and
later systems which will observe the WAIT# signal. Note that the card is not required to assert the
WAIT# signal during operation. Host systems which do not support the WAIT# signal, PCMCIA
1.0 / JEIDA 4.0 and earlier, shall not use timing data provided in a tuple with the MWAIT field set
(1).
When the MWAIT field is reset (0), the timings given represent worst case cycle times and shall be
used by host systems which do not support the WAIT# signal. Note that the VccUsed field shall not
indicate 5 V VCC operation because this condition, MWAIT reset (0) and 5 V VCC, is indicated using
the CISTPL_DEVICE and CISTPL_DEVICE_A tuples
The VccUsed field indicates a VCC voltage at which the PC Card can be operated. A PC Card
capable of operating at more than one VCC voltage shall have a separate instance of the Other
Conditions tuple, CISTPL_DEVICE_OC or CISTPL_DEVICE_OA, for each such operating voltage.
VccUsed field
Value Meaning
00B 5 volt VCC operation.
01B 3.3 volt VCC operation.
10B Reserved for X.X volt VCC operation.
11B Reserved for CardBus PC Card Y.Y volt VCC operation.
The Device Info fields for the CISTPL_DEVICE_OC and CISTPL_DEVICE_OA tuples have the same
definition and format as the CISTPL_DEVICE and CISTPL_DEVICE_A tuples. The fields are defined
in section 3.2.2.1 Device Info Fields (For Tuples CISTPL_DEVICE, CISTPL_DEVICE_A).
3.2.2.1Device Info Fields
3.2.4 CISTPL_DEVICEGEO, CISTPL_DEVICEGEO_A: Device

Geometry Tuples
The device geometry info tuple CISTPL_DEVICEGEO is required for certain memory technologies
(e.g. Flash Memory, EEPROM) or card integrated memory subsystems. While conceptually similar
to a DOS disk geometry tuple (CISTPL_GEOMETRY), it is not a format dependent property; this
deals with the fixed architecture of the memory device(s) or subsystem(s). Rather than being specific
to a partition within a larger device type, this applies to the entire address range of that device
type. Accordingly, each Device Geometry Info entry in the CISTPL_DEVICEGEO tuple must have a
corresponding Device Info entry, including NULL device space, in CISTPL_DEVICE or
CISTPL_DEVICE_OC tuples when the CISTPL_DEVICEGEO tuple is employed. This one-to-one
relationship also applies to device geometry entries in the CISTPL_DEVICEGEO_A tuple and device
info entries in CISTPL_DEVICE_A or CISTPL_DEVICE_OA tuples.
Table 3-13 CISTPL_DEVICEGEO and CISTPL_DEVICEGEO_A: Device Geometry Tuples

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_DEVICEGEO (1EH) and CISTPL_DEVICEGEO_A (1FH)
1 TPL_LINK Link to next tuple (at least 6 * k).
2áá7 Device Geometry Info for Device 1.
8áá13 Device Geometry Info for Device 2.
(etc.)
áá((6 * k)+1) Device Geometry Info for Device k.
Device Geometry Info field

Byte 7 6 5 4 3 2 1 0
(n-1)
+0 DGTPL_BUS Value = n, where card interface width = 2 bytes.
n = 2 for 16-bit PC Cards.
n = 3 for CardBus PC Cards.
The value n = 00H is not allowed.
+1 DGTPL_EBS Value = n, where memory array/subsystem's physical memory segments have a minimum
erase block size of 2(n-1) address increments of DGTPL_BUS-wide accesses. The value n = 00H
is not allowed.
+2 DGTPL_RBS Value = n, where memory array/subsystem's physical memory segments have a minimum
read block size of 2(n-1) address increments of DGTPL_BUS-wide accesses. The value n = 00H
is not allowed.
+3 DGTPL_WBS Value = n, where memory array/subsystem's physical memory segments have a minimum
write block size of 2(n-1) address increments of DGTPL_BUS-wide accesses. The value n = 00H
is not allowed.
+4 DGTPL_PART Value = p, where memory array/subsystem's physical memory segments can have partitions
subdividing the arrays in minimum granularity of 2 (p-1) number of erase blocks. P = 1 where
array partitioning at erase block boundaries is allowed. The value p = 00H is not allowed.
+5 DGTPL_HWIL Value = q, where card architectures employ a multiple of 2(q-1) times interleaving of the entire
memory arrays or subsystems with the above characteristics. Non-interleaved cards have
values of q = 1.
The value q = 00H is not allowed.
If the Device Geometry Info field is used, the entire six byte entry must be filled out for each entry in
the corresponding CISTPL_DEVICE, CISTPL_DEVICE_OC, CISTPL_DEVICE_OA or
CISTPL_DEVICE_A, even for devices without any special geometry (e.g. ROM, RAM), so that a 1:1
correspondence between Device Info and Device Geometry Info fields of the described regions exists.
The table length is 6 * k + 2 bytes, where k = the number of devices described. Bit 7 of
DGTPL_HWIL, the last (sixth) byte of each detailed Device Geometry Info field, is reserved for future
use and must be reset (0). When set (1) this bit indicates that an extended device geometry
information structure follows.
The DGTPL_BUS tuple has a value of n = 2 for 16 bit bus width of 16-bit PC Cards regardless of
word or byte wide operation (byte wide operation is logically low and high byte sequencing of a
fundamental 16 bit wide card internal bus) and n = 3 for the 32 bit bus width of CardBus PC Cards.
The purpose of this entry is to accommodate possible wider width cards of the future and/or to
allow file systems to use this tuple structure in non-card environments (e.g. system resident
memory arrays using the same file system).
Note: The device geometry info is normalized to byte equivalent geometry to
simplify the context for the O/S or driver level software which utilizes it.
Subsystems using internal bus widths less than 8 bits wide must employ
low-level drivers which accept 8 bit minimum data from the higher levels.
The DGTPL_EBS, DGTPL_RBS, and DGTPL_WBS (address increment or bus operation based
values) are multiplicative of the DGTPL_BUS entry (denoting bus width) to define the non-
interleaved physical memory erase, read, and write block sizes in bytes, respectively. The
DGTPL_HWIL value for cards employing hardware interleaved (i.e., ÒbanksÓ of) memory arrays or
subsystems (where DGTPL_HWIL - 2) is multiplicative of the resulting non-interleaved erase, read,
and write geometry. The product of these three geometry info layers yields the resulting card level
minimum physical block geometry.
DGTPL_PART is a special partitioning info field based on physically distinct segments of the
memory array(s) such that data are not affected by read/write/erase operations in adjacent
partitions. It is multiplicative of the resulting erase geometry (only) and defines the minimum
partition size allowed for that card. DGTPL_PART: p = 1 where array partitioning at erase block
boundaries is allowed (i.e., there are no special partitioning requirements).
Examples:
1. A particular non-interleaved (DGTPL_HWIL: q = 1) 16-bit PC Card based memory array (DGTPL_BUS: n = 2) employs
a new EEPROM type of byte-wide memory device which erases in 4K bytes (DGTPL_EBS: n = 13) and writes in 256
byte pages (DGTPL_WBS: n = 9). It has no special partitioning requirements (DGTPL_PART: p = 1). The resulting
physical geometry is:
Bus x Block x Interleave
ERASE Geometry = 2 x 4096 x1 = 8192 bytes
READ Geometry = 2x 1 x1 = 2 bytes
WRITE Geometry = 2x 256 x1 = 512 bytes
PARTITION Boundary = ERASE Geometry x1 = 8192 bytes

2. A particular four layer interleaved (DGTPL_HWIL: q = 3) 16-bit PC Card based memory array (DGTPL_BUS: n = 2)
employs a new type of word wide flash memory device with built in byte/word mode operation. Internal components
erase in blocks that are 64 KBytes, or 32 KBytes times their 16 bit bus (DGTPL_EBS: n = 16) and write in single words
(DGTPL_WBS: n = 1). It requires partitioning in erase block groups of four (DGTPL_PART: p = 3). The resulting
physical geometry is:
Bus x Block x Interleave
ERASE Geometry = 2 x 32,768 x4 = 262,144 bytes
READ Geometry = 2x 1 x4 = 8 bytes
WRITE Geometry = 2x 1 x4 = 8 bytes
PARTITION Boundary = ERASE Geometry x4 = 1,024 KBytes
3.2.5 CISTPL_EXTDEVICE: The Extended Common Memory Device

Information Tuple
The extended common memory device information tuple contains information about the card's
devices which reside in common memory. The CISTPL_EXTDEVICE tuple contains device speed,
device size, device type, address space layout, address extension size, address extension register
location and memory page size information for Common Memory space. The tuple (illustrated in
Table 3-14) is primarily intended to be used with PC Cards containing more than 64 MBytes of
common memory.
When this tuple is present and recognized by the system software, the data provided by the tuple
shall override the Device Info field data presented by the CISTPL_DEVICE and
CISTPL_DEVICE_OC tuples; however, tuple CISTPL_EXTDEVICE should present the same Device
ID field information in the same sequential order as what the tuple CISTPL_DEVICE and/or tuple
CISTPL_DEVICE_OC provides. Even though the CISTPL_EXTDEVICE tuple overrides the Device
Info parts of a CISTPL_DEVICE_OC tuple, the Other Conditions Info part of the
CISTPL_DEVICE_OC tuple shall still apply.
To maintain backward compatibility as much as possible with host systems which do not recognize
the CISTPL_EXTDEVICE tuple, tuples CISTPL_DEVICE and CISTPL_DEVICE_OC should be
encoded to describe the first (non-extended) 64 MByte region of common memory for a PC Card. For
each device type the CISTPL_DEVICE and/or CISTPL_DEVICE_OC tuple(s) would encode a
maximum device size of 64 MBytes. Then, all host systems would recognize the CISTPL_DEVICE
and/or CISTPL_DEVICE_OC tuple(s) and, using the tuple information, be able to access the 1st 64
MBytes of the cardÕs memory. If a host system supported the CISTPL_EXTDEVICE tuple, the host
system would process the information presented by the CISTPL_EXTDEVICE tuple and ignore the
information contained in the CISTPL_DEVICE and CISTPL_DEVICE_OC tuples.
Table 3-14 CISTPL_EXTDEVICE: The Extended Common Memory Device information Tuples
Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_EXTDEVICE (09H)
1 TPL_LINK Link to next tuple (at least m-1)
2 Memory Paging Info (1 or more bytes)
n Device Info 1 (2 or more bytes)
Device Info 2 (2 or more bytes)
É (etc.)
Device Info n (2 or more bytes)
m FFH (marks end of Device Info field)
3.2.5.1 Memory Paging Info Field

The Memory Paging-Info field is a sequence of one or more bytes. Each byte consists of a set of fields
with up to seven bits of paging information and one extension bit. The fields indicate defined
paging conditions which apply to the device information in the tuple.
All undefined fields in the Memory Paging-Info byte sequence are reserved for future standardization
and shall be zero. Bit 7 of each byte is defined as the extension bit which indicates that another byte
of paging information follows the present byte. For the first byte of the byte sequence there are 3
paging condition fields Ñ the Page Size, Page Address Location and the Number of Address Extension
Bits fields. Other bytes in the byte sequence are undefined.
The 3 fields for the single defined byte are defined as follows:
Memory-Paging-Info field
7 6 5 4 3 2 1 0
EXT Number of Address Extension Bits - 1 Page Address Page Size
Location
EXT Additional Bytes Each is present only if EXT bit is set in previous byte
The Page Size field indicates the page size for Common Memory.
The Page Address Location bit applies only for 64 MByte page size and denotes which Function
Configuration Register provides a set of address extension bits for accessing > 64 MBytes of
Common Memory. The Page Address Location bit indicates the choice of either the Configuration
Option Register or Address Extension Register 0 as the source for the address extension bits.
For a 32 MByte page size Address Extension Registers 0 and 1 provide the address extension bits for
addressing a 32 MByte memory page, while for a 16 MByte page size Address Extension Registers
0, 1, 2 and 3 contain the address extension bits to address a 16 MByte memory page.
The Memory Paging-Info fieldÕs Page Size and Page Address Location sub-fields indicate the page size
and Function Configuration Registers as follows:
Memory-Paging-Info Field Bits

Page Address Page Size Description
Location
Selected Page Function Configuration Register(s)
Bit 2* Bit 1 Bit 0 Size providing Address Extension
0 0 0 64 MBytes Address Extension Register 0
1 0 0 64 MBytes Configuration Option Register
0 1 32 MBytes Address Extension Registers 0 and 1
1 0 16 MBytes Address Extension Registers 0, 1, 2 and 3
1 1 Reserved ¾
* Bit 2 is defined only for the condition where bits 1 and 0 both equal `0Õ. For all other conditions bit 2 is
reserved and must = `0Õ.
For the Function Configuration Register(s) providing an address extension the Number of Address
Extension Bits - 1 field indicates the actual number of bits in the address extension provided by the
register(s). The number of actual address extension bits is represented as a binary value equal to the
number of actual address extension bits minus 1; thus, 0 would imply that an address extension
consisted a single address extension bit.
3.2.5.2 Device Info fields (for tuple CISTPL_EXTDEVICE)

The device information tuples are composed of a sequence of Device Info fields. Each field is further
composed of two variable length byte sequences Ñ the Device ID and the Device Size. Each Device
Info field defines the characteristics of a group of addresses in the appropriate memory space.
For a device memory size £ 64 MBytes the following definition holds:

Device Info fields
Byte 7 6 5 4 3 2 1 0
n Device ID one or more bytes of Device ID fields
n+m Device Size one byte indicating the device size for a £ 64 MByte device memory space
For a device memory size > 64 MBytes the following definition holds:
Device Info fields
Byte 7 6 5 4 3 2 1 0
n Device ID one or more (m) bytes of Device ID fields
n+m Device Size Extender Indicates > 64 MBytes of device memory space
0 0 0 0 ExtBytes 1 1 1
ExtBytes = 0 signifies that 1 Device Extended Size byte and then the Device Final Size byte follow extender byte.
ExtBytes = 1 signifies that 2 Device Extended Size bytes and then the Device Final Size byte follow extender byte.
All other bit combinations of bits 7 through 0 indicate that this byte is the single Device Size byte defining a £ 64 MByte
device memory space (i.e., is not extender byte) and that no further device size bytes follow.
n+m+1 P7 P6 P5 P4 P3 P2 P1 P0
Device Extended Size byte #1 Bits 0 through 7 of P (`64 MByte pageÕ multiplier lower byte)
n+m+2 P15 P14 P13 P12 P11 P10 P9 P8
Device Extended Size byte #2 Bits 8 through 15 of P (`64 MByte pageÕ multiplier upper byte)
n + m + (s-1) Device Final Size Last of three or four bytes (s). This byte codes an amount of device memory up to a
maximum of 64 MBytes.
3.2.5.2.1 Device ID fields

Same as Section 3.2.2.1.1 Device ID Fields.
3.2.5.2.2 The Device Size Byte(s) (For Tuple CISTPL_EXTDEVICE)

As outlined in Section 3.2.4, the device size information depends on whether or not the amount of
common memory for the device being described is greater than 64 MBytes. For a £ 64 MByte device
memory size a single Device Size Byte provides the information. However, for a > 64 MByte device
memory size, 3 or 4 bytes contain the device size information.
3.2.5.2.2.1 Device Memory Size £ 64 MBytes

Within the device information tuple fields, following the device speed/type information, is the
Device Size byte. The indicated size describes the total memory address range of the device type
specified with the device speed/type information. The Device Size byte consists of 2 fields, the # of
Address Units - 1 field (bits 7 - 3 of the Device Size byte) and the Size Code field (bits 2 - 0 of the
Device Size byte).
For £ 64 MByte memory device size the # of Address Units - 1 field represents the number of
memory units specified by the Size Code field. A code of zero indicates 1 unit, a code of 1 indicates 2
units, and so on (for device size codes 0 through 6).
When the device size code = 7 (and reserved bits 7 through 4 of the Device Size byte = 0), then a >
64 MByte device memory size is indicated (see following section).
The Size Code field ranges in value from 0 to 7 with codes 0 to 6 used to determine £ 64 MByte
device memory size The Size Code field is defined as follows:
Device Size Codes
Code Units Max Size
0 512 bytes 16 Kbytes
1 2 Kbytes 64 Kbytes
2 8 Kbytes 256 Kbytes
3 32 Kbytes 1 MByte
4 128 Kbytes 4 MBytes
5 512 Kbytes 16 Mbytes
6 2 MBytes 64 Mbytes
7*
ExtBytes = 0 Identifies byte as Device Size Extender byte for > 64 MByte
device memory size and indicates that 1 Device Extended
Size byte and the Device Final Size byte follow next in the
tuple sequence (see following section)
ExtBytes = 1 Identifies byte as Device Size Extender byte for > 64 MByte
device memory size and indicates that 2 Device Extended
Size bytes and the Device Final Size byte follow next in the
tuple sequence (see following section)
Device Size [7::4] Reserved (= 0)
* Code 7 is defined for a memory device size > 64 MBytes. For a code 7 the Device Size byte is
redefined to be the Device Size Extender byte, the first of a sequence of bytes defining > 64 MByte
device size. The Device Size Extender byte contains the ExtBytes field which is not defined for the
Device Size byte.
If the Device Size byte is FFH, then this entry should be treated as an end marker for the device
information tuple. The device type and speed information encoded for this entry should be ignored.
3.2.5.2.2.2 Device Memory Size > 64 MBytes

Card and Socket Services software support is specified for PC Card common memory spaces not
exceeding 4 Gigabytes. The size definition which follows allows for PC Cards with more than 4
Gigabytes of common memory; the larger memory provisions can be utilized with Memory
Technology Driver (MTD) software which bypasses Card and Socket Services software to directly
drive a PC Card.
Within the device information tuple fields, following the device speed/type information, is a
sequence of bytes for defining a > 64 MByte device memory size. The byte sequence describes the
total memory address range of the device type specified with the device speed/type information.
For > 64 MByte device memory spaces the device size information is contained in the following 4
bytes:
1. Device Size Extender Byte
2. Device Extended Size Byte 1
3. Device Extended Size Byte 2 (for device memory size > 16 Gigabytes) and
4. Device Final Size Byte
Bits 0 - 2 of the Device Size Extender byte must all = 1 in order to indicate device size extension
beyond 64 MBytes. If bits 0 -2 do not all = 1, then they represent the Size Code field for a device
memory size < 64 MBytes (see the previous section).
If the Device Size Extender byte is FFH, then this entry should be treated as an end marker for the
device information tuple. The device type and speed information encoded for this entry should be
ignored.
When the single-bit ExtBytes field (bit 3) of the Device Size Extender byte = 0, a single Device
Extended Size byte and then a Device Final Size byte follow next in line after the Device Size Extender
byte.
Device memory size is calculated using the single Device Extended Size byte and the Device Final
Size byte as follows:
(P )* 64 MBytes + Device Final Size
where ,
P = the binary-encoded value provided by the Device Extended Size byte
and
Device Final Size = the device size coded in the Device Final Size byte.
The Device Final Size byte which follows the Device Extended Size byte is formatted identical to the
single Device Size Byte used for < 64 MByte device memory sizes. Thus, 64 MBytes, obtained with a
device size code of 6, is the maximum value which can be indicated for Device Final Size. The
Device Final Size byte should not contain a device size code of 7 (where the device size codes are
defined in the table of the previous section).
When the single-bit ExtBytes field (bit 3) of the Device Size Extender byte = 1, the Device Size
Extender byte indicates that 2 Device Extended Size bytes and then a Device Final Size byte follow
next in line after the Device Size Extender byte. The order and format of the 2 Device Extended Size
bytes are illustrated in section 3.2.4.
Device memory size is calculated using the 2 Device Extended Size bytes and the Device Final Size
byte as follows:
(P )* 64 MBytes + Device Final Size
where:
P = the binary-encoded value provided by the Device Extended Size bytes
and
Device Final Size = the device size coded in the Device Final Size byte.
The Device Final Size byte which follows the 2 Device Extended Size bytes is formatted identical to the
single Device Size Byte used for < 64 MByte device memory sizes. Thus, 64 MBytes, obtained with a
device size code of 6, is the maximum value which can be indicated for Device Final Size. The
Device Final Size byte should not contain a device size code of 7 (where the device size codes are
defined in the table of the previous section).
Regardless of the device size stipulated by the Device Extended Size byte(s) immediately preceding
the Device Final Size byte, if the Device Final Size byte is FFH, then this entry should be treated as
an end marker for the device information tuple. The device type and speed information encoded for
this entry should be ignored.
3.2.5.3 Tuple Examples for Memory Device Size > 64 MBytes

If 16-bit PC Card Common Memory consists of 128 MBytes of Flash memory arranged in 64 MByte
pages and the page address is provided by the COR, then a software header block might be laid
out as follows:
/byte[0]: (CISTPL_DEVICE_OC, /*1CH*/
/byte[1]: /*link*/ 4,
/byte[2] /*other conditions -- 3.3 volt Vcc operation */ 1<<1,
/byte[3]: /*type/speed*/ DTYPE_FLASH | DSPEED_200NS,
/byte[4]: /*device size ¾ units/code Ð 64 MBytes*/ (1Fh<<3) | 6,
/byte[5]: /*end of tuple*/ FFh
);
/byte[6]: (CISTPL_EXTDEVICE, /*09H*/
/byte[7]: /*link*/ 6,
/byte[8]: /*number of address extension bits/page address
location/page size*/ 1<<2 ,
/byte[10]: /*device size extender ¾ 1 device extended size byte*/
7,
/byte[11]: /*device extended size byte*/ 1,
/byte[12]: /*device final size byte ¾ units/code Ð 64 MBytes*/
(1Fh<<3) | 6,
);
/byte[14]: (CISTPL_CONFIG, /*1AH*/
/byte[15]: /*link*/ 6,
/byte[16]: /*field sizes -- TPCC_RFSZ/TPCC_RMSZ/TPCC_RASZ*/
1,
/byte[17]: /*TPCC_LAST*/ 0,
/byte[18]: /*TPCC_RADR byte 0*/ 00h,
/byte[20]: /*TPCC_RMSK*/ 01h,
/byte[21]: /* end of tuple*/ FFh
);
If a 16-bit PC Card contains a 576 Mbyte Common Memory area consisting of 128 MBytes of ROM
memory, followed by a 128 MByte empty (null) area, followed by 320 MBytes of Flash memory,
then a software header block might be laid out as follows using 16 MByte pages:
/byte[0]: (CISTPL_DEVICE, /*01H*/
/byte[1]: /*link*/ 7,
/byte[2]: /*type/speed */ DTYPE_ROM| DSPEED_100NS,
/byte[3]: /*device size ¾ units/code Ð 64 MBytes*/ ((1Fh<<3) | 6)
/byte[4]: /*type/speed ¾ no device present*/ DTYPE_NULL |
DSPEED_NULL,
);
/byte[9]: (CISTPL_EXTDEVICE, /*09H*/
/byte[10]: /*link*/ Eh,
/byte[11]: /*number of address extension bits/page address
location/page size*/ ((6<<3) | 2)
/byte[12]: /*type/speed*/ DTYPE_ROM | DSPEED_100NS,
/byte[13]: /*device size extender ¾ 1 device extended size byte */
7,
/byte[14]: /*device extended size byte*/ 01h,
/byte[15]: /*device final size byte ¾ units/code Ð 64 MBytes */
((1Fh<<3) | 6)
/byte[16]: /*type/speed ¾ no device present */ DTYPE_NULL |
DSPEED_NULL,
7,
((1Fh<<3) | 6)
7,
((1Fh<<3) | 6)
);
/byte[25]: (CISTPL_CONFIG, /*1AH*/
/byte[26]: /*link*/ 8,
/byte[27]: /*field sizes -- TPCC_RFSZ/TPCC_RMSZ/TPCC_RASZ*/
2<<2 | 1,
/byte[28]: /*TPCC_LAST*/ 0,
/byte[31]: /*TPCC_RMSK byte 0*/ 00h,
/byte[34]: /* end of tuple*/ FFh
);
3.2.6 CISTPL_FUNCE: Function Extension Tuple

The function extension tuple contains information about a specific PC Card function. The information
provided is determined by the function identification tuple, CISTPL_FUNCID, that is being
extended. Each function has a defined set of extension tuples. They are described in subsections
following this one.
Table 3-15 CISTPL_FUNCE: Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_FUNCE (22H)
1 TPL_LINK Link to next tuple (see following sections)
2 TPLFE_TYPE Type of extended data (see following sections)
3áán TPLFE_DATA Function information (see following sections)
The TPLFE_TYPE field identifies the type of extended information provided about a function by this
tuple. This information varies depending on the function being extended.
The TPLFE_DATA field is the specific information being provided by the extended function. The
content of this field varies depending on the function being extended and the TPLFE_TYPE field.
Each of the function classes identified in the PC Card Functions table may be extended. Function
extension tuples are optional. If present, they relate to the function identification tuple preceding
them in the Card Information Structure.
Actual card identification extensions are to be determined by working groups concerned with
specific PC Card function classes. The following subsections describe specific extension tuples.
Multiple Function 16-bit PC Card function identification tuples are not extendible. The subsections
are numbered corresponding to the function code being extended. If a particular function may be
extended with multiple types of extended data, a further division is provided for each type of
extension data within the subsection.
3.2.6.1 Function Extension Tuples for Serial Ports

The tuples defined in this document contain information which describe the operational features of a
modem. Modems are identified using a function ID of a Serial Port and defined further using
function extension tuples to describe specific capabilities. The structure of a function extension tuples
is determined by a code appearing in the TPLFE_TYPE field. Function extension tuples are
intended for informational use and not configuration control. Only those features commonly
available and of particular interest to application software are included.
The TPLFE_TYPE field presented below, distinguishes each successive CISTPL_FUNCE serial
port/modem extension tuple. Since all function extension tuples contain the same code (22H), both
the position and the value of the TPLFE_TYPE field must be used to identify the functionality
described by a particular extension tuple. Consequently, the serial port/modem extension tuples
defined in this document must always appear immediately after the CISTPL_FUNCID tuple defined
for serial port devices.
The codes defined for the TPLFE_TYPE field are presented below. Please note that separate codes
are provided to describe the modem and serial port interfaces for individual modem services.
Separate codes are also provided to describe the modem and serial port interfaces common to all
modem services.
TPLFE_TYPE: Serial Port Extension Tuple Type Codes

7 6 5 4 3 2 1 0
PC Card Subfunction Descriptor PC Card Subfunction Id
PC Card Subfunction Id: Identifies a category of services provided by the modem and ISDN Terminal Adapter
Code Description
0 Identifies the extension tuple as a description of a serial port interface.
1 Identifies the extension tuple as a description of the capabilities of the modem interface, common to all
modem and ISDN Terminal Adapter services.
2 Identifies the extension tuple as a description of data modem services.
3 Identifies the extension tuple as a description of facsimile modem services.
4 Identifies the extension tuple as a description of voice encoding services.
5 Identifies the extension tuple as a description of the capabilities of the data modem interface.
6 Identifies the extension tuple as a description of the capabilities of the facsimile modem interface.
7 Identifies the extension tuple as a description of the capabilities of the voice modem interface.
8 Identifies the extension tuple as a description of a serial port interface for data modem services.
9 Identifies the extension tuple as a description of a serial port interface for facsimile modem services.
10 Identifies the extension tuple as a description of a serial port interface for voice modem services.
11 Identifies the extension tuple as a description of ISDN Terminal Adapter services.
12 Identifies the extension tuple as a description of the capabilities of ISDN Terminal Adapter services.
13 Identifies the extension tuple as a description of a serial port interface for ISDN Terminal Adapter
services.
14áá15 Reserved for future standardization.
PC Card Subfunction Descriptor: Identifies a sub-category of services provided by the modem

Code Description
1áá15 Identifies the extension tuple as a description of the EIA/TIA Service Class specified in the numeric value
of the code.
3.2.6.1.1 Serial Port Interface Function Extension

This tuple indicates the type and capabilities of the serial port interface used in communicating with
the modem. A specific code in the TPLFE_TYPE field is defined to describe the serial port interface
to all modem services. Additional codes are also defined to describe the serial port interface for each
available modem service (data, facsimile, voice, and/or ISDN terminal adapter). Please refer to the
Serial Port Extension Tuple Type Codes Table for a list of all TPLFE_TYPE field codes.
The UART is identified with a generic reference to the de-facto standard it conforms to (i.e., 16450,
16550) not, however, a specific product identification. The UART capabilities field is provided to
describe the asynchronous data formats supported in UART implementations which vary from the
standard. When describing a de-facto standard UART the contents of this field may be set to zero.
The structure of the tuple and the codes currently defined for each field are presented below.
Table 3-16 CISTPL_FUNCE: Serial Port Interface Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
1 TPL_LINK Link to next tuple (04H minimum)
2 TPLFE_TYPE Type of extended data (00H, 08H, 09H, 0AH, or 0DH)
3 TPLFE_UA Identification of the type of UART in use.
4áá5 TPLFE_UC Identification of the UART capabilities.
TPLFE_UA: UART Identification Field

7 6 5 4 3 2 1 0
RFU, set to zero. interface
interface: The type of the UART is described using the codes defined below
Code Description
0 Indicates that an 8250 UART is present.
1 Indicates that a 16450 UART is present.
2 Indicates that a 16550 UART is present.
3 Indicates that an 8251 USART is present.
4 Indicates that an 8530 SCC is present.
5 Indicates that an 85230 ESCC is present.
6áá31 Reserved for future standardization.
TPLFE_UC: UART Capabilities Field

7 6 5 4 3 2 1 0
RFU, set to zero. even parity odd parity mark parity space parity
RFU, 2 stop bits 1.5 stop bits 1 stop bit 8 bit char 7 bit char 6 bit char 5 bit char
set to zero
Field Description
space parity The protocol where the parity bit is always reset.
mark parity The protocol where the parity bit is always set.
odd parity The protocol where the parity bit is generated to create an odd number of set bits.
even parity The protocol where the parity bit is generated to create an even number of set bits.
5 bit char The encoding of data where each serial data unit contains 5 data bits.
1 stop bit: The use of one (1) stop bit encoded in each serial data unit.
1.5 stop bit The use of one and one-half (1.5) stop bits encoded in each serial data unit.
2 stop bit The use of two (2) stop bits encoded in each serial data unit.
When the field is set (1) the specified capability is supported, when the field is reset (0) the specified
capability is not supported.
3.2.6.1.2 Function Extension Tuple for Modem and ISDN Interface

This structure describes the characteristics of the modem interface when considered separately from
the UART. This includes an indication of the types of flow control supported, the size of the
command buffer, DCE to DTE buffer, and the DTE to DCE buffer.
A specific code in the TPLFE_TYPE field is defined to describe the modem interface to all modem
services. Additional codes are also defined to describe the modem interface for each available
modem service (data, facsimile, voice, and/or ISDN Terminal Adapter). Please refer to the Serial
Port Extension Tuple Type Codes table for a list of all TPLFE_TYPE field codes.
Table 3-17 CISTPL_FUNCE: Modem and ISDN Interface Function Extension Tuple
Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE Type of extended data (01H, 05H, 06H, 07H, or 0CH)
3 TPLFE_FC Supported flow control methods.
4 TPLFE_CB Size in bytes of the DCE command buffer.
5áá7 TPLFE_EB Size in bytes of the DCE to DTE buffer.
8áá10 TPLFE_TB Size in bytes of the DTE to DCE buffer.
TPLFE_FC: Flow Control Methods

7 6 5 4 3 2 1 0
RFU, set to zero. transparent rx h/w flow tx h/w flow rx xon/xoff tx xon/xoff
ctrl ctrl
Field Description
tx xon/xoff DTE to DCE transmit flow control using DC1/DC3 for XON/XOFF
rx xon/xoff DCE to DTE receive flow control using DC1/DC3 for XON/XOFF
tx h/w flow DTE to DCE transmit flow control (CTS)
ctrl
rx h/w flow DCE to DTE receive flow control (RTS)
ctrl
transparent DCE to DCE flow control
When the field is set (1) the specified flow control method is supported, when the field is reset (0) the
specified flow control method is not supported.
TPLFE_CB: DCE Command Buffer

7 6 5 4 3 2 1 0
size of DCE command buffer
size of DCE command buffer

Code Description
v/4 - 1 Indicates the number of bytes within the command line buffer. To compute the actual size of the
command buffer, the value of this field (represented in the formula as n) is increased by 1, then
multiplied by 4 ((n+1)* 4). A command buffer of 256 bytes is represented by a field value of 3FH (63).
TPLFE_EB: Modem DCE to DTE Buffer Field

7 6 5 4 3 2 1 0
size of DCE-DTE buffer Ñ LSB of LSW
size of DCE-DTE buffer Ñ MSB of LSW
size of DCE-DTE buffer Ñ LSB of MSW
size of DCE to DTE buffer

Code Description
0 Indicates that no DCE to DTE buffer is present.
1áá16777215 Indicates that a DCE to DTE buffer is available and its size in bytes.
The largest possible size in bytes of the modem's DCE to DTE buffer used in buffering received data,
not including the UART FIFO buffer. The actual number of bytes in the buffer appears in this field to
allow a more precise definition of its size.
TPLFE_TB: Modem DTE to DCE Buffer Field

7 6 5 4 3 2 1 0
size of DTE-DCE buffer Ñ LSB of LSW
size of DTE-DCE buffer Ñ MSB of LSW
size of DTE-DCE buffer Ñ LSB of MSW
size of DTE to DCE buffer

Code Description
0 Indicates that no DTE to DCE buffer is present.
1áá16777215 Indicates that a DTE to DCE buffer is available and its size in bytes.
The largest possible size in bytes of the modem's DTE to DCE buffer used in buffering transmitted
data, not including the UART FIFO buffer. The actual number of bytes in the buffer appears in this field
to allow a more precise definition f its size.
3.2.6.1.3 Function Extension Tuple for Data Modem

This structure describes the capabilities of the data modem. This includes the level of error
correction and data compression supported, the highest possible data rate supported in the DTE to
UART interface of the data modem, the command set in use for DTE to DCE control and
configuration (e.g. AT command set), the ITU-T(CCITT) standard and non ITU-T(CCITT) standard
modulations supported, the standardized data encryption methods supported, and the ITU-T(CCITT)
defined country code of the target market The escape codes supported for the return to command
mode are also described. Features which cannot be included in the categories reserved for the
capabilities mentioned above are included in the TPLFE_EF field, the ÒMiscellaneous End User
Feature SelectionÓ field.
The ITU-T(CCITT) country code field defines the countries targeted for distribution of the data
modem. This field has been specified to support a maximum value of 254 (255 or FFH is reserved as
a country code list terminator, see below) in accordance with the ITU-T(CCITT) standard T.35 which
has assigned each member country or area a unique 8 bit value. Please refer to T.35 Annex A for a
list of country or area codes currently assigned.
To specify support of multiple countries, the country code field TPLFE_CD was positioned as the last
field in the Data Modem function extension tuple. Additional country codes may be specified by
increasing the value of the TPL_LINK field by one for each additional country specified. A value of
FFH is used to indicate the end of the country code list if it does not extend to the end of the tuple.
Any additional fields which follow this value must be represented by an appropriate increase in the
value of the TPL_LINK field and are considered a description of manufacturer specific capabilities.
Table 3-18 CISTPL_FUNCE: Data Modem Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
1 TPL_LINK Link to next tuple (0CH minimum)
2 TPLFE_TYPE Type of extended data (02H, see Serial Port Extension Tuple Type Codes)
3áá4 TPLFE_UD The highest possible bit rate in the DTE to UART interface.
5áá6 TPLFE_MS Modulation standards supported
7 TPLFE_EM Error correction/detection protocols and non ITU-T(CCITT) modulation schemes supported
8 TPLFE_DC Data compression protocols supported
9 TPLFE_CM Command protocols supported
10 TPLFE_EX Indication of the escape mechanisms supported
11 TPLFE_DY Standardized data encryption
12 TPLFE_EF Miscellaneous end user feature selection
13áán TPLFE_CD The ITU-T(CCITT) defined country code (ITU-T(CCITT) T.35/T.35 Annex A)
TPLFE_UD: UART Interface Field

7 6 5 4 3 2 1 0
RFU, set to zero. DTE to UART maximum data rate MSB
DTE to UART maximum data rate - LSB
DTE to UART maximum data rate

Code Description
v/75 Indicates the highest DTE to UART bit rate supported. To compute the actual bit rate, the value of this
field (represented in the formula as n) is multiplied by 75 (n * 75). A bit rate of 115,200 would be
represented by a field value of 600H (1536).
TPLFE_MS: Modulation Standards Field

7 6 5 4 3 2 1 0
V.26bis V.26 V.22bis Bell 212A V.22A&B V.23 V.21 Bell 103
RFU, set to zero. V.90 V.34 V.32bis V.32 V.29 V.27bis
Field Description
Bell 103: 300 bps duplex modem standardized for use in the GSTN.
V.21: 300 bps duplex modem standardized for use in the GSTN.
V.23: 600/1200 baud modem standardized for use in the GSTN.
V.22A&B: 1200 bps duplex modem standardized for use in the GSTN and for telephone-type leased circuits.
Bell 212A: 2400 bps duplex modem standardized for use in the GSTN.
V.22bis: 2400 bps duplex modem using the frequency-division technique standardized for use on the GSTN and
on point-to-point two-wire leased telephone-type circuits.
V.26: 2400 bps modem standardized for use on 4-wire leased telephone-type circuits.
V.26bis: 2400 bps duplex modem standardized for use in the GSTN, specifying two alternate encoding
schemes (A or B).
V.27bis: 4800/2400 bps modem with automatic equalizer standardized for use on leased telephone-type
circuits.
V.29: 9600/7200/4800 bps modem standardized for use on point-to-point 4-wire leased telephone-type
circuits
V.32: A family of two-wire, duplex modems operating at data rates of up to 9600 bps for use on the GSTN or
on lease telephone-type circuits.
V.32bis: A family of two-wire, duplex modems operating at data rates of up 14400 bps for use on the GSTN or
on lease telephone-type circuits.
V.34: A modem operating at data signaling rates of up to 33,600 bps for use on the GSTN and on leased
point-to-point 2-wire telephone-type circuits.
V.90 A modem operating at data signaling rates of up to 56,000 bps (downstream) and 33,600 bps
(upstream) for use on the GSTN when connecting to a digital switched network.
When the field is set (1) the specified standard is supported, when the field is reset (0) the specified
standard is not supported.
TPLFE_EM: Error Correction/Detection Protocols and Non ITU-T(CCITT) Modulation Schemes

7 6 5 4 3 2 1 0
RFU, set to zero. V.42 / LAPM MNP 2-4
Field Description
MNP 2-4: Error correction/detection protocols progressively defined in MNP levels 2, 3, and 4.
V.42/LAPM: Error correction/detection protocol defined by the ITU-T(CCITT).
When the field is set (1) the specified error correction/detection services and/or non ITU-T(CCITT)
modulation schemes is supported, when the field is reset (0) the specified error correction/detection
services and/or non ITU-T(CCITT) modulation schemes is not supported.
TPLFE_DC: Data Compression Protocols

7 6 5 4 3 2 1 0
RFU, set to zero. MNP 5 V.42bis
Field Description
V.42bis Data compression protocol defined by ITU-T(CCITT), requiring additional support of V.42.
MNP 5 Data compression protocol requiring the additional support of MNP 2, 3, or 4.
When the field is set (1) the specified compression protocol is supported, when the field is reset (0) the
specified compression protocol is not supported.
TPLFE_CM: Command Protocols

7 6 5 4 3 2 1 0
RFU, set to DMCL V.25A V.25bis MNP AT AT3 AT2 AT1
zero.
Field Description
AT1 The ÒActionÓ AT command group as defined in the Automatic Calling Equipment (ACE) command
standard ANSI/EIA/TIA 602.
AT2 The ÒACE/DTE Interface ParametersÓ AT command group as defined in the Automatic Calling
Equipment (ACE) command standard ANSI/EIA/TIA 602.
AT3 The ÒACE ParametersÓ AT command group as defined in the Automatic Calling Equipment (ACE)
command standard ANSI/EIA/TIA 602.
MNP AT The command mode convention available for DTE to DCE control and configuration of the available
MNP protocols.
V.25bis A specification of the formatting and response of DCE commands used in automatic calling
procedures over the 100-series interchange circuits.
V.25A A specification on test facilities relating to the implementation of the V.25bis automatic calling
procedure.
DMCL A command mode convention available for DTE to DCE control and configuration.
When the field is set (1) the specified command protocol is fully supported, when the field is reset (0)
the specified command protocol is not fully supported.
TPLFE_EX: Escape Mechanisms Field

7 6 5 4 3 2 1 0
RFU, set to zero. User Defined +++ BREAK
Escape Char.
Field Description
BREAK The standardized BREAK represented by a sequence of 0 bits of a specified length.
+++ A sequence of characters used to return the modem to command mode.
User Defined Indicates support for a user defined escape character.
Escape Char.
When the field is set (1) the specified escape mechanism is supported, when the field is reset (0) the
specified escape mechanism is not available to return the modem to command mode.
TPLFE_DY: Standardized Data Encryption

7 6 5 4 3 2 1 0
RFU, set to zero.
TPLFE_EF: Miscellaneous End User Feature Selection

7 6 5 4 3 2 1 0
RFU, set to zero. Caller Id
Field Description
Caller Id A protocol which defines the encoding of specific information to allow the answering station to identify
the calling station.
When the field is set (1) caller id decoding services are provided.
When the field is reset (0) caller id decoding services are not provided.
TPLFE_CD: ITU-T(CCITT) Country Code

7 6 5 4 3 2 1 0
country code
Field Description
country code ITU-T(CCITT) numeric code assigned to the country targeted for distribution of this modem (Annex A,
Recommendation T.35).
A value of 0áá254 is the assigned ITU-T(CCITT) country code.
A value of 255 indicates the end of the variable length country code list if it does not extend to the end of
the tuple. The fields which follow this field when a value of 255 is present represent manufacturer
specific capabilities.
3.2.6.1.4 Function Extension Tuple for Document Facsimile

The Document Facsimile function extension tuple describes the capabilities of the facsimile modem.
This includes the highest possible data rate in the DTE to UART interface of the facsimile modem,
the ITU-T(CCITT) modulation standards supported, the ITU-T(CCITT) defined country code of the
target market, the standardized data encryption methods supported, and the various document
facsimile features supported.
A separate tuple shall be used to describe the capabilities of each supported Service Class. Thus a
facsimile modem supporting the EIA/TIA-578 Service Class 1 standard and the draft standard
Service Class 2 must include two separate extension tuples. The PC Card Subfunction Descriptor
represented in the least significant nibble of the TPLFE_TYPE field would vary with each tuple.
The document facsimile services of Error Correction Mode, Voice Request, Polling, File Transfer,
Password, Selective Polling, Character Mode, and Copy Quality were not included in this tuple.
Many have not yet achieved wide spread use and are still in the midst of the ITU-T(CCITT)
approval process. Others require control and configuration through the use of manufacturer specific
AT commands and are consequently not within the scope of this document.
The ITU-T(CCITT) country code field defines the country targeted for distribution of the facsimile
modem. This field has been specified to support a maximum value of 254 (255 or FFH is reserved as
a country code list terminator, see below) in accordance with the ITU-T(CCITT) standard T.35 which
has assigned each member country or area a unique 8 bit value. Please refer to T.35 Annex A for a
list of country or area codes currently assigned.
To specify support of multiple countries, the country code field TPLFE_CF is positioned as the last
field in the Document Facsimile function extension tuple. Additional country codes may be specified
by increasing the value of the TPL_LINK field by one for each additional country specified. A value
of FFH indicates the end of the country code list if it does not extend to the end of the tuple. Any
additional fields which follow this value must be represented by an appropriate increase in the
Table 3-19 CISTPL_FUNCE: TPCID_FF: Document Facsimile Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
1 TPL_LINK Link to next tuple (8 minimum)
2 TPLFE_TYPE Type of extended facsimile features (13H, 23H or 33H, see Serial Port Extension Tuple Type
Codes)
3áá4 TPLFE_UF The highest possible data rate in the DTE to UART interface.
5 TPLFE_FM The supported ITU-T(CCITT) modulation standards
6 TPLFE_FY Standardized data encryption
7áá8 TPLFE_FS The document facsimile feature selection
9áán TPLFE_CF The ITU-T(CCITT) defined country code (ITU-T(CCITT) T.35/T.35 Annex A)
TPLFE_TYPE: Extended Facsimile Features Type

7 6 5 4 3 2 1 0
Field Description
PC Card A value of 03 indicates that document facsimile services are described in this tuple.
Subfunction
Id
PC Card Indicates the EIA/TIA Service Class described in this tuple.
Subfunction Legal values are 01áá03, i.e., a value of 1 indicates support of EIA/TIA-578 Service Class 1.
Descriptor
A separate extension tuple is required for each Service Class described.
TPLFE_UF: UART Interface Field

7 6 5 4 3 2 1 0
RFU, set to zero. DTE to UART maximum data rate Ñ MSB
DTE to UART maximum data rate Ñ LSB
Field Description
DTE to The highest bit rate supported for communications with the DTE (v) in increments of 75 bps, where
UART the field value is computed by v/75.
maximum To compute the actual bit rate, the value of this field (represented in the formula as n) is multiplied by
data rate 75 (n * 75). A bit rate of 115,200 would be represented by a field value of 600H (1536).
TPLFE_FM: ITU-T(CCITT) Modulation Standards

7 6 5 4 3 2 1 0
RFU, set to zero. V.34 V.33 V.17 V.29 V.27ter V.21-C2
Field Description
V.21-C2 300 bps duplex modem standardized for universal use in the GSTN
V.27ter 4800/2400 bps modem standardized for use in the GSTN
V.29 9600/7200/4800 bps modem standardized for use on point-to-point 4-wire leased telephone-type
circuits
V.17 14.4-K/12000/9600/7200 bps modem using trellis-coded modulation (TCM) standardized for use in the
GSTN
V.33 14.4-K/12000/9600/7200 bps modem using trellis-coded modulation (TCM) standardized for use on
point-to-point 4-wire leased telephone-type circuits
V.34 A modem operating at data signaling rates of up to 33,600 bps for use on the GSTN.
TPLFE_FY: Standardized Data Encryption

7 6 5 4 3 2 1 0
RFU, set to zero.
TPLFE_FS: Document Facsimile Feature Selection

7 6 5 4 3 2 1 0
password file transfer polling voice request error correct T.6 T.4 T.3
mode
RFU, set to zero.
Field Description
T.3 Standardization of group 2 facsimile apparatus for document transmission.
T.4 Facsimile coding schemes and coding control functions for group 3 facsimile apparatus.
T.6 Facsimile coding schemes and coding control functions for group 4 facsimile apparatus.
error correct A mode of operation allowing error correction of document facsimile page data.
mode
voice request Interruption of the transmission of a facsimile image to allow voice contact with the remote station.
polling A request to receive or send a facsimile regardless of which station is considered the originator.
file transfer ITU-T(CCITT) defined procedure for transferring files between PC based facsimile DCE 's.
password A mode of operation allowing secured facsimile transmissions.
When the field is set (1) the feature is supported in the specified Service Class, when the field is reset
(0) the feature is not supported the specified Service Class.
TPLFE_CF: ITU-T(CCITT) Country Code

7 6 5 4 3 2 1 0
country code
Field Description
3.2.6.1.5 Function Extension Tuple for Voice Function

This structure describes the capabilities of a modem equipped to process digitally encoded voice
data. The highest possible data rate in the DTE to UART interface of the voice modem is described.
The PC Card Subfunction Descriptor specifies the number of the Service Class used to activate the
voice command mode.
The sample rate, size, and compression methods supported are represented in a series of three
separate tuples. Each tuple is repeated for the supported sample rates, sizes, and compression
methods. These fields serve only to described the range of supported options not, however, the
various combinations of each. As extended voice AT commands are defined by the EIA/TIA and
the operation of a voice equipped modem is standardized this tuple will be appropriately updated.
Table 3-20 CISTPL_FUNCE: Voice Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE Type of extended data (84H assuming Service Class 8, see Serial Port Extension Tuple Type
Codes)
3áá4 TPLFE_UV The highest possible data rate in the DTE to UART interface.
5áá TPLFE_SR A variable length list of the sample rates supported.
áá TPLFE_SS A variable length list of the sample sizes supported.
áán TPLFE_SC A variable length list of the EIA/TIA Compression Method Identifiers. It is not yet certain if the
EIA/TIA will maintain the assignment of these numeric id's. Consequently, until the outcome is
determined, if manufacturer specific data is present at the end of the tuple, this field shall remain
set to zero.
TPLFE_TYPE: Type of CISTPL_FUNCE Extended Data

7 6 5 4 3 2 1 0
Field Description
PC Card A value of 04 indicates the presence of PCM voice encoding capabilities.
Subfunction See Serial Port Extension Tuple Type Codes for a list of all Subfunction Codes defined.
Id
PC Card The numeric value of the Service Class reserved for the definition of the extended voice AT
Subfunction commands (currently being standardized). Defined values are in the range 4áá15.
Descriptor The actual value used by the manufacturer shall be indicated in this field.
A value of zero (0) indicates that voice encoding services are provided using a protocol other than that
defined in the applicable Service Class.
TPLFE_UV: UART Interface Field

7 6 5 4 3 2 1 0
Field Description
DTE to The highest bit rate supported for communications with the DTE (v) in increments of 75 bps, where
UART the field value is computed by v/75.
maximum To compute the actual bit rate, the value of this field (represented in the formula as n) is multiplied by
data rate 75 (n * 75). A bit rate of 115,200 would be represented by a field value of 600H (1536).
TPLFE_SR: Sample Rate Field

7 6 5 4 3 2 1 0
RFU, set to Sample Rate in KHz
zero.
RFU, set to Sample Rate in KHz/100
zero.
Field Description
Sample Rate The voice sampling rate supported in increments of a 1000 Hz.
in KHz Legal values are in the range 1áá99. A value of 0BH (11) indicates an 11 KHz sample rate.
A value of zero (0) indicates the end of the variable length list of supported sample rates. The next byte
represents the beginning of the variable length list of supported sample sizes.
Sample Rate The voice sampling rate supported in units of 1/100 KHz. The fractional component of 11.025 KHz is
in KHz/100 represented in this field as 02H. The final sample rate is derived by adding the fractional component in
this field to the whole number value in the field Sample Rate in KHz. A value of 11.025 KHz would be
derived by adding 0BH KHz or 11 KHz to 02H/100 KHz or 0.02 KHz for a value of 11.02 KHz in four
significant digits.
Legal values are in the range 1áá99.
TPLFE_SS: Sample Size Field

7 6 5 4 3 2 1 0
RFU, set to zero. Sample Size in Bits
RFU, set to zero. Sample Size in Bits/10
Field Description
Sample Size The sample size supported in units of 1 bit.
in Bits Legal values are in the range 1áá15. The integer portion of 2.66 bits is represented in this field as 02H.
A value of zero (0) indicates the end of the variable length list of supported sample sizes. The next byte
represents the beginning of the variable length list of supported data compression methods.
Sample Size The sample size supported in units of 1/10 bits.
in Bits/10 Values in the range 0áá9 indicate the fractional component of the supported sample size in units of 1/10
bits. The final sample size is derived by adding the fractional component in this field to the whole
number value in the field Sample Size in Bits. A sample size of 2.66 bits would be derived by adding
02H or 2 bits from Sample Size in Bits to 06H or 0.6 bits from Sample Size in Bits/10 for a value of 2.6
bits in 2 significant digits.
TPLFE_SC: Voice Compression Methods

7 6 5 4 3 2 1 0
Voice Compression Method Id
(RFU, set to zero.)
Voice Compression Method Id

Value Description
1áá255 Indicates the EIA/TIA assigned Compression Method Identifier associated with the supported
compression method.
0 Indicates the end of the variable length list of supported Compression Method Identifiers. The next byte
represents the beginning of fields containing manufacturer specific data. This byte need not be present
if the list extends to the end of the tuple.
Assuming the EIA/TIA presides over the assignment of id's to the many compression methods
currently available, this field represents the EIA/TIA assigned Compression Method Identifier.
3.2.6.1.6 Function Extension Tuple for ISDN Terminal Adapter

This structure describes the capabilities of ISDN Terminal Adapter. This includes the highest
possible data rate in the DTE to UART interface of ISDN Terminal Adapter, Physical Layer protocols
supported, Data Link Layer protocols supported, Network Layer protocols supported, Rate Adaption
protocol supported, other services supported, the command set in use for DTE to DCE control and
configuration(e.g.AT command set), the ITU-T(CCITT) standard defined country code of the target
market. The escape codes supported for return to command mode are also described.
The ITU-T(CCITT) country code field defines the countries targeted for distribution of ISDN
Terminal Adapter. This field has been specified to support a maximum value of 254 (255 or FFH is
reserved as a country code list terminator, see below) in accordance with the ITU-T(CCITT) standard
T.35 which has assigned each member country or area a unique 8 bit value. Please refer to T.35
Annex A for a list of country or area codes currently assigned.
To specify support of multiple countries, the country code field TPLFE_CD was positioned as the last
field in ISDN Terminal Adapter function extension tuple. Additional country codes may be specified
by increasing the value of the TPL_LINK field by one for each additional country specified. A value
of FFH is used to indicate the end of the country code list if it does not extend to the end of the tuple.
Any additional fields which follow this value must be represented by an appropriate increase in the
Table 3-21: CISTPL_FUNCE: ISDN Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE Type of extended data (0BH, see Serial Port Extension Tuple Type Codes)
3 TPLFE_LAYER1 Physical layer protocols supported
4 TPLFE_LAYER2 Data Link layer protocols supported
5 TPLFE_LAYER3 Network layer protocols supported
6 TPLFE_RA Rate adoption protocols supported
7 TPLFE_SP Speech Standards Field
8 TPLFE_DT Data Transfer Standards Field
9 TPLFE_AD Audio Standards Field
10 TPLFE_VD Video Standards Field
11 TPLFE_FE Miscellaneous Feature Selection
12..13 TPLFE_UD The highest possible data rate in the DTE to UART interface.
14 TPLFE_DC Data compression protocols supported
15 TPLFE_CM Command protocols supported
16 TPLFE_EX Indication of the escape mechanisms supported
17--n TPLFE_CD The ITU-T(CCITT) defined country code (ITU-T(CCITT) T.35/T.35 Annex A)
TPLFE_LAYER1: Layer 1 protocols (Physical Layer)

7 6 5 4 3 2 1 0
RFU, set to zero. NT1 S/T I.431 I.430
Field Description
I.430: Basic user-network Interface - Layer 1 specification.
I.431: Primary rate user-network Interface - Layer 1 specification.
S/T S/T(Local Bus/Terminal) Interface Connector.
NT1 NT1(Network Termination 1).
TPLFE_LAYER2: Layer 2 protocols (Data Link Layer)

7 6 5 4 3 2 1 0
RFU, set to zero. Q.922 Q.921
Field Description
Q.921: ISDN user-network interface - Data link layer specification.
Q.922: ISDN Data Link Layer specification for Frame mode Bearer services.
TPLFE_LAYER3: Layer 3 protocols (Network Layer)

7 6 5 4 3 2 1 0
RFU, set to zero. Q.933 Q.931
Field Description
Q.931: ISDN user-network interface layer 3 specification for basic call control.
Q.933: ISDN Signalling specification for Frame mode basic call control.
TPLFE_RA: Rate Adaption protocols

7 6 5 4 3 2 1 0
RFU, set to zero. I.465 I.463
Field Description
I.463: Support of data terminal equipments(DTEs) with V-series type interfaces by an ISDN. (V.110)
I.465: Support by an ISDN of data terminal equipment with V-series type interface with provision for
statistical multiplexing. (V.120)
TPLFE_SP: Speech Standards Field

7 6 5 4 3 2 1 0
RFU, set to zero. G.721 G.711
Field Description
G.711: Pulse mode modulation(PCM) of voice frequencies.
G.721: 32Kbit/s adaptive differcential pulse code modulation (ADPCM).
TPLFE_DT: Data Transfer Standards Field

7 6 5 4 3 2 1 0
RFU, set to zero. MLPPP PPP X.75
Field Description
X.75: Packet-switched signaling system between public networks providing data services.
PPP: Piont-to-Point Protocol.
MLPPP MultiLink Piont-to-Point Protocol.
TPLFE_AD: Audio Standards Field

7 6 5 4 3 2 1 0
RFU, set to zero. G.725 G.722
Field Description
G.722: 7 kHz audio-coding within 64 kbit/s.
G.725: System aspects for the use of 7 kHz audio codec within 64 kbit/s.
TPLFE_VD: Video Standards Field

7 6 5 4 3 2 1 0
RFU, set to zero. H.320 H.261
Field Description
H.261: Codec for audiovisual services at n x 384 kbit/s.
H.320: Narrow band visual telephone systems and terminal equipment.
TPLFE_EF: Miscellaneous Feature Selection

7 6 5 4 3 2 1 0
RFU, Aux. Analog Port. G4 FAX Circuit mode Packet mode
set to zero.
Field Description
Packet mode Packet mode
Circuit mode Circuit mode
G4 FAX Group 4 Facsimile service
Aux. Number of supported Analog Ports.
Analog Port. 0 : no ports supported 6 : six ports supported 12 : twelve ports supported.
1 : one port supported 7 : seven ports supported 13 : thirteen ports supported
2 : two ports supported 8 : eight ports supported 14 : fourteen ports supported
3 : three ports supported 9 : nine ports supported 15 : fifteen ports supported
4 : four ports supported 10 : ten ports supported
5 : five ports supported 11 : eleven ports supported
TPLFE_UD: UART Interface Field

7 6 5 4 3 2 1 0
DTE to UART maximum data rate

Code Description
v/75 Indicates the highest DTE to UART bit rate supported. To compute the actual bit rate, the value of this
field (represented in the formula as n) is multiplied by 75 (n * 75). A bit rate of 115,200 would be
represented by a field value of 600H (1536).
TPLFE_DC: Data Compression Protocols

7 6 5 4 3 2 1 0
RFU, set to zero. V.42bis
Field Description
V.42bis Data compression protocol defined by ITU-T(CCITT),
When the field is set (1) the specified compression protocol is supported, when the field is reset (0) the
specified compression protocol is not supported.
TPLFE_CM: Command Protocols

7 6 5 4 3 2 1 0
RFU, set to DMCL V.25A V.25bis RFU, set to AT3 AT2 AT1
zero. zero.
Field Description
AT1 The ÒActionÓ AT command group as defined in the Automatic Calling Equipment (ACE) command
standard ANSI/EIA/TIA 602.
AT2 The ÒACE/DTE Interface ParametersÓ AT command group as defined in the Automatic Calling
Equipment (ACE) command standard ANSI/EIA/TIA 602.
AT3 The ÒACE ParametersÓ AT command group as defined in the Automatic Calling Equipment (ACE)
command standard ANSI/EIA/TIA 602.
V.25bis A specification of the formatting and response of DCE commands used in automatic calling
procedures over the 100-series interchange circuits.
V.25A A specification on test facilities relating to the implementation of the V.25bis automatic calling
procedure.
DMCL A command mode convention available for DTE to DCE control and configuration.
TPLFE_EX: Escape Mechanisms Field

7 6 5 4 3 2 1 0
RFU, set to zero. User Defined +++ BREAK
Escape Char.
Field Description
BREAK The standardized BREAK represented by a sequence of 0 bits of a specified length.
+++ A sequence of characters used to return the modem to command mode.
User Defined Indicates support for a user defined escape character.
Escape Char.
When the field is set (1) the specified escape mechanism is supported, when the field is reset (0) the
specified escape mechanism is not available to return the modem to command mode.
TPLFE_CD: ITU-T(CCITT) Country Code

7 6 5 4 3 2 1 0
country code
Field Description
3.2.6.2 Function Extension Tuple for Disk

See also the PC Card ATA Specification for Disk Device function extension tuples. Additional
function extension tuples may be added in the future for PC Card ATA and other disk interfaces.
Table 3-22 CISTPL_FUNCE: Disk Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE Extension type: Disk Device Interface tuple (01H)
3 TPLFE_DATA Interface type: PC Card-ATA Interface (01H)
Table 3-23 CISTPL_FUNCE: Combined PC Card ATA Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE Extension type: Basic PC Card ATA Interface tuple (02H)
3 TPLFE_DATA
RFU RFU RFU D U S V
4 TPLFE_DATA
RFU I E N P3 P2 P1 P0
Data Fields for PC Card ATA Function Extension Tuple

Field Description
V VPP[2::1] Power
0 Not Required
1 Required for Media Modification Accesses
2 Required for all Media Accesses
3 Required Continuously
S Silicon
0 Rotating Device
1 Silicon Device
U Unique Drive Identifier
0 Identify Drive Model / Serial Number may not be unique
1 Identify Drive Model / Serial Number is guaranteed unique
D Dual Drive
0 single drive on card.
1 two drives on card.
P0 Sleep Ñ Low Power Mode
0 Sleep Mode Not Supported
1 Sleep Mode Supported
P1 Standby Ñ Low Power Mode
0 Standby Mode Not Supported
1 Standby Mode Supported
P2 Idle Ñ Low Power Mode
0 Idle Mode Not Supported
1 Idle Mode Supported
P3 Auto Ñ Low Power Mode
0 Low Power Mode Use Required to Minimize Power
1 Drive Automatically Minimizes Power. No need for host to actively power manage.
N 3F7/377 Register Inhibit Available
0 All Primary and Secondary I/O Addressing Modes include ports 3F7H or 377H.
1 Some Primary or Secondary I/O Addressing Modes exclude 3F7H and / or 377H for floppy
interference avoidance.
E Index Emulated
0 Index Bit is Not Emulated
1 Index Bit is Supported or Emulated
I IOIS16# on Twin Card
0 IOIS16# use is Unspecified on Twin-Card Configurations
1 IOIS16# is asserted only for Data Register on Twin-Card Configurations
RFU Reserved (set to zero).
Table 3-24 CISTPL_FUNCE: Dual-Drive Card PC Card ATA Function Extension Tuple
Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE Extension type: Basic PC Card ATA Interface tuple
(02H for first drive and 03H for additional drive on card)
3 TPLFE_DATA
RFU RFU RFU D U S V
4 TPLFE_DATA
RFU I E N P3 P2 P1 P0
3.2.6.3 Function Extension Tuple for LAN

The tuples defined here contain information about the operational features of LAN cards. LAN cards
are identified by a function ID of LAN and are further defined using function extension tuples to
describe specific capabilities. Function extension tuples are optional for LAN cards. The general
form of the LAN function extension tuple is:
Table 3-25 CISTPL_FUNCE: LAN Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
1 TPL_LINK Link to next tuple (m-1 minimum)
2 TPLFE_TYPE LAN type / feature code
3áám TPLFE_DATA Content and format-dependent on LAN_FEATURE
Field LAN_FEATURE is a code indicating the feature being described. The structure and content of
the DATA field varies according to LAN_FEATURE. A CIS may contain zero, one or more of these
tuples. If the LAN card doesn't support a feature it will lack the corresponding Extension Tuple. If it
supports more than one variation of a particular feature, it can have multiple extension tuples with
the same LAN_FEATURE value, each describing a different variant of the same feature. Defined
LAN_FEATURE values are:
TPLFE_TYPE: Values for LAN Functions
Value Description
1 LAN_TECH Technology type, e.g. ethernet, token ring, etc.
2 LAN_SPEED Raw bit rate
3 LAN_MEDIA Cable or transmission media
4 LAN_NID Node identification
5 LAN_CONN Connector standard
3.2.6.3.1 LAN_TECH Function Extension Tuple
Table 3-26 CISTPL_FUNCE: LAN_TECH Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE LAN_TECH (01H)
3 LAN_TECH_CODE Network technology code
LAN_TECH_CODE Values
Value
1 Arcnet
2 Ethernet
3 Token Ring
4 Local Talk
5 FDDI/CDDI
6 ATM
7 Wireless
3.2.6.3.2 LAN_SPEED Function Extension Tuple
Table 3-27 CISTPL_FUNCE: LAN_SPEED Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE LAN_SPEED (02H)
3 LAN_SPEED_VALUE Raw bit rate
LAN_SPEED_VALUE is a 32 bit integer containing the raw network bit rate.
3.2.6.3.3 LAN_MEDIA Function Extension Tuple
Table 3-28 CISTPL_FUNCE: LAN_MEDIA Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE LAN_TECH (03H)
3 LAN_MEDIA_CODE Cable or transmission media
LAN_MEDIA_CODE Values
Value Description
1 Unshielded twisted pair
2 Shielded twisted pair
3 Thin coax
4 Thick coax
5 Fiber
6 Spread spectrum radio 902áá928 MHz
7 Spread spectrum radio 2.4 GHz
8 Spread spectrum radio 5.4 GHz
9 Diffuse infra red
10 Point to point infra red
3.2.6.3.4 LAN_NID Function Extension Tuple
Table 3-29 CISTPL_FUNCE: LAN_NID Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE LAN_NID (04H)
3 LAN_NID_SZ Number of bytes in LAN node ID
4áám LAN_NID_CODE Binary value of LAN node ID
3.2.6.3.5 LAN_CONN Function Extension Tuple
Table 3-30 CISTPL_FUNCE: LAN_CONN Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
2 TPLFE_TYPE LAN_CONN (05H)
3 LAN_CONN_CODE Connector standard compliance code
LAN_CONN_CODE Values
Value Description
0 Open connector standard
1 Closed connector standard
3.2.6.4 Function Extension Tuple for ISDN

The tuples defined here contain information about the operational features of ISDN cards. ISDN
cards are identified by a function ID of ISDN and are further defined using function extension tuples
to describe specific capabilities. Function extension tuples are optional for ISDN cards. The general
form of the ISDN function extension tuple is:
Table 3-31: CISTPL_FUNCE: ISDN Function Extension Tuple

Byte 7 6 5 4 3 2 1 0
1 TPL_LINK Link to next tuple (m-1 minimum)
2 TPLFE_TYPE ISDN type / feature code
3áám TPLFE_DATA Content and format-dependent on ISDN FEATURE
Field ISDN_FEATURE is a code indicating the feature being described. The structure and content of
the DATA field varies according to ISDN_FEATURE. A CIS may contain zero, one or more of these
tuples. If the ISDN card doesn't support a feature it will lack the corresponding Extension Tuple. If it
supports more than one variation of a particular feature, it can have multiple extension tuples with
the same ISDN_FEATURE value, each describing a different variant of the same feature. Defined
ISDN_FEATURE values are:
TPLFE_TYPE: Values for ISDN Functions
Value Description
81H ISDN_TECH Technology type
3.2.6.4.1 ISDN_TECH Function Extension Tuple

Function extension tuples are the same as for a serial type ISDN card. See Table 3-21:
CISTPL_FUNCE: ISDN Function Extension Tuple.
Note The following fields on Table 3-21: CISTPL_FUNCE: ISDN Function

Extension Tuple are not used for a network adapter type ISDN card and all
fields should be set to zero:
TPLFE_UD, TPLFE_DC, TPLFE_CM, TPLFE_EX
3.2.6.5 Function Extension Tuple for Serial I/O Bus Adapter

The tuples defined here contain information about the operational features of Serial I/O Bus
Adapter. Serial I/O Bus Adapters are identified by a function ID of 0BH in TPLFID_FUNCTION
code and are further defined using function extension tuples to describe specific capabilities. The
general form of the Serial I/O Bus Adapter function extension tuple is:
Table 3-32: CISTPL_FUNCE: 1394 Serial I/O Bus Adapter Function Extension Tuple
Byte 7 6 5 4 3 2 1 0
1 TPL_LINK Link to next tuple (05)
2 TPLFE_TYPE 1394_TYPE (01H)
3 TPLFE_ADAPTER 1394 Host Adapter type
4 TPLFE_POWER Power management data
5..6 TPLFE_SPEED Bus speed, Max raw bit rate
TPLFE_SPEED is a 16 bit integer containing the raw bus Mb/second rate.
The TPLFE_ADAPTER field identifies the type of IEEE-1394 host adapter implemented in the PC
Card. This data is used by the host to select and load the appropriate driver.
The defined TPLFFE_ADAPTER codes are listed below

TPLFE_ADAPTER Values
Value Description
00 IEEE-1394/OHCI
01 IEEE-1394/Pele
02-FFH Reserved
The TPLFE_POWER field describes the bus power requirements of the IEEE-1394 device. The device
may either source or sink power. The POWER_CLASS values associated with each code can be
found in the IEEE 1394-1995 Specification in Section 4.3.4.1 (Self-ID packet).
TPLFE_POWER Values
Value Description
0-7 (bit 0-2) Power class code of 1394
(bit 3-7) Reserved (0)
Table 3-33: CISTPL_FUNCE: USB Serial I/O Bus Adapter Function Extension Tuple
Byte 7 6 5 4 3 2 1 0
1 TPL_LINK Link to next tuple (05)
2 TPLFE_TYPE USB_TYPE (02H)
3 TPLFE_ADAPTER USB Host Adapter type
4 TPLFE_POWER Power management data
5..6 TPLFE_SPEED Bus speed, Max raw bit rate
TPLFE_SPEED is a 16 bit integer containing the raw bus Mb/second rate.
The TPLFE_ADAPTER field identifies the type of USB host adapter implemented in the PC Card.
This data is used by the host to select and load the appropriate driver.
The defined TPLFFE_ADAPTER codes are listed below
TPLFE_ADAPTER Values
Value Description
00 USB/OHCI
01 USB/Universal
02-FFH Reserved
The TPLFE_POWER field describes the power source ability of the USB device. A Self Powered
device will neither require nor supply power on the USB bus. A Bus Powered device will draw itÕs
power from the USB bus within the constraints of the USB specification. Both of these power codes
are valid for USB functions only, not for a USB root or hub. A Low Power device can be a root
device or a hub. A Low Power device is capable of supplying only 100 mA of current per port. A
High Power device is either a root or hub capable of supplying up to 500 mA per port
The defined TPLFFE_POWER codes are listed below
TPLFE_POWER Values
Value Description
0 Self Powered
1 Bus Powered
2 USB low power source (100 mA)
3 USB high power source (500 mA)
4-FFH Reserved
3.2.7 CISTPL_FUNCID: Function Identification Tuple

The function identification tuple contains information about the functionality provided by a PC
Card. Information is also provided to enable system utilities to decide if the PC Card should be
configured during system initialization. If additional function specific information is available, one
or more function extension tuples follow this tuple.
Multiple Function 16-bit PC Cards primary CIS may include a CISTPL_FUNCID tuple in each
function-specific secondary CIS. The TPLFID_FUNCTION code of zero (0) for multi-function is only
used for 16-bit PC Cards with more than one function that do not follow this standard. In other
words, a TPLFID_FUNCTION code of zero (0) identifies a 16-bit PC Card that provides multiple
functions using a vendor specific implementation.
CardBus PC Cards have one to eight functions, each function is uniquely identified and contains a
separate CIS. Each CardBus PC Card function CIS shall contain a CISTPL_FUNCID tuple describing
that function.
Table 3-34 CISTPL_FUNCID: Function Identification Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_FUNCID (21H)
2 TPLFID_FUNCTION IC Card function code
3 TPLFID_SYSINIT System initialization bit mask
The TPLFID_FUNCTION field identifies the function provided by the PC Card.

As noted above, additional information about a specific function may be available in function
extension tuples. These extension tuples follow their related function identification tuple.
The defined TPLFID_FUNCTION codes are listed below.
TPLFID_FUNCTION field codes
Code Name Meaning
0 Multi-Function 16-bit PC Card using a vendor specific implementation with more than one
function and only one (1) set of configuration registers
1 Memory Memory Card (RAM, ROM, EPROM, flash, etc.)
2 Serial Port Serial I/O port, includes modem cards
3 Parallel Port Parallel printer port, may be bi-directional
4 Fixed Disk Fixed drive, may be silicon may be removable
5 Video Adapter Video interface, extension tuples identify type and resolutions
6 Network Adapter Network adapter
7 AIMS Auto Incrementing Mass Storage card
8 SCSI SCSI bridge
9 Security Security services, extension tuples identify type and capabilities.
AH Instrument Instrumentation Cards
BH Serial I/O Bus Adapter High speed Serial Bus Adapter (e.g. IEEE-1394, USB)
0CHááFDH Reserved Unused in this release. Reserved for future use
FEH Vendor-Specific Unique to specific vendor
FFH Do Not Use Invalid code.
The TPLFID_SYSINIT is a bit-mapped field. It allows PC Cards with standard system resources to
be installed during system initialization. The bit definitions are described in the following table: the
TPLFID_SYSINIT field.
TPLFID_SYSINIT field
7 6 5 4 3 2 1 0
RFU, must be zero (0). ROM POST
The POST bit indicates that the Power-On Self Test routines may attempt to configure the PC Card
during system initialization.
The ROM bit indicates the PC Card contains a system expansion ROM which may be installed
during system initialization. Information describing the ROM to be installed is in the TPCE_FS
Feature Selection Byte and related Memory Space Description Structure in a 16-bit PC Card
CISTPL_CFTABLE_ENTRY tuple or CardBus PC Card CISTPL_CFTABLE_ENTRY_CB tuple.
Only the specific function requiring POST or BOOT processing should have the appropriate bits set
in the System Initialization Byte.
3.2.8 CISTPL_JEDEC_C, CISTPL_JEDEC_A: The JEDEC Identifier

Tuples
This optional tuple is provided for cards containing programmable devices. It provides an array of k
entries, where k is the number of distinct entries in the device information tuple (codes 01H or 17H).
There is a one-to-one correspondence between JEDEC identifier entries in this tuple and device
information entries in the device information tuple.
Table 3-35 CISTPL_JEDEC_C and CISTPL_JEDEC _A: JEDEC Identifier Tuples

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_JEDEC_C (18H) and CISTPL_JEDEC _A (19H).
1 TPL_LINK Link to next tuple (at least m-1).
2áá3 JEDEC identifier for first device info entry.
4áá5 JEDEC identifier for second device info entry (if needed).
6áám JEDEC identifiers for remaining device info entries (if needed).
The TPL_CODE field indicates to which device information tuple(s) the JEDEC identifier tuple
corresponds. If the value is 18H. CISTPL_JEDEC_C, the tuple corresponds to the CISTPL_DEVICE or
CSTPL_DEVICE_OC tuples. CardBus PC Cards use CISTPL_JEDEC_C tuples to indicate JEDEC
identifiers which correspond to CISTPL_DEVICE_OC tuples. If the value is 19H, CISTPL_JEDEC_A,
the tuple corresponds to the CISTPL_DEVICE_A or CISTPL_DEVICE_OA tuples (16-bit PC Cards
only).
JEDEC identifiers consist of two bytes. The first byte is the device manufacturer ID, as assigned by
JEDEC committee JC-42.4. This byte, if valid, must always have an odd number of bits set true. The
MSB (bit 7) of the byte is used as a parity bit to ensure that this constraint is met. The values of 0
and FFH are illegal JEDEC identifiers (due to their even parity). The value 0H indicates Òno JEDEC
identifier for this device.Ó
The second byte contains manufacturer specific information representing device type, programming
algorithm, and the like. If the manufacturer ID is 00H, then this byte is reserved and should be set
to zero.
JEDEC identifiers will only be provided for device info entries that indicate some kind of
programmable device. For all other entries, the corresponding JEDEC identifier field shall be
absent, i.e., set to 00H .
Examples:
If a 16-bit PC Card consists of four ÒCompany XÓ 27C512 devices, whose JEDEC identifier is
(hypothetically) manufacturer: 40H, device ID: 15H, then the header block might be laid out as
follows:
/byte[0]: (CISTPL_DEVICE,
/byte[1]: /*link*/ 3,
/byte[2]: /*type/speed*/ DTYPE_OTPROM | DSPEED_250NS,
/byte[3]: /*size: units/code*/ (1<<3) | 4)
);
/byte[5]: (CISTPL_JEDEC_C, /*18H*/

/byte[6]: /*link*/ 0FFh, /*(end of chain)*/
/byte[7]: /*manufacturer ID*/ 40h,
/byte[8]: /*mfr's info*/ 15h,
);
Note: In the above example, the size byte indicates that 2 x 128K bytes are
available, for a total of 256K. Programming software would use the JEDEC
information to determine that in fact 4, 64K x 8 devices are present. Since
16-bit PC Cards are always 16 bits wide, programming software could
therefore deduce the organization of such a card.
The following tuples might be used to describe a card with 256K of OTPROM and 16 KBytes of
RAM. In this example, RAM occupies locations [0 - 03FFFH], and ROM occupies locations [20000H -
5FFFFH] (for ease of decoding).
/byte[0]: (CISTPL_DEVICE,
/byte[1]: /*link*/ 7,
/byte[2]: /*type/speed*/ DTYPE_SRAM | DSPEED_100NS,
/byte[3]: /*size: units/code*/ ((1<<3) | 2)
/byte[4]: /*type/speed*/ DTYPE_NULL | DSPEED_NONE,
/byte[5]: /*size: units/code*/ ((0Dh<<3) | 2)
/byte[6]: /*type/speed*/ DTYPE_OTPROM | DSPEED_250NS,
/byte[7]: /*size: units/code*/ ((1<<3) | 4)
);
/byte[9]: (CISTPL_JEDEC_C,
/byte[10]: /*link*/ 0FFh, /*(end of chain)*/
/byte[11]: /*RAM: no code*/ 0,
/byte[12]: /*no info*/ 0,
/byte[13]: /*hole: no code*/ 0,
/byte[14]: /*no info*/ 0,
/byte[15]: /*manufacturer ID*/ 40h,
/byte[16]: /*mfr's info*/ 15h,
);
3.2.9 CISTPL_MANFID: Manufacturer Identification Tuple

The manufacturer identification tuple contains information about the manufacturer of a PC Card.
Two types of information are provided: the PC Card's manufacturer and a manufacturer card
number. Only one manufacturer identification tuple may be present in the card information
structure.
Table 3-36 CISTPL_MANFID: Manufacturer Identification Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_MANFID (20H)
2áá3 TPLMID_MANF PC Card manufacturer code
4áá5 TPLMID_CARD manufacturer information (Part Number and/or Revision)
The TPLMID_MANF field identifies the PC Card's manufacturer. New codes are assigned by both
PCMCIA and JEIDA. The first 256 identifiers (0000 H through 00FFH) are reserved for manufacturers
who have JEDEC IDs assigned by JEDEC Publication 106. Manufacturers with JEDEC IDs may use
their eight bit JEDEC manufacturer code as the least significant eight bits of their PC Card
manufacturer code. In this case, the most significant eight bits must be zero (0). For example, if a
JEDEC manufacturer code is 89H, their PC Card manufacturer code is 0089H.
The TPLMID_CARD field is reserved for use by the PC Card's manufacturer. It is anticipated that
the field will be used to store card identifier and revision information.
3.2.10 CISTPL_VERS_1: The Level 1 Version / Product Information

Tuple
This tuple contains Level 1 version compliance and card manufacturer information. It applies to
Level 1 tuples only. It should appear only once in each partition descriptor chain.
Table 3-37 CISTPL_VERS_1: Level 1 Version / Product Information Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_VERS_1 (15H).
2 TPLLV1_MAJOR Major version number.
3 TPLLV1_MINOR Minor version number.
4 TPLLV1_INFO Product information string: name of the manufacturer, terminated by NULL (00H).
Name of product, terminated by NULL (00H).
Additional product information, in text; terminated by NULL (00H).
Suggested use: lot number.
Additional product information, in text; terminated by NULL (00H).
Suggested use: programming conditions.
m FFH: marks end of chain.
Indicates compliance with the following Standard TPLLV1_MAJOR TPLLV1_MINOR

PC Card Standard, February 1999 (Release 7.0) 7 (07H) 0 (00H)
PC Card Standard, April 1998 (Release 6.1) 6 (06H) 1 (01H)
PC Card Standard, March 1997 (Release 6.0) 6 (06H) 0 (00H)
PC Card Standard, May 1996 (Release 5.2) 5 (05H) 2 (02H)
PC Card Standard, November 1995 (Release 5.1) 5 (05H) 1 (01H)
PC Card Standard, February 1995 (Release 5.0) 5 (05H) 0 (00H)
PCMCIA 2.1 / JEIDA 4.2 4 (04H) 1 (01H)*
PCMCIA 2.0 / JEIDA 4.1 4 (04H) 1 (01H)
PCMCIA 1.0 / JEIDA 4.0 4 (04H) 0 (00H)
NOTE: TPLLV1_MINOR was intentionally set to 01H for PCMCIA

2.1/JEIDA 4.2.
3.3 Configuration Tuples

The Configuration and Configuration-Entry tuples describe the configurable characteristics of 16-bit
PC Card Memory Only and I/O cards as well as CardBus PC Cards. The card characteristics
described by these tuples include:
· Class of interface (Memory Only, I/O or other);
· Use of Wait, READY, Write Protect, BVDs, and Interrupts;
· Card configurations requiring currents in excess of the nominal levels;
· Configurations of VPP[2::1] or VCC;
· I/O port and memory mapping requirements;
· CardBus PC Card Base Address Register size and characteristics;
· Interrupt levels;
· Unique identification of identical cards.
The Configuration tuple contains a number of fields within it which describe the interface(s)
supported by the card, and, when present, the locations of the Card Configuration Registers and the
Card Configuration Table.
Specific card configurations and their variations are defined in the Configuration-Entry tuples which
make up the Card Configuration Table.
3.3.1 CISTPL_BAR: CardBus PC Card Base Address Register Tuple

The CardBus PC Card-bit Base Address Register tuple describes the size, characteristics and
capabilities of the space mapped by a Base Address Register or an Expansion ROM Base Address
Register.
Table 3-38 CISTPL_BAR: CardBus PC Card Base Address Register Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_BAR (07H)
2 TPLBAR_ATTR Base Address Register Indicator and Attributes
Below Prefetchable / Cacheable Address RFU Address Space Indicator
1 MB space (0)
3 Reserved, must be 0
4áá7 TPLBAR_SIZE Base Address Register Size
TPLBAR_ATTR field
Field Description
Address Space Same encoding as the Address Space Indicator field in the CISTPL_LONGLINK_CB tuple.
Indicator 0 illegal value - zero indicates CardBus PC Card configuration space.
1 Base Address Register 1.
7 the Expansion ROM Base Address Register.
Address space 0 Base Address Register is of type memory.
1 Base Address Register is of type I/O, Address Space Indicator allowed values 1áá5.
Prefetchable / When Address Space is set (1) this field is reserved and must be zero (0).
Cacheable When Address Space is reset (0):
0 neither prefetchable nor cacheable
1 prefetchable but not cacheable
2 both prefetchable and cacheable
3 Reserved value, do not use.
Below When Address Space is set (1) this field is reserved and must be zero (0).
1 MB When Address Space is reset (0):
0 no restriction on mapping location.
1 must locate in the first megabyte of system address space on x86 architecture
systems.
The TPLBAR_SIZE field indicates the size in bytes of the area mapped by the Base Address
Register or Expansion ROM Base Address Register identified by the Address Space Indicator field of
the TPLBAR_ATTR byte. All Base Address Register sizes are powers of two.
3.3.2 CISTPL_CFTABLE_ENTRY: 16-bit PC Card Configuration Table

Entry Tuple
The initial portion of each entry of the 16-bit PC Card Configuration Table is given in a compact,
standard form. Additional information may be added to the compact information by appending
tuple-formatted information (tuple-code, offset to next tuple, and tuple contents) within the interface
definition or configuration entry tuples containing the Configuration Table Entry. Subtuple codes
80HááBFH are reserved for vendor-specific configuration information.
The 16-bit PC Card Configuration Table organization for a Memory Only Card and an I/O Card are
the same. However, a Memory Only Card should not include I/O specific fields or tuples. Fields
related to VCC, VPP[2::1] and timing apply to all 16-bit PC Cards.
16-bit PC Card Configuration Table Entry tuples are used to specify each possible configuration of a
card and to distinguish among the permitted configurations. The Configuration tuple must precede
all Configuration Table Entry tuples. The Configuration Table Entry, whose Configuration Table
Index matches the last index in the Configuration tuple, must appear after all other Configuration
Table Entries.
When the default bit is set in the Configuration Table index byte, that Configuration Table Entry
provides default values for entries which follow in the Card Configuration Table.
When the default bit is not set in an entry's Configuration Table index byte, the entry provides
default values which apply only to the configuration indicated by the that entry's Configuration
Table Index (TPCE_INDX) byte.
Values which are not present in a specific entry are taken from the card's most recently scanned
default entry, as indicated in the specific fields below.
Table 3-39 CISTPL_CFTABLE_ENTRY: Configuration Table Entry Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_CFTABLE_ENTRY (1BH)
1 TPL_LINK Link to next tuple (n-1, [2 minimum])
2 TPCE_INDX Configuration Table Index Byte.
áá TPCE_IF Interface Description field. This field is present only when the Intface field of the Configuration
Table Index Byte is set.
áá TPCE_FS Feature Selection byte. This field indicates which optional fields are present.
áá TPCE_PD Power Description Structure.
áá TPCE_TD Configuration Timing Information field.
áá TPCE_IO I/O Space description field.
áá TPCE_IR Interrupt Request Description structure.
áá TPCE_MS Memory Space Description structure.
áá TPCE_MI Miscellaneous Features field.
áán TPCE_ST Additional information about the configuration in subtuple format.
3.3.2.1 TPCE_INDX: The Configuration Table Index Byte

The Configuration Table index byte contains the value to be written to the Card Configuration
Option Register in order to enable the configuration described in the tuple. In addition, this byte
contains a bit to indicate that the configuration defined in this tuple should be taken as the default
conditions for Configuration-Entry tuples that follow.
TPCE_INDX: Configuration Table Index Byte

7 6 5 4 3 2 1 0
Intface Default Configuration-Entry-Number
Field Description
Configuration- Contains the value to be written to the Card Configuration Register to enable the configuration
Entry-Number described in the tuple.
Default This bit indicates that this entry provides default values for succeeding entries until another entry
is encountered with its Default bit set.
1 The default conditions for following table entries are exactly those conditions specified
in this entry.
0 The default conditions are the conditions specified by the last entry encountered with its
default bit set.
Intface 0 No interface configuration byte is present following this byte.
When the default bit is set in this byte or no Configuration-Entry tuple has been scanned
with its default bit set then the standard, Memory Only Interface with READY, Write
Protect and Battery Voltage Detects are present at pins but not necessarily in a Pin
Replacement Register. WAIT# is not generated for memory cycles. (TPCE_IF value
of 70H)
Otherwise, the timing is specified by the most recently scanned Configuration-Entry
tuple with its default bit set.
1 An interface configuration byte follows this byte.
3.3.2.2 TPCE_IF: Interface Description Field

The Interface Description field indicates the particular card interface which the configuration uses.
The interface type (Memory Only or Memory and I/O) is specified. In addition, the card's
requirements for system support of the Battery Voltage Detect, Write Protect, READY and Wait
functions may be indicated.
TPCE_IF: Interface Description field
7 6 5 4 3 2 1 0
M Wait READY WP Active BVDs Active Interface Type
Required Active
Field Description
Interface Type 0 Memory
1 I/O and Memory
2 Reserved for future standardization
3 Reserved for future standardization
4 Custom Interface 0
8áá15 Reserved for future standardization
Interfaces 4 through 7 correspond to interfaces which are defined in CCSTPL_CIF subtuples in
the Configuration Tuple. The custom interface number is the relative position of the CCSTPL_CIF
subtuple used by this configuration in the set of CCSTPL_CIF subtuples within the Configuration
Tuple (CISTPL_CONFIG tuple, TPCC_SBTPL field) for this card.
BVDs Active BVD1 and BVD2 signals are active and should be recovered from the Pin Replacement Register
if not available on Pins 62 and 63.
WP Active Write Protect Status is active and should be recovered from the Pin Replacement Register if not
available on Pin 33.
READY Active READY Status Active and should be recovered from the Pin Replacement Register if not
available on Pin 16.
M Wait Required WAIT# Signal support required for Memory Cycles.
(This bit should not be set by I/O PC Cards that do not use Common Memory.)
The status bits BVDs Active, WP Active, READY Active, and M WAIT Required are TRUE when set
(1).
3.3.2.3 TPCE_FS: Feature Selection Byte

The feature selector byte indicates which compact descriptive fields are present within the table
entry. Those fields which are present are indicated by a 1 in the corresponding bit of the selector
byte. Within the entry, the fields are ordered in the order of the selector bits starting from bit 0
(LSB) to bit 7 (MSB).
TPCE_FS: Feature Selection Byte
7 6 5 4 3 2 1 0
Misc Mem Space IRQ IO Space Timing Power
Field Description
Power The power supply requirements and load characteristics for this configuration are indicated.
There may be 0, 1, 2 or 3 fields following representing VCC, VPP[2::1], or VPP1 and VPP2
(individually) in that order. The coding is as follows:
0 No power-description structures, use the default.
1 VCC power-description-structure only.
2 VCC and VPP[2::1] (VPP1 = VPP2) power-description-structures.
3 VCC, VPP1 and VPP2 power-description-structures.
Timing 0 When the default bit is set in this tuple, or no Configuration-Entry tuple has been
scanned with its default bit set, then no timing is specified. READY may indicate busy
indefinitely, WAIT# will be active from 0 to 12 microseconds.
Otherwise, the timing is specified by the most recently scanned Configuration-Entry
tuple with its default bit set.
1 A timing-description structure is present following the power-description structure.
IO Space 0 When the default bit is set in this tuple, or no Configuration-Entry tuple has been
scanned with its default bit set, then no I/O space is used.
Otherwise, the I/O space requirement is specified by the most recently scanned
Configuration-Entry tuple with its default bit set.
1 An I/O space description structure is present following the timing description structure.
IRQ 0 When the default bit is set in this tuple, or no Configuration-Entry tuple has been
scanned with its default bit set, then no Interrupt is used.
Otherwise, the Interrupt request requirement is specified by the most recently scanned
Configuration Entry tuple with its default bit set.
1 An Interrupt request description structure is present following the I/O space description
structure.
Mem Space Memory address space mapping requirements for this configuration. There may be 0, 2, 4 or N
bytes of information following the Interrupt Request Structure. The coding is as follows:
0 When the default bit is set in this tuple, or no Configuration-Entry tuple has been
scanned with its default bit set, then no configuration dependent, memory address
space is used.
Otherwise, the memory address space requirement is specified by the most recently
scanned Configuration-Entry tuple with its default bit set.
1 Single 2-byte length specified. CardÕs Base Address is zero (0) and any host address
may be mapped. The length is specified in 256-byte units.
2 Length (2 bytes) and Card Address (2 bytes) specified. Host address equals card
address. The length and card address are each 2-bytes long and represent the number
of 256- byte pages which are mapped, and the starting page, which is mapped,
respectively. The length field appears before the card address field.
3 A memory space descriptor byte followed by one or more window descriptors is
present.
Misc 0 When the default bit is set in this tuple, or no Configuration-Entry tuple has been
scanned with its default bit set, then the miscellaneous fields are interpreted to be all
zero.
Otherwise, the miscellaneous fields are specified by the most recently scanned
1 A miscellaneous fields structure is present following the memory space description
structure.
3.3.2.4 TPCE_PD: Power Description Structure

Each power description structure has the following format:
Parameter Selection Byte

First Parameter Definition
áá
Last Parameter Definition
Each bit in the parameter selection byte indicates whether or not the corresponding parameter is
described by parameter definitions which follow that byte. The parameter definitions are present for
each logic-1 bit in the parameter selection byte. Each byte in a parameter definition, except the last
byte, has a logic-1 in bit 7 of the byte. The parameter definitions are ordered corresponding to bits 0
through 7 of the parameter selection byte.
1) Parameter Selection Byte
Parameter Selection Byte in Power Description Structure
7 6 5 4 3 2 1 0
RFU (0) Pdwn I Peak I Avg I Static I Max V Min V Nom V
Field Description
Nom V Nominal operating supply voltage. In the absence of other information the nominal operating
voltage has a tolerance of ±5%.
Min V Minimum operating supply voltage.
Max V Maximum operating supply voltage.
Static I Continuous supply current required.
Avg I Maximum current required averaged over 1 second.
Peak I Maximum current required averaged over 10 milliseconds.
PDwn I Power-down supply current required.
RFU Reserved for future standardization.
2) Parameter Definitions
Parameter definitions consist of a first byte containing a mantissa and exponent as described
below. Additional bytes appearing after the first byte serve to modify the initial value as
described below. An arbitrary number of additional bytes may be defined with the last byte in
the list having a 0 in bit 7. The next parameter definition, or the next field of the I/O tuple, is in
the byte immediately following the last byte of the parameter definition.
Parameter Definition in Power Description Structure
7 6 5 4 3 2 1 0
EXT Mantissa Exponent
EXT Extension
Extension bytes may be continued indefinitely until the first byte which contains a 0 in bit 7, which is the
final byte.
The Exponent of the Current and Voltage Values are given below:
Exponent Current Voltage Scale

Scale
0 100 nA 10 mV
1 1 mA 100 mV
2 10 mA 1 mV
3 100 mA 10 mV
4 1 mA 100 mV
5 10 mA 1V
6 100 mA 10 V
7 1A 100 V
The mantissa of the value is given by the following table:
Mantissa Value
0 1
1 1.2
2 1.3
3 1.5
4 2
5 2.5
6 3
7 3.5
8 4
9 4.5
AH 5
BH 5.5
CH 6
DH 7
EH 8
FH 9
Field Description
EXT When EXT is set (1), an extension byte follows this byte. Extension bytes may be concatenated
indefinitely. The final extension byte contains a 0 in the EXT field.
Extension The Extension field is defined as follows:
0áá63H Binary value for next two decimal digits to the right of the current value. (Note that
this range is 0áá99 decimal).
64Háá7CH Reserved.
7DH No connection (i.e., high impedance) permitted during sleep or power-down only.
(Must be last extension byte).
7EH Zero value required (Must be only extension byte). The voltage values given as
nominal values are to be ignored.
7FH No connection (i.e., high impedance) is required (Must be only extension byte).
The voltage values given as nominal values are to be ignored.
Here is an example power descriptor of a card with the following characteristics:
Operates over a VCC range of 2.5 to 7 volts. Operating current is 1 mA standby (static), 30 mA
average operating current. When in power down mode, the card requires only 75 mA. It uses a
VPP[2::1] of 12 volts ±5% at 50 mA peak which need not be connected during sleep or power down.
Power Description Example
Byte Value D7 D6 D5 D4 D3 D2 D1 D0 Notes
x+0 02H 0 0 0 0 0 0 2 VCC & VPP[2::1] Feature Byte

+1 5EH 0 1 0 1 1 1 1 0 Parameter Selection Byte for
RFU Power No Peak I Avg I Static I Max V Min V No VCC
Down Nominal
V
+2 2DH 0 52.5 X 5 VCC Minimum Voltage
No EXT 1 Volt
+3 6DH 0 DH 5 VCC Maximum Voltage
No EXT 7X 1 Volt
+4 04H 0 0 4 VCC Static Current
No EXT 1É0 1 mA
+5 35H 0 6 5 VCC Average Current
No EXT 3.0 X 10 mA
+6 EAH 1 DH 2 VCC Power Down Current
EXT 7.0 X 10 mA
Next
+7 32H 0 32H VCC Power Down Current
No EXT +.50 (gives 7.50 x 10 mA) Extension Byte
+8 21H 0 0 1 0 0 0 0 1 VPP[2::1] Parameter
RFU No Pwr Peak I No Avg No Static No Max No Min Nominal Selection Byte, Nominal V
Down Specified I I V V and Peak I given
V
I
+9 8EH 1 1 6 Nominal VPP[2::1] is 12.0
EXT 1.2 X 10 Volts Volts ±5%
Next
+AH 7DH 0 7DH Extension byte indicates that
No EXT VPP[2::1] may be made no connect during power down and sleep modes No Connect is permitted on
VPP[2::1] during Sleep and
power Down
+BH 55H 0 AH 5 Peak VPP[2::1] current is 50
No EXT 5.0 X 10 mA mA.
3.3.2.5 TPCE_TD: Configuration Timing Information

Timing information for Wait, READY and Initialization Delay are given in scaled, extended device
speed code format. The first byte contains the scale factors and the other bytes contain the unscaled
factors in the extended device speed code format.
(See also 3.2.2.1.1 Device ID Fields.)
TPCE_TD: Configuration Timing Information field
7 6 5 4 3 2 1 0
Reserved Scale 7 READY Scale Wait Scale
The timing descriptions, when present, occur in the same order as the fields are listed below:
Field Description
WAIT Scale This field is the power of 10 scale factor to be applied to the MAX WAIT time in extended device
speed format which follows. The value 3 indicates that the WAIT# signal is not used and the MAX
WAIT Speed is not present following the timing byte.
READY Scale This field is the power of 10 scale factor to be applied to the MAX time in the Busy State for the
READY signal. A value of 7 indicates that READY is not used and no maximum time is present
following the timing scale factor byte.
Reserved This field is the power of 10 scale factor which is to be applied to a reserved time definition. A
Scale 7 value of 7 indicates that no initial or extended reserved speed bytes follow the READY extended
speed bytes.
3.3.2.6 TPCE_IO: I/O Space Addresses Required For This Configuration

The I/O Space description indicates that the card requires a portion of its I/O address space be
accessible within the host's I/O address space. The I/O Space entry consists of, at minimum, the I/O
Space Definition byte. If this byte has the Range bit set, a Range Descriptor byte follows the
Definition byte, which is then followed by a series of Range Description fields. Each Range
Description consists of either a Starting Address field, a Length field, or both. Multiple Range
Descriptions can be defined if the card has multiple I/O windows.
TPCE_IO: I/O Space Description
7 6 5 4 3 2 1 0
Range Bus 16/8 IOAddrLines
Field Description
Bus 16/8 Recommended values for Bus 16/8 are:
Value Card-Related Description Host Requirements
00B Reserved.
01B Card supports 8-bit I/O only. Host must be able to access I/O on card
using byte accesses only on D0 through
All registers are accessible only with byte
D7. When 16-bit access is requested, two
accesses on D0 through D7.
cycles must be generated with the even
byte first.
10B All registers accessible by 16-bit hosts Host must access 16-bit registers using
which generate byte accesses for byte 16-bit accesses, and access 8-bit
registers and 16-bit accesses for word registers using 8-bit accesses. IOIS16# is
registers. Eight-bit accesses to 16-bit used to determine whether an access is
registers are not supported. Byte to an 8- or 16-bit register.
accesses to odd-byte registers may take
place on either D0 through D7 or D8
through D15.
11B All registers are accessible by both 8-bit This mode supports either 16-bit or 8-bit
or 16-bit accesses. If bit IOIS8 in the Card accesses, but 8-bit hosts can specify
Configuration and Status Register is set, operation as in mode 01, above, by setting
the host only supports 8-bit access and the IOIS8 bit in the Card Configuration
operation is as described for Bus 16/8 = and Status Register to 1. If IOIS8 is
01. If IOIS8 is zero, all registers can be cleared to zero either 8-bit or 16-bit
accessed using either 8-bit or 16-bit access is supported to all registers.
accesses.
Field Description
Range 0 The I/O Space Definition byte is the only byte needed for this definition. The card will
respond to all enabled I/O accesses and uses IOAddrLines of address to distinguish
among its I/O ports. The host can select any 2N boundary (N = IOAddrLines) for the
card and generate enables for accesses at this host base address, with the amount of
space also equal to 2N.
1 The I/O Space definition byte is followed by an I/O Range Descriptor byte, and one or
more I/O Address Range Description fields.
IOAddrLines Total number of address lines that are used by the card to determine when the card is selected.
0 When IOAddrLines is zero, a range must also be specified, and the card will respond to
all addresses presented to the card. The host is entirely responsible for when the card
is selected, and at what addresses the card is selected. The host must assign to the
card a portion of the address space which is at least as large as the number of bytes
indicated in the length field of the following range entry. The Base Address for the I/O
space (assigned to the card by the host) must begin on a 2N address boundary such that
2N is greater than the number of bytes indicated in the length field.
1áá26 When IOAddrLines is non-zero, the card performs address decoding to determine
when it is selected. In this case, the card and the host share the determination of when
a card is actually selected. The card must indicate in IOAddrLines the highest address
line (plus 1) which it decodes to determine when it has been selected. The card will
determine which I/O addresses are actually selected within the I/O space that it
decodes.
The host and the card then share the task of determining when the card is selected. The
host uses information provided by IOAddrLines and any range descriptions to
determine if Card Enables should be generated during I/O cycles. The card then
determines if it should respond to an address that has been enabled by the card
enables. The card returns the Input-Acknowledge signal to the host whenever the card
can actually respond to an I/O address on the bus.
27áá31 Reserved. (Beyond the 64 Megabyte I/O space.)
Recommended values for IOAddrLines are:
0 Card responds to all I/O cycles when CE's are true, and specifies the desired address
ranges to enable. It is suitable for all architectures.
N Where the card has 2(N-1) < I/O ports £ 2N, and can be placed on any multiple of 2N
boundary. It is suitable for any architecture. For example, if a card has 32 eight-bit I/O
ports and the card decodes 5 address lines (A4ááA0), then N = 5, but the card can still
be placed on a 32-byte I/O boundary; it does not need to be placed on a 64 byte I/O
boundary.
10 A 1 Kilobyte I/O address space. This is software compatible for decoding in the top 768
bytes of each 1 KByte of I/O space. This is the same as is done in the ISA and EISA
PC's.
16 Full decoding of 64 Kilobytes of I/O space. This is not compatible with EISA or ISA bus
architectures.
I/O Range Descriptor Byte

7 6 5 4 3 2 1 0
Size of Length Size of Address Number of I/O Address Ranges (-1)
The I/O Range Descriptor byte is only provided if the Range bit in the I/O Space definition byte was
set to one. This byte determines how many I/O Address Range Description fields will follow and how
many bytes will be used to encode the Start of I/O Address Block and the Length of I/O Address Block
portion of each of the I/O Address Range Description fields that follow. Either the Start of I/O Address
Block or the Length of I/O Address Block, but not both portions of the descriptions can be eliminated
by encoding the respective size field as zero. Every I/O Address Range Description that follows must
have the same number of bytes as defined by the sum of the encoded sizes from the two size fields
in the I/O Range Descriptor byte.
Field Description
Number of I/O This field specifies how many I/O Address Range Description fields will follow the I/O Range
Address Ranges Descriptor byte. This value is encoded as one less than the number of descriptions. (A value of 0
indicates 1 I/O Address Range Description field, a value of 15 indicates 16 fields.)
Size of Address This field specifies how many bytes will be used to encode the Start of I/O Address block in each
of the I/O Range Description fields that follow.
0 address is not present in I/O Address Range Descriptions.
1 address is 1 byte long.
2 address is 2 bytes long.
3 address is 4 bytes long.
Size of Length This field specifies how many bytes will be used to encode the Length of I/O Address block in
each of the I/O Range Description fields that follow.
0 length is not present in I/O Address Range Descriptions.
1 length is 1 byte long.
2 length is 2 bytes long.
3 length is 4 bytes long.
The Size of Address and Size of Length fields may not both be zero (0).
I/O Address Range Description Field

Byte 7 6 5 4 3 2 1 0
n Start of I/O Address Block 0, 1, 2 or 4 bytes long as determined in the I/O Range Descriptor.
Implied address bits in bytes that are not provided are zeros.
n+(0áá4) Length of I/O Address Block (value is length -1)
0, 1, 2 or 4 bytes long as determined in I/O Range Descriptor.
When the Start of I/O Address Block field is not present, this indicates that the starting address of the
block is on an arbitrary 2 N boundary in the host space, where N is the number of address lines
defined by IOAddrLines.
3.3.2.6.1 I/O Space Encoding Guidelines

Many permutations of the three main I/O Space encoding parameters (IOAddrLines, Start Address,
and Length) are possible. These fields define the requirements of the card with respect to I/O
addresses. In all cases, the host and the card share the same address (no translation is performed),
the tuple merely defines when the card will be selected. The table below and associated text, is
intended to give a precise definition for all the possible combinations of these parameters. There are
two areas of explanation: when the host must generate Card Enables based on I/O address
decoding, and how the host allocates I/O addresses.
I/O Space Definition Fields

IOAddrLines Start Address Length Interpretation
* * 0 Invalid combination. Should not be used.
0 NP NP Invalid combination. Should not be used.
0 NP L Host must at least generate CE for a host selected I/O address range
of length L. Host sets the I/O range beginning on multiple of a power of
2 boundary. Host address selection range can be defined as follows
(host chooses x and y):
[y * 2x] áá [y * 2x + L -1], where 2x >= L and x should be

the smallest value that the host hardware will allow.
0 B NP Illegal combination.
0 B L Host must at least generate CE for the I/O address range specified by
Start and Length. Host allocates the specified I/O address range, i.e.,
the address range is: [B] áá [B + L - 1].
A NP NP Host must at least generate CE for a host selected I/O address range
of length 2A. Host selects the I/O address range beginning on a 2A
boundary of length 2A, i.e., the address range is (host chooses x): [x *
2A] áá [(x + 1) * 2A - 1]
A NP L Host must at least generate CE for a host selected I/O address range
of length L. Host selects the I/O address range beginning on a 2A
boundary of length L, i.e., the address range is (host chooses x): [x *
2A] áá [x * 2A + L - 1]
A B NP Host must at least generate CE for a host I/O address range of length
2A that includes B, i.e., the address range is (host determines x):
[ x * 2(A)] áá [(x + 1) * 2A - 1]
where: x * 2(A) <= B < (x + 1) * 2A

A B L Host must at least generate CE for an address range of length L that
includes base B, i.e., the address range is (host determines x):
[x * 2A] áá [x * 2A + L - 1]
where: x * 2(A) <= B < x * 2A + L

* any value that can be defined for the field
0 value is zero
NP field is not present
A a non zero value for IOAddrLines field
B the base value defined for Start Address field
L the value defined for Length field
x a value chosen by the host to define host address selections
y a value chosen by the host to define host address selections
When IOAddrLines <> 0, whether a base address is specified or not, the host can generate CE for
any combination of the upper (26 - IOAddrLines) address lines. If a base address is specified and
requires more address bits to represent than was specified by IOAddrLines, the full base address
indicates a desired I/O address range allocation which should be included in the decode by the
host. If a base address and IOAddrLines <> 0 are both specified, all recommended configurations
will have a base address value that is a multiple of 2(IOAddrLines).
When IOAddrLines <> 0 and Length L is specified, the host need not reserve any excess I/O address
space (2(IOAddrLines) - L bytes) for this PC Card. If L is not specified, the host must allocate all
2(IOAddrLines) bytes of address space to this PC Card.
In all cases, the host may allocate a larger address space than that indicated for a particular
configuration entry. The host may also allocate multiple (aliased) address ranges for a given PC
Card. If such aliased address ranges are allocated, a PC Card with IOAddrLines = 0 will respond to
all aliased ranges since it does not perform upper address line decoding. A PC Card with
IOAddrLines <> 0 will respond to other aliased ranges based on the number of decoded address
lines specified with IOAddrLines.
If multiple address ranges are specified in a configuration entry, the IOAddrLines value must span
the sum of all range lengths. For example, if an entry has a range with a length of 4 and a second
range of length 8, IOAddrLines must be at least 4 (4 bits of addressing are required to access all 12
bytes).
3.3.2.7 TPCE_IR: Interrupt Request Description Structure

When the IRQ bit is set, it indicates that an interrupt description follows the I/O address bytes, if
any. The interrupt request levels specified by the Configuration Table Entry Tuple describe the
preferred routing for the card's IREQ# line. Routing of the IREQ# interrupt is performed by the
host system which actually determines the system interrupt level used. A client which is the sole
consumer of the card's IREQ# interrupt may elect to route the IREQ# line to a level not specified by
the Configuration Table Entry Tuple. A generic card configuration utility which is not the ultimate
consumer of the card's IREQ# interrupt should only route to the specified interrupt levels. There are
either one or three interrupt description bytes as shown below:
TPCE_IR: Interrupt Request Description Structure
Byte 7 6 5 4 3 2 1 0
+0 Share Pulse Level Mask IRQN Line 0áá15
VEND BERR IOCK NMI
+1 * IRQ7 IRQ6 IRQ5 IRQ4 IRQ3 IRQ2 IRQ1 IRQ0
+2 * IRQ15 IRQ14 IRQ13 IRQ12 IRQ11 IRQ10 IRQ9 IRQ8
* These bytes present only when bit 4 of byte 0 is set (1). See Mask description below.
Field Description
Share The card contains interrupt sharing support logic in the Card Control and Status Register which
may be used to allow interrupt levels to be shared among several cards.
Pulse When this bit is one, the interrupt request pin in this mode may be pulsed low momentarily to
request an interrupt.
Level The Level Bit, when set, indicates that in this configuration the card's interrupt request pin can
remain asserted at the active low level until the interrupt is serviced. When a configuration is
capable of supporting level mode interrupts, the IRQLEV bit in the Configuration Register controls
whether the level or pulsed mode interrupts are selected.
Mask The Mask bit indicates whether the possible destinations of the interrupt request line are indicated
by a single interrupt line value, or a mask of possible interrupt lines.
When this bit is zero, the destination is given by the IRQN field, formed from right hand nibble of
byte 0, which selects 1 of 16 possible interrupt request lines. In this case, bytes 1 and 2 are not
present.
When this bit is a one, the 4 least significant bits of byte 0 are masks for possible interrupt
destinations. In addition, two additional bytes are present which contain mask bits for 16 possible
interrupt request lines.
NMI These bits are valid only when the Mask bit is 1. When set, each of these bits indicates that the
corresponding special interrupt signal may be assigned by the host to the card's interrupt-request
IOCK
pin. Systems are not required to support these interrupts.
BERR
NMI is non-maskable interrupt.
VEND IOCK is the I/O-check signal.
BERR is Bus-Error signal.
VEND is a Vendor-Specific signal.
IRQ0áá15 These bytes are present only when the Mask bit is a 1. When set, each of these bits indicates that
the corresponding interrupt signal may be assigned by the host to the card's interrupt request pin.
IOCK is the I/O check signal. General purpose systems must support all those interrupts which
are available on the I/O bus normally associated with the environment they are supporting.
3.3.2.8 TPCE_MS: Memory Space Description Structure

The Memory Space description indicates the card requires a configuration-entry related portion of its
Common Memory space be mapped into the host's address space. This memory may be either
direct mapped (no address translation is performed by the host), or may require that the host
translate the host address to the corresponding card address in order to support the card. In either
case, for the host to support the card under this configuration, the host must access the card when
the corresponding addresses are accessed by software.
TPCE_MS: Memory Space Descriptor Byte*
7 6 5 4 3 2 1 0
Host Addr Card Address Size Length Size Number of Windows
* This byte and the associated Window Descriptors are present only if the Mem Space field in the Feature
Selection byte is 3.
Field Description
Number of The number of window descriptors following minus 1.
Windows
Length Size The size of the length fields in bytes. The length is in 256-byte pages
Card Address The size of the card address fields in bytes. The card address is in 256-byte pages.
Size
Host Addr 0 No host address field is present and the host address is arbitrary.
1 A host address field, the same size as the card address field, is present.
Window Descriptor
Byte 7 6 5 4 3 2 1 0
+0áá3 Length The length of the window in units of 256 bytes. The least significant part appears in byte 0.
0áá3 bytes depending upon Length Size field above.
+0áá3 Card Address The address to be accessed on the card corresponding to the host address. The least significant
part appears in byte 0. 0áá3 bytes depending upon Card Address Size field above.
+0áá3 Host Address The physical address in the host-address space where the block of memory must be placed.
This field is present only when the Host Addr field is set (1). The least significant part appears in
byte 0. 0áá3 bytes depending upon Card Address Size field above.
3.3.2.9 TPCE_MI: Miscellaneous Features Field

When the Misc bit is set in the Feature Selection Byte, the Miscellaneous Features Field follows prior
Card Information Structure (CIS) fields. The Miscellaneous Features Field is one or more bytes. The
most significant bit of each byte in the field, except the last byte, is set to one (1). The most
significant bit of the last byte in the Miscellaneous Features Field is reset to zero (0).
If a configuration does not support any of the features described in the latter bytes of the
Miscellaneous Features Field, these bytes may be omitted and only the initial bytes shall be
present. In all cases, the most significant bit of the last byte present shall be reset to zero (0). For
example, if the configuration does not support DMA transfers, but the Pwr Down feature is
supported, only a single byte may be present with its most significant bit reset (0) and the Pwr
Down bit set to one (1).
The two bytes following the DMA specification contain the PC CardÕs thermal rating. The first byte
in bits 0 - 6 contain the XX part of a XX.YY thermal rating. The range of the PC CardÕs thermal
rating is 00.00 to 99.99. Bit 7 is always set to 1. The second byte in bits 0 - 6 is the YY part of the
XX.YY thermal rating. Bit 7 is used to extend the TPCE_MI field. See the Physical Specification
for more information on the PC Card thermal rating.
TPCE_MI: Miscellaneous Features Field

7 6 5 4 3 2 1 0
EXT RFU (0) Pwr Down Read Only Audio Max Twin Cards
EXT RFU (0) RFU (0) DMA Width DMA Request Signal RFU (0) RFU (0)
1 PC CardÕs Thermal Rating, XX of XX.YY value
EXT PC CardÕs Thermal Rating, YY of XX.YY value
Field Description
Max Twin Cards This field is used to indicate the card requires that identical cards installed in the system be
differentiated from each other in a sequential manner. For example, first twin is card 0, second is
card 1, and so on. This allows the cards to share I/O ports and interrupts in a manner consistent
with some peripherals commonly used in PC computers, such as fixed disk drives.
The Max Twin Cards field specifies the maximum number of other identical cards which can be
configured identically to this card. This permits more than one card to be installed in host which
responds to the identical I/O addresses. The host allows the cards to distinguish among
themselves by writing their ÒCopyÓ numbers ( e.g. 0, for the first card, 1 for the second, etc.) into
the copy field of the Socket and Copy Register in the Card Configuration Registers.
Audio This bit indicates the card allows the BVD2 signal to be used as Audio Waveform for the speaker.
This operation is controlled by the Audio Enable Bit in the Card Control and Status Configuration
Register.
Read Only This bit indicates the card contains a data storage medium which is read-only for this
configuration. There may be other configurations for which the storage medium is read/write.
Pwr Down This bit indicates the card supports a power-down mode controlled by the power-down bit in the
Control and Status Register.
RFU (0) These bits are reserved for future definition and must be 0.
EXT An extension follows this byte. A series of extension bytes is terminated when an extension byte is
encountered which does not have the EXT bit set to one (1).
DMA Request A binary value identifying the pin on the interface used to signal a DMA request.
Signal 0 DMA not supported by this configuration
1 DREQ# uses SPKR#
2 DREQ# uses IOIS16#
3 DREQ# uses INPACK#
DMA Width The DMA data transfer width.
0 the DMA data width is 8-bits.
1 the DMA data width is 16-bits.
Thermal Rating, Bits The XXh value of a PC CardÕs Thermal Rating. Valid range is 0 (00h) - 99 (63h). For
Major 0-6 consistency, bit 7, EXTension bit, is set (1).
Thermal Rating, Bits The YYh value of a PC CardÕs Thermal Rating. Valid range is 0 (00h) - 99 (63h). Bit
Minor 0-6 7, EXTension flag, is set according to future specification fields.
3.3.2.10 TPCE_ST: Additional information in subtuple format

The TPCE_ST field extends to the end of the tuple. It contains tuple-formatted information relating
to the configuration defined in this tuple.
3.3.2.10.1 STCE_EV: Environment Descriptor Subtuple

The environment-descriptor subtuple is an optional subtuple used to describe the environment in
which the configuration is used. It describes the system and, optionally, the operating system for
which the configuration is intended.
The subtuple contains one or more strings, the first of which contains 3 parts. The three parts are:
1. System Name
2. Operating System Name
3. Comment
The Operating System Name is preceded by a colon (:) and the comment is preceded by a
semicolon (;). The remaining strings contain comment (and, optionally, the system name and OS
name) in alternate languages. Each string is terminated by a 00H byte. The list of strings is
terminated by reaching the end of the subtuple. When the default bit is set in this configuration
entry tuple, the environment descriptor becomes the default environment descriptor for succeeding
entries as well.
STCE_EV: Environment Descriptor Subtuple
Byte 7 6 5 4 3 2 1 0
0 ST_CODE STCE_EV (C0H).
1 ST_LINK Link to next subtuple (at least m-1).
2áám STEV_STRS A list of strings, the first being ISO 646 IRV coded, and the rest being coded as ISO alternate
language strings, with the initial escape character suppressed. Each string is terminated by a 0
byte, and the last string, if it does not extend to the end of the subtuple, is followed by an FFH byte.
3.3.2.10.2 STCE_PD: Physical Device Name Subtuple

The physical device name subtuple is an optional subtuple used to describe the physical device
being implemented by the configuration.
The subtuple contains one or more strings, the first of which contains up to two parts. The first part
is the physical device name; the second part, preceded by a semicolon (;) is comment.
The remaining strings contain comment (and, optionally, the physical device name) in alternate
languages.
When the default bit is set in this configuration entry tuple, the environment descriptor becomes the
default environment descriptor for succeeding entries as well.
STCE_PD: Physical Device Name Subtuple
Byte 7 6 5 4 3 2 1 0
0 ST_CODE STCE_PD (C1H).
1 ST_LINK Link to next subtuple (at least m-1).
2áám STPD_STRS A list of strings, the first being ISO 646 IRV coded, and the rest being coded as ISO alternate
language strings, with the initial escape character suppressed. Each string is terminated by a 0
byte, and the last string, if it does not extend to the end of the subtuple, is followed by an FFH byte.
3.3.2.10.3 Additional I/O Feature Definitions within Entry

Additional information about the configuration may be embedded, at the end of, but within, a table
entry in the Card Configuration Table. The information takes the form of configuration-entry-
specific subtuples. These tuples begin at the byte following the last feature-description byte
indicated by the feature-selector byte. These additional tuples must be in standard tuple form (tuple
code, followed by offset to next tuple, followed by tuple info) and may not extend beyond the size
for the entry, indicated by the offset to the next table entry. The tuple-codes definitions used are
valid only within the interface definition tuple, or the configuration entry tuple.
3.3.3 CISTPL_CFTABLE_ENTRY_CB: CardBus PC Card

Configuration Table Entry Tuple
Configuration Table Entry tuples are used to specify each possible configuration of a card and to
distinguish among the permitted configurations. The Configuration tuple must be located before all
Configuration Table Entry tuples. The Configuration Table Entry, whose Configuration Table Index
matches the last index in the Configuration tuple, must appear after all other Configuration Table
Entries.
When the default bit is set in an entry's Configuration-Table index byte, that Configuration Table
Entry provides all default values for following entries in the Card Configuration Table.
While the default bit is not set in an entry's Configuration-Table index byte, the entry provides
default values which apply only to the configuration indicated by the that entry's Configuration-
Table Index (TPCE_INDX) byte.
Values which are not present in a specific entry are taken from the card's most recently scanned
default entry, as indicated in the specific fields below.
Table 3-40 CISTPL_CFTABLE_ENTRY_CB: CardBus PC Card Configuration Table Entry Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_CFTABLE_ENTRY_CB (05H)
1 TPL_LINK Link to next tuple (n-1, 2 minimum)
2 TPCE_INDX Configuration Table Index Byte.
3 TPCE_CBFS Feature Selection byte, This field indicates which optional fields are present.
áá TPCE_PD Power Description Structure. (See 3.3.2.4 TPCE_PD: Power Description Structure.)
áá TPCE_CBIO I/O Base Address Registers Used.
áá TPCE_IR Interrupt Request Description structure.
áá TPCE_CBMS Memory Base Address Registers Used.
áá TPCE_CBMI CardBus PC Card Miscellaneous Features field.
áán TPCE_ST Additional information about the configuration in subtuple format.
3.3.3.1 TPCE_INDX: The Configuration Table Index Byte

The Configuration-Table index byte, TPCE_INDX, contains a bit to indicate that the configuration
defined in this tuple should be taken as the default conditions for Configuration-Entry tuples that
follow. The TPCE_INDX field is also used to identify the last CISTPL_CONFIG_ENTRY_CB in the
CIS chain when the value matches the value in the TPCC_LAST field of the CISTPL_CONFIG_CB
tuple.
TPCE_INDX: Configuration Index Byte
7 6 5 4 3 2 1 0
RFU (0) Default Configuration-Entry-Number
Field Description
Configuration- Contains the value to be written to the Card Configuration Register to enable the configuration
Entry-Number described in the tuple.
Default This bit indicates that this entry provides default values for succeeding entries until another entry
is encountered with its Default bit set.
1 The default conditions for following table entries are exactly those conditions specified
in this entry.
0 The default conditions are the conditions specified by the last entry encountered with its
default bit set.
3.3.3.2 TPCE_CBFS: Feature Selection Byte

The feature-selector byte indicates which compact descriptive fields are present within the table
entry. Those fields which are present are indicated by a 1 in the corresponding bit of the selector
byte. Within the entry, the fields are ordered in the order of the selector bits starting from bit 0
(LSB) to bit 7 (MSB).
TPCE_FS: Feature Selection Byte
7 6 5 4 3 2 1 0
Misc RFU (0) Mem Space IRQ IO Space RFU (0) Power
Field Description
Power The power supply requirements and load characteristics for this configuration are indicated.
There may be 0, 1, 2 or 3 fields following representing VCC, VPP[2::1], or VPP1 and VPP2
(individually) in that order. The coding is as follows:
0 No power-description structures, use the default.
1 VCC power-description-structure only.
2 VCC and VPP[2::1] (VPP1 = VPP2) power-description-structures.
3 VCC, VPP1 and VPP2 power-description-structures.
IO Space 0 When the default bit is set in this tuple, or no Configuration-Entry tuple has been
scanned with its default bit set, then no I/O space is used.
Otherwise, the I/O space requirement is specified by the most recently scanned
1 An I/O space description structure is present.
IRQ 0 When the default bit is set in this tuple, or no Configuration-Entry tuple has been
scanned with its default bit set, then no Interrupt is used.
Otherwise, the Interrupt request requirement is specified by the most recently scanned
Configuration Entry tuple with its default bit set.
1 An Interrupt request description structure is present.
Mem 0 When the default bit is set in this tuple, or no Configuration-Entry tuple has been
Space scanned with its default bit set, then no memory space(s) are used.
Otherwise, the memory space requirement(s) are specified by the most recently
scanned Configuration-Entry tuple with its default bit set.
1 A memory space description structure is present.
Misc 0 When the default bit is set in this tuple, or no Configuration-Entry tuple has been
scanned with its default bit set, then the miscellaneous fields are interpreted to be all
zero.
Otherwise, the miscellaneous fields are specified by the most recently scanned
1 A miscellaneous fields structure is present.
3.3.3.3 TPCE_PD: Power Description Structure

The CardBus PC Card Power Description structure, TPCE_PD is identical to the 16-bit PC Card
structure used in the CISTPL_CFTABLE_ENTRY tuple. (See 3.3.2.4 TPCE_PD: Power Description
Structure.)
Note: CardBus PC Cards allow three VCC operational voltage settings: 3.3 volts
and reserved values X.X volts and Y.Y volts. The 5 volt VCC setting is
illegal for CardBus PC Cards.
3.3.3.4 TPCE_CBIO: I/O Base Address Registers Used

This field indicates the Base Address Registers which are used for I/O in this configuration. The
potential values are limited to the range one through five by the requirement that all CardBus PC
Card I/O space(s) be configurable as memory mapped I/O. The associated registers must be
provided in order, with the I/O Base Address Register (or Registers) immediately preceding the
memory Base Address Register, to avoid inadvertent double mapping, i.e., there may be a
memory Base Address Register following each I/O Base Address Register to map the I/O space, or
a contiguous set of I/O Base Address Registers may be followed by a single memory Base Address
Register which maps all of the I/O spaces described by the set.
TPCE_CBIO: Base Address Registers Used For I/O In This Configuration
7 6 5 4 3 2 1 0
RFU RFU IO_BAR_Used ( set = true ) RFU
The IO_BAR_Used field is a bit-mapped representation of the I/O Base Address Registers required
by a configuration. For example, if bits one and two are set, Base Address Registers one and two
map I/O space used in the configuration.
3.3.3.5 TPCE_IR: Interrupt Request Description Structure

The CardBus PC Card Interrupt Request Description structure, TPCE_IR is identical to the 16-bit PC
Card structure used in the CISTPL_CFTABLE_ENTRY tuple. (See 3.3.2.7 TPCE_IR: Interrupt
Request Description Structure.)
Note: All CardBus PC Cards generate level mode interrupts whenever interrupts
are selected. Level shall be set (1) and Pulse shall be reset (0) for all CardBus
PC Cards.
3.3.3.6 TPCE_CBMS: Memory Base Address Registers Used

This field indicates the Base Address Registers which are used for memory space in this
configuration. The potential values are limited to the range one through seven by the encoding of
configuration space accesses as zero (0). Note that the Expansion ROM Base Address Register is
listed with all other memory space accesses when it is used in the configuration.
TPCE_CBMS: Base Address Registers Used For Memory In This Configuration
7 6 5 4 3 2 1 0
MEM_BAR_Used ( set = true ) RFU
The MEM_BAR_Used field is a bit-mapped representation of the memory Base Address Registers
required by a configuration. For example, if bits one and two are set, Base Address Registers one
and two map memory space used in the configuration.
3.3.3.7 TPCE_CBMI: CardBus PC Card Miscellaneous Features Field

The CardBus PC Card Miscellaneous Features Field is one or more bytes. The most significant bit of
each byte in the field, except the last byte, is set to one (1). The most significant bit of the last byte
in the TPCE_CBMI field is reset to zero (0).
If a configuration does not support any of the features described in the last bytes of the
Miscellaneous Features Field, these bytes may be omitted and only the initial bytes shall be
present. In all cases, the most significant bit of the last byte present shall be reset to zero (0).
A number of the fields defined in the TPCE_CBMI field are used to give information on how the
Command register fields should be set. With the exception of the Fast Back-to-Back field, each
Command register field should have the same values as the corresponding feature indicator in this
tuple field. For example, if the Parity Error Response field is set here, then the Parity Error Response
field should be set in the Command register as well. (See also the Electrical Specification.)
The two bytes following the RFU feature bits contain the PC CardÕs thermal rating. The first byte in
bits 0 - 6 contain the XX part of a XX.YY thermal rating. The range of the PC CardÕs thermal rating
is 00.00 to 99.99. Bit 7 is always set to 1. The second byte in bits 0 - 6 is the YY part of the XX.YY
thermal rating. Bit 7 is used to extend the TPCE_MI field. See the Physical Specification for more
information on the PC Card thermal rating.
TPCE_CBMI: Miscellaneous Features Field
7 6 5 4 3 2 1 0
EXT Fast Back-to- SERR# Wait Cycle Parity Error VGA Palette Memory Bus Master
(must be 1) Back Enable Control Response Snoop Write &
Invalidate
EXT RFU (0) RFU (0) RFU (0) RFU (0) Wakeup Binary Audio PWM Audio
Event Enable Enable
Support
1 PC CardÕs Thermal Rating, XX of XX.YY value
EXT PC CardÕs Thermal Rating, YY of XX.YY value
Field Description
RFU (0) These bits are reserved for future (or historical) definition and must be 0.
EXT If set (1), another byte follows this byte. A series of extension bytes is terminated when an
extension byte is encountered which has the EXT bit reset to zero (0).
Bus Master (See the Electrical Specification.)
Memory Write & (See the Electrical Specification.)
Invalidate
VGA Palette (See the Electrical Specification.)
Snoop
Parity Error (See the Electrical Specification.)
Response
Wait Cycle (See the Electrical Specification.)
Control
SERR# Enable (See the Electrical Specification.)
Fast Back-to- This bit field does not control the corresponding value in the Command register. Rather, this is the
Back value which should be placed in the Status register indicating if this particular function, when
acting as a target, is Fast Back-to-Back capable
PWM Audio This field is used to indicate that the card can supply audio data in a Pulse Width Modulation
Enable encoded format.
Binary Audio This field is used to indicate that the card can supply audio data in a binary wave format.
Enable
Wakeup Event This read only field is used to indicate that the card supports (can provide) wakeup events. If the
Support field is set (1), then the card supports wakeup events. If the field is reset (0), then the card does
not support wakeup events.
Thermal Rating, Bits 0-6 hold the XXH value of a PC CardÕs Thermal Rating. Valid range is 0 (00H) - 99 (63H).
Major For consistency, bit 7, EXTension bit, is set (1).
Thermal Rating, Bits 0-6 hold the YYh value of a PC CardÕs Thermal Rating. Valid range is 0 (00H) - 99 (63H). Bit
Minor 7, EXTension flag, is set according to future specification fields.
3.3.3.8 TPCE_ST: Additional information in subtuple format

The TPCE_ST field extends to the end of the tuple. It contains tuple-formatted information relating
to the configuration defined in this tuple. The CardBus PC Card definitions for this field are
identical to the 16-bit PC Card structures used in the CISTPL_CFTABLE_ENTRY tuple. (See 3.3.2.10
TPCE_ST: Additional information in subtuple format.)

3.3.4 CISTPL_CONFIG: 16-bit PC Card Configuration Tuple

The Configuration tuple is used to describe the general characteristics of 16-bit PC Cards which can
be configured for operation. This includes cards containing I/O devices or using custom interfaces. It
may also describe PC Cards, including Memory Only cards, which exceed nominal power supply
specifications, or which need descriptions of their power requirements or other information.
The default interface, in the absence of a Configuration tuple, is a Memory Only interface.
There may be no more than one Configuration tuple in the CIS.
There are two types of 16-bit PC Card defined host interfaces:
· Those supporting Memory Card Only interface and,
· Those supporting both the Memory and the I/O Card interfaces.
In addition, custom interfaces are also permitted which can be recognized and enabled in a
standardized manner.
The card indicates which type(s) of custom interface(s) it can support in Custom Interface subtuples
of the Configuration Tuple. The interpretation of the rest of the bytes of the configuration tuple is
determined by the size-of-fields byte, TPCC_SZ, and consist of two Configuration Register
Descriptors, TPCC_RASZ and TPCC_RMSZ, and a Reserved Size field, TPCC_RFSZ.
The Card Configuration Table allows the system to determine the characteristics of the card for each
allowable configuration. The system may then configure the card into any allowable configuration,
or leave the card unconfigured. It may use the configuration to gracefully reject the card if the card
is found to be incompatible with the system hardware and software.
Table 3-41 CISTPL_CONFIG : 16-bit PC Card Configuration Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_CONFIG (1AH)
1 TPL_LINK Link to next tuple (n-1; minimum 5)
2 TPCC_SZ Size of Fields Byte
TPCC_RFSZ TPCC_RMSZ TPCC_RASZ
(Reserved Size, (Size of TPCC_RMSK field) (Size of TPCC_RADR)
must be 0)
3 TPCC_LAST Index Number of the last entry in the Card Configuration Table.
RFU (0) Last Index
4áá TPCC_RADR Configuration Registers Base Address in Attribute Memory Space. 1, 2, 3 or 4 bytes depending
upon the TPCC_RASZ field in TPCC_SZ.
áá TPCC_RMSK Configuration Registers Present Mask. 1 to 16 bytes as indicated by the TPCC_RMSZ field in
TPCC_SZ.
m TPCC_RSVD Reserved area 0áá3 bytes. Must be 0 bytes until defined.
máán TPCC_SBTPL The rest of the tuple is reserved for subtuples containing standardized optional additional
information related to the Card Configuration.

3.3.4.1 TPCC_SZ: Size of Fields Byte

TPCC_SZ: Size of Fields Byte
7 6 5 4 3 2 1 0
TPCC_RFSZ TPCC_RMSZ TPCC_RASZ
(Reserved Size) (Size of TPCC_RMSK field) (Size of TPCC_RADR)
Field Description
TPCC_RASZ The number of bytes in the Configuration Registers Base Address in Attribute Memory Space
field (TPCC_RADR) of this tuple is the value of this field plus 1.
TPCC_RMSZ The number of bytes in the Configuration Register presence mask field (TPCC_RMSK field) of
the tuple is this value plus 1.
TPCC_RFSZ Size of area presently reserved for future use 0, 1, 2 or 3 bytes. Must be 0 at present.
3.3.4.2 TPCC_LAST: Card Configuration Table Last Entry Index

The Card-Configuration-Table size is a one byte field which contains the Configuration Index
Number of the last configuration described in the Card Configuration Table. Once the host
encounters this configuration, when scanning for valid configurations, it will have processed all
valid configurations.
TPCC_LAST: Card Configuration and Last Entry Index
7 6 5 4 3 2 1 0
RFU 0 Last Index
Field Description
Last Index The Index Number of the final entry in the Card Configuration Table (the last entry encountered
when scanning the CIS).
RFU 0 This area is reserved for future standardization and must be 0.
3.3.4.3 TPCC_RADR: Configuration Registers Base Address in Attribute Space

TPCC_RADR: Configuration Registers Base Address in Attribute Space
7 6 5 4 3 2 1 0
Base Address Bits 7áá0
(always present)
(present if TPCC_RASZ is ³ 1)
(present if TPCC_RASZ is ³ 2)
(present if TPCC_RASZ is = 3)
The Base Address of the Configuration Registers, in an even byte of Attribute Memory (address of
Configuration Register 0), is given in this field. The system uses this information together with the
information in the Configuration Register's presence mask field to determine which registers are
present on the card and where they are located in the card's Attribute Memory space.

The Base Address is a field which may be from 1 to 4 bytes long depending upon the number of
bits needed to represent it. High order address bits, not present in the field, are always interpreted
to be zeros. The size of this field in bytes is one greater than the value of the TPCC_RASZ size field
in the TPCC_SZ byte.
It is recommended, but not required, that the Configuration Register's Base Address be placed near
the beginning of the Attribute Memory space.
3.3.4.4 TPCC_RMSK: Configuration Register Presence Mask Field for Interface

Tuple
TPCC_RMSK: Configuration Register Presence Mask Field for Interface Tuple
7 6 5 4 3 2 1 0
Configuration Register Presence Mask for Registers 7 to 0
(this byte is always present)
Configuration Register Presence Mask for Registers 15 to 8
this byte is present only if TPCC_RMSZ ³ 1)
Etc.
The presence mask for the Configuration Registers is given in this field. Each bit represents the
presence (1) or absence (0) of the corresponding Configuration Register. The least significant bit
represents the lowest Configuration Register represented by the byte, and the represented registers
increase with higher bit significance. Those registers which would be indicated by bytes extending
beyond the end of the field are not implemented on the card.
The system uses this information together with the information in the Configuration Registers Base
Address field to determine which registers are present on the card, and where they are located in
the card's Attribute Memory space.
The address of each configuration register is given by the formula:
Base Address + (Register Number * 2)
regardless of whether or not the register is present.
3.3.4.5 TPCC_SBTPL: Configuration tuple Sub-tuples

The TPCC_SBTPL field extends to the end of the tuple. It contains tuple formatted information
relating to the card's configuration. These tuples are subtuples of the CISTPL_CONFIG tuple and
cannot extend beyond the end of the configuration tuple. The chain of subtuples is ended by
reaching an FFH subtuple, or reaching the end of the CISTPL_CONFIG tuple. Any subtuple is
invalid if it contains a link field which links beyond the first byte of the tuple following the
CISTPL_CONFIG tuple. The tuple codes of the subtuples have meaning only within the
CISTPL_CONFIG tuple. Subtuple codes from 80H through BFH are vendor specific whereas the rest
are reserved for standard definition. The only subtuples presently defined are the list terminating
subtuple, FFH (a 1-byte-long subtuple), and the CCSTPL_CIF, custom interface subtuple.
3.3.4.5.1 CCSTPL_CIF: Custom Interface Subtuples

The custom interface subtuple provides a code which uniquely identifies a card supported interface.
These interfaces are referenced in the configuration entry tuples (CISTPL_CFTABLE_ENTRY,
TPCE_IF field) by their relative positions in the CISTPL_CONFIG tuple. A 1 to 4 byte, unique,
Interface Number may be followed by series of strings which describe the interface.

A maximum of four custom interface subtuples may be present in the configuration tuple
(CISTPL_CONFIG).
There are two classes of custom interfaces. The first class of custom interfaces are those jointly
defined by PCMCIA and JEIDA. These interfaces have a published electrical interface which is
documented in Appendix C in the Electrical Specification. The second class of custom interfaces are
those which have an assigned custom vendor interface code but no published interface definition
within the PC Card Standard.
The first-byte codes Ñ 41H, 81H and C1H in the field STCI_IFNÑ define two (XX41H), three
(XXXX81H) and four (XXXXXXC1H) byte numbers for custom interfaces which are jointly defined
by PCMCIA and JEIDA. The custom interface codes defined by PCMCIA/JEIDA are provided in the
following table:
STCI_IFN STCI_IFN_1 STCI_IFN_2 STCI_IFN_3 CIF Name
Code Code Code Code
41H 00H N/A N/A Reserved
41H 01H N/A N/A Zoomed Video
41H 02H N/A N/A Digital Video Broadcasting
41H 03-FFH N/A N/A Reserved for future use.
81H 00-FFH 00-FFH N/A Reserved for future use.
C1H 00-FFH 00-FFH 00-FFH Reserved for future use.
Vendors that wish to define proprietary custom interfaces may do so by requesting a custom vendor
interface code assignment. To simplify initial assignments, manufacturers who possess a JEDEC
programmable semiconductor manufacturer's ID may use first-byte codes 42h, 82h and C2h
followed by a second byte, which is their JEDEC ID, to generate interface ID numbers. For example,
with yy indicating values selected by the manufacturer and jj indicating their JEDIC ID, the
interface ID numbers jj42h, yyjj82h, and yyyyjjC2h are appropriate. Currently, no custom vendor
interface codes have been assigned.
The subtuple is defined as follows:
CCSTPL_CIF: Custom Interface Subtuples
Byte 7 6 5 4 3 2 1 0
0 ST_CODE CCSTPL_CIF (C0H)
1 ST_LINK Link to next tuple (n; minimum 1)
2 STCI_IFN Interface ID Number LSB - 1 to 4 bytes least significant byte first
This field provides a unique 8- to 32- bit number which identifies the interface. Within the ID
number are two bits (bits 6 and 7 of byte 0) which give the size of this field. The first two or three
bytes of the ID number is assigned by PCMCIA, JEIDA or its designer. When a vendor has been
assigned a two or three byte initial portion the remaining one or two bytes of the field are
assigned by that vendor to uniquely identify the interface.
STCI_IFN_SIZE STCI_IFN_BASE
3 STCI_IFN_1 2nd Interface ID Number byte, exists if STCI_IFN_SIZE is 1, 2 or 3.
4 STCI_IFN_2 3rd Interface ID Number byte, exists if STCI_IFN_SIZE is 2 or 3.
5 STCI_IFN_3 4th Interface ID Number byte, exists if STCI_IFN_SIZE is 3.
m STCI_STR Interface Description Strings
A list of strings, the first being ISO 646 IRV coded and the rest being coded as ISO alternate language strings with the
initial escape character suppressed. Each string is terminated by a 0 byte and the last string, if it does not extend to the
end of the subtuple, is followed by an FFH byte.

3.3.5 CISTPL_CONFIG_CB: CardBus PC Card Configuration Tuple

CISTPL_CONFIG_CB and CISTPL_CONFIG are extremely similar, although CISTPL_CONFIG_CB
has only one variable size field: TPCC_SBTPL, the configuration sub-tuple, compared to three
variable fields in CISTPL_CONFIG. CISTPL_CONFIG_CB gives the location of the CardBus PC Card
status registers for the associated function in place of the configuration registers for a 16-bit PC Card
identified by CISTPL_CONFIG.
CISTPL_CONFIG_CB indicates via Configuration sub-tuple(s) which type(s) of custom interface(s), if
any, are supported by the CardBus PC Card.
The Card Configuration Table allows the system to determine the characteristics of the card for each
allowable configuration. The system may then configure the card into any allowable configuration,
or leave the card unconfigured. It may use the configuration to gracefully reject the card if the card
is found to be incompatible with the system hardware and software.
Table 3-42 CISTPL_CONFIG_CB: CardBus PC Card Configuration Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_CONFIG_CB (04H)
1 TPL_LINK Link to next tuple (n-1; minimum 6)
2 TPCC_SZ Size of fields (must be 03H).
3 TPCC_LAST Index Number of the last entry in the Card Configuration Table.
4áá7 TPCC_ADDR Pointer to CardBus PC Card status registers.
8 TPCC_RSVD Reserved area 0áá3 bytes. Must be 0 bytes.
8áán TPCC_SBTPL The rest of the tuple is reserved for subtuples containing standardized optional additional
information related to the Card Configuration.
3.3.5.1 TPCC_SZ: Size of Fields Byte

TPCC_SZ: Size of Fields Byte
7 6 5 4 3 2 1 0
TPCC_RFSZ (Reserved Reserved, must be 0. Must be 3 (All TPCC_ADDR
Size, must be 0). status registers are 4 bytes).
3.3.5.2 TPCC_LAST: Card Configuration Table Last Entry Index

The Card-Configuration-Table size is a one-byte field which contains the Configuration Index
Number of the last configuration described in the Card Configuration Table. Once the host
encounters this configuration, when scanning for valid configurations, it will have processed all
valid configurations.
TPCC_LAST: Card Configuration and Last Entry Index
7 6 5 4 3 2 1 0
RFU 0 Last Index

Field Description
Last Index The Index Number of the final entry in the Card Configuration Table (the last entry encountered
when scanning the CIS).
RFU 0 This area is reserved for future standardization and must be 0.
3.3.5.3 TPCC_ADDR: CardBus PC Card Status Register Pointer

The encoding of this address is the same as for the TPLL_ADDR field in the
CISTPL_LONGLINK_CB tuple and the CIS Pointer, with the additional restriction that CardBus PC
Card status registers can only be placed in one of the memory spaces. The applicable values of the
Address Space Indicator and the Address Space Offset fields are given below.
When the status registers are not implemented, the Address Space Indicator must be set to zero(0).
TPCC_ADDR: CardBus PC Card Status Register Pointer Layout
DWORD 31 É 4 3 2 1 0
Address Space Offset Address Space Indicator
Memory offset within Base Address Register memory space replace with 0s
Space
Field Description
Address Space Value Meaning
Indicator 0 The status registers are not implemented.
1áá6 The status registers are in the memory address space governed by one of the six
Base Address Registers. For example, if the value is 2, then the status registers
are in the memory address space governed by Base Address Register 2.
7 Reserved.
Address Space Address Space Indicator Space Type Address Space Offset Values
Offset 0 Reserved. If Address Space Indicator is set to 0, this
field must be set to 0.
x; 1 £ x £ 6 memory space 0 £ value £ FFFFFFF8H. This is the offset
into the memory address space governed
by Base Address Register x. Adding this
value to the value in the Base Address
Register gives the location of the start of the
status registers.
7 Reserved. Undefined.
3.3.5.4 TPCC_SBTPL: Additional Information Stored in Tuple Format

The TPCC_SBTPL field in the CISTPL_CONFIG_CB tuple does not have any sub-tuples defined.
3.3.6 CISTPL_PWR_MGMNT: Function State Save/Restore Definition

The function state save/restore definition tuple identifies the method of PC Card function state
preservation supported by the function. When the PC Card function does not store state information
on the card the tuple describes the size and location of a buffer through which the PC Card function
state is retrieved when state is saved and returned to the card when state is later restored.
The CIS for a PC Card function shall contain at most one CISTPL_PWR_MGMNT tuple. Multiple
Function PC Cards shall never place a CISTPL_PWR_MGMNT tuple in the PC CardÕs global CIS.

Instead, Multiple Function PC Cards shall place a CISTPL_PWR_MGMNT tuple in the function-
specific CIS of each function that indicates the Power Management Support Register is present in the
functionÕs Configuration Register array.
Table 3-43 CISTPL_PWR_MGMNT: Function State Save/Restore Definition

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_PWR_MGMNT (08H)
1 TPL_LINK Link to next tuple (at least 6 when PWR_METHOD = 80H, at least 14 in all other cases)
2 PWR_METHOD type of support provided by the PC Card for saving/restoring card state
00H = PC Card state is saved/restored through buffer in Attribute space
01H = PC Card state is saved/restored through buffer in Common space
02Háá7FH = Reserved for future use.
80H = PC Card state is saved in non-volatile storage on the PC Card
81HááFFH = Reserved for future use.
3 PWR_TIME Save/Restore time
4áá7 PWR_REG_ADDR Offset of Power Management Support Register in Attribute Space
8áá11 PWR_OFFSET Offset of save/restore buffer
12áá15 PWR_BUFFSIZE Size in bytes of save/restore buffer
The PWR_METHOD field identifies the type of support provided by the PC Card function for
saving and restoring the state of the function. Two methods of state save/restore support are
defined. When the PWR_METHOD field is 80H, the PC Card function uses storage on the card when
saving and restoring the state of the function. When the PWR_METHOD field is 00H or 01H, the PC
Card transfers the state of the function through a buffer and relies on storage in the host when
saving and restoring the state of the function.
The PWR_TIME field is used by the PC Card function to specify the period of time required by the
function to save and/or restore the functionÕs state. The granularity of this count is four milliseconds
(4 ms). A PC Card requiring eighty milliseconds (80 ms) to save and/or restore its state encodes a
value of twenty (14H) in this field. The maximum value that can be encoded in the PWR_TIME field
is FFH, corresponding to one thousand twenty milliseconds (1020 ms).
The PWR_REG_ADDR field indicates the location of the PC Card functionÕs Power Management
Support Register in Attribute Space. This address corresponds with register ten (10) at offset twenty
(20) in the PC Card functionÕs array of Configuration Registers. (See the Electrical Specification.)
The PWR_OFFSET field is the address of the PC Card functionÕs save/restore buffer in a card
address space. When the PWR_METHOD field is 01H the save/restore buffer for the function is in
Common Memory space. When the PWR_METHOD field is 00H the save/restore buffer for the
function is in Attribute Memory space. Note that in Attribute Memory space only even bytes in the
address range are valid and therefore the offset of the buffer must be a multiple of two (2).
The PWR_BUFFSIZE field indicates the number of bytes to be saved during a save operation and
then later restored during a restore operation. When the PWR_METHOD field is 00H, indicating a
save/restore buffer in Attribute Memory space, only even bytes in the address range are counted.
For example, if PWR_METHOD = 00H, PWR_OFFSET = 0100H, and PWR_BUFFSIZE = 20H , the
significant data bytes are the thirty-two (20H) bytes at even addresses in the range 0100H through
013EH in Attribute space.

4. DATA RECORDING FORMATS (LAYER 2)

This level defines the data-recording format for the card. If none of the layer-2 headers are present,
software should assume that the card is organized as an unchecked sequence of bytes.
Card data-recording formats fall into two categories:
· Disk-like Ñ the card consists of a number of data blocks, where each block consists of a fixed
number of bytes. These blocks correspond to the sectors of rotating disk drives. Conceptually,
an entire block must be updated if any byte in the block is to be changed.
· Memory-like Ñ the card is treated as a sequence of directly-addressable bytes of data. Formats
are further categorized according to how error checking is performed.
This Standard recognizes four basic possibilities:
· Unchecked Ñ no data checking is performed at the data-format layer.
· Checked with in-line codes Ñ data checking is performed by the data-format layer using check
codes. The check code for a given block is recorded immediately after the block.
· Checked with out-of-line codes Ñ data checking is performed by the format layer using check
codes. The check code for a given block is recorded in a special table that resides separately
from the data blocks.
· Checked over entire partition Ñ data checking is performed only over the complete partition.
This Standard recognizes two kinds of check codes: arithmetic checksum and CRC. Arithmetic
checksums are typically one-byte or two-bytes long; CRCs are always two-bytes long.
When cards with 16-bit or 32-bit data paths are used to record byte data, it is necessary to specify
how the bytes of the data card correspond to sequential bytes of data. In this Standard, all disk-like
organizations require that bytes be assigned to words, with the lowest-byte-address mapping to the
least-significant byte of the word, and subsequent-byte-address mapping to increasingly significant
bytes.
Memory-like formats also require that the byte mapping be specified. For maximum flexibility,
both little-endian and big-endian byte orders are supported.
4.1 Card Information Tuples

The tuples listed in the following subsections provide generic information about how the card is to
be used.

DATA RECORDING FORMATS (LAYER 2)
4.1.1 CISTPL_BATTERY: The Battery-Replacement Date Tuple

This optional tuple shall be present only in cards with battery-backed storage. It indicates the date
at which the battery was replaced, and the date at which the battery is expected to need
replacement.
Only one CISTPL_BATTERY tuple is allowed per card.
Its format is given below:
Table 4Ð1 CISTPL_BATTERY: Battery Replacement Date Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_BATTERY (45H).
2áá3 TPLBATT_RDAY date battery last replaced.
4áá5 TPLBATT_XDAY date battery due for replacement.
Bytes 2-3, TPLBATT_RDAY, indicate the date on which the battery was last replaced. This field has
the same interpretation as the field TPLDATE_DAY in the CISTPL_DATE tuple.
Bytes 4-5, TPLBATT_XDAY, (the Òexpiration dayÓ) indicate the date on which the battery should be
replaced. This field has the same format as the field TPLDATE_DAY in the CISTPL_DATE tuple.
If either TPLBATT_RDAY or TPLBATT_XDAY are zero, it indicates that the corresponding date was
not known when the tuple was written.

4.1.2 CISTPL_DATE: The Card Initialization Date Tuple

This optional tuple indicates the date and time at which the card was formatted. Only one
CISTPL_DATE tuple is allowed per card. The layout of the tuple is shown below.
Table 4Ð2 CISTPL_DATE: Card Initialization Date Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_DATE (44H).
2áá3 TPLDATE_TIME time the card was initialized.
4áá5 TPLDATE_DAY date the card was initialized.
Bytes 2-3, TPLDATE_TIME, indicate the time at which the card was initialized. It is a 16-bit packed
structure with the following format:
TPLDATE_TIME field
Byte 7 6 5 4 3 2 1 0
0 MINLO SSS
1 HHH MMM HI
· The field HHH contains the hour at which the card was initialized. It is a binary number
between 0 and 23.
· The field MMM contains the minute at which the card was initialized. It is a binary number
between 0 and 59. MMM is a six bit field constructed by combining MMMHI and MMMLO.
· The field SSS represents the two-second interval at which the card was initialized. It is a binary
number between 0 and 29. To convert SSS to seconds, it should be multiplied by two.
Bytes 4-5, TPLDATE_DAY, indicate the date the card was initialized. It is a 16-bit packed structure
with the following format:
TPLDATE_DAY field
Byte 7 6 5 4 3 2 1 0
0 MONLO DAY
1 YYYY MONHI
· The field YYYY represents the year. It is a binary number between 0 and 127, with 0
representing the year 1980.
· The field MON represents the month. It is a binary number between 1 and 12, with 1
representing January. MON is a four bit field constructed by combining MONHI and MONLO.
· The field DAY represents the day. It is a binary number between 1 and 31.
If the date and time components of the date are both zero, this should be taken as an indication that
the date and time were unknown when the card was first initialized.

4.1.3 CISTPL_VERS_2: The Level-2 Version and Information Tuple

The Level-2 information tuple serves to introduce information pertaining to the logical organization
of the cardÕs data. The layout of the Level-2 tuple is shown below. This tuple should appear only
one time in a CIS.
Table 4Ð3 CISTPL_VERS_2: Level-2 Information Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_VERS_2 (40H).
2 TPLLV2_VERS Structure version (00H).
3 TPLLV2_COMPLY Level of compliance claimed.
4áá5 TPLLV2_DINDEX Byte address of first data byte in card (LSB first).
6 TPLLV2_RSV6 Reserved; must be zero.
7 TPLLV2_RSV7 Reserved; must be zero.
8 TPLLV2_VSPEC8 Vendor-specific byte.
9 TPLLV2_VSPEC9 Vendor-specific byte.
10 TPLLV2_NHDR Number of copies of CIS present on the device.
11áák TPLLV2_OEM Vendor of software that formatted card (ASCII, variable length, terminated with NULL [00H]).
k+1áám TPLLV2_INFO Informational message about the card (ASCII, variable length, terminated with NULL [00H]).
TPLLV2_VERS represents the standardization version of the tuple. This byte should always be zero.
TPLLV2_COMPLY indicates the claimed degree of compliance with this Standard. At present, this
should always be zero.
TPLLV2_DINDEX specifies the address of the cardÕs first data byte. Setting this to non-zero reserves
bytes at the beginning of Common Memory.
Note: The first data byte on the card must always be somewhere in the first 64
KBytes of the card. This field should be consistent with information
provided in the format tuple (if that tuple is present).
TPLLV2_NHDR specifies the number of copies of the CIS that are present on the card. For
compatibility with this Standard, this value should be 1.
TPLLV2_OEM specifies the vendor of the machine, or format program, that formatted the card. This
is a text string terminated by a NULL byte (00 H). The value of TPLLV2_OEM, combined with the
value of TPLLV2_INFO, determines how to interpret vendor-specific fields in the Level-2 tuples. For
alternate languages, CISTPL_ALTSTR tuples may follow this tuple, specifying the string value to be
substituted when using alternate languages.
TPLLV2_INFO contains a text message terminated by a NULL byte (00H). This message should be
displayed to users, by a computer, whenever the host needs to describe the type of card that is in
the drive. For alternate languages, CISTPL_ALTSTR tuples may follow this tuple, specifying the
string value to be substituted when using alternate languages.

Note: If the host systemÕs format routine determines that the card is already
formatted, it may display a message like: Caution! This card contains data
for <info>, from <vendor>. The contents of the information field should be
chosen appropriately. For example, a VCR setup card for a VCR by
AlphaBeta Electronics might have <info> as ÒModel 9770 VCRÓ and the
<vendor> field would be ÒAlphaBetaÓ.
The characters used in TPLLV2_INFO and TPLLV2_OEM shall be chosen from the printing 7-bit ISO
646 IRV set (codes 20H through 7EH, inclusive).
TPLLV2_RSV6 and TPLLV2_RSV7 are reserved for use in future versions of this Standard. They
shall be set to zero.
TPLLV2_VSPEC8 and TPLLV2_VSPEC9 are vendor specific. If not used, they shall be set to zero.

4.2 Data Recording Format Tuples

All information about a cardÕs data-recording format is given in special tuples in the Card
Information Structure. Each card that conforms to this StandardÕs Layer 2 shall contain at least one
format tuple defining how the data is recorded on the card.
If the format is disk-like, the format tuple may be followed by a geometry tuple. This tuple
indicates the cylinder, track and sector layout for operating environments that need to treat all mass-
storage devices in that way.
If the format is memory-like, the format tuple may be followed by a byte-order tuple. The byte-
order tuple specifies two independent (but related) parameters:
· How multi-byte numbers are recorded on the media, and
· How byte addresses are assigned within each word (for cards with 16-bit or wider data-paths).

4.2.1 CISTPL_BYTEORDER: The Byte-Order Tuple

This tuple shall only appear in a partition tuple set for a memory-like partition. It specifies two
parameters: the order for multi-byte data, and the order in which bytes map into words for 16-bit
cards.
Table 4Ð4 CISTPL_BYTEORDER: Byte Order Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_BYTEORDER (43H).
1 TPL_LINK Link to next tuple; should be at least 2.
2 TPLBYTE_ORDER Byte order code: see Byte Order Codes table
3 TPLBYTE_MAP Byte mapping code: see Byte Mapping Codes table
Byte 2, TPLBYTE_ORDER, specifies the byte order for multi-byte numeric data. Symbolic codes for
this field begin with the text ÒTPLBYTEORD_Ó, and are listed below.
TPLBYTE_ORDER Byte Order Codes.
Code Name Description
0 TPLBYTEORD_LOW Specifies that multi-byte numeric data is recorded in little-endian
order.
1 TPLBYTEORD_HIGH Specifies that multi-byte numeric data is recorded in big-endian order.
02Háá7FH Reserved for future standardization.
80HááFFH TPLBYTEORD_VS Vendor-specific.
Byte 3, TPLBYTE_MAP, specifies the byte mapping for 16-bit or wider cards. Symbolic codes for this
field begin with the text ÒTPLBYTEMAP_Ó, and are listed below.
TPLBYTE_MAP Byte Mapping Codes.
0 TPLBYTEMAP_LOW Specifies that byte 0 of a word is the least-significant byte (multi-byte
cards).
1 TPLBYTEMAP_HIGH Specifies that byte 0 of a word is the most-significant byte (multi-byte
cards).
02Háá7FH Reserved for future standardization.
80HááFFH TPLBYTEMAP_VS Vendor-specific.
If a byte-order tuple is not present, the data shall be recorded using little-endian byte order,
TPLBYTEORD_LOW, and shall be mapped with byte 0 of each word corresponding to the least-
significant byte, TPLBYTEMAP_LOW.
For applications involving DOS file systems, little-endian byte order and low-to-high byte mapping
are mandatory.

4.2.2 CISTPL_FORMAT, CISTPL_FORMAT_A: The Format Tuples

The format tuples define the data recording format for a region (usually all) of a card. Layouts are
shown below.
Table 4Ð5 CISTPL_FORMAT and CISTPL_FORMAT_A: Format Tuples

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_FORMAT (41H) or CISTPL_FORMAT_A (47H).
1 TPL_LINK Link to next tuple (n-1: at least 12, typically 20)
2 TPLFMT_TYPE Format type code (TPLFMTTYPE_xxx)
3 TPLFMT_EDC Error-detection method and length of error-detection code
RFU Error-detection-code type. EDC Length
4áá7 TPLFMT_OFFSET Byte address of the first data byte in this partition.
8áá11 TPLFMT_NBYTES Number of data bytes in this partition.
12áán Additional information, interpreted based on value of TPLFMT_TYPE.
Note: Bytes 4áá7, TPLFMT_OFFSET, contain the four byte address of the first data
byte in this partition. In CISTPL_FORMAT, defining either CardBus PC
Card memory or 16-bit PC Card Common Memory, this value is the
physical offset in the partition. In CISTPL_FORMAT_A, defining 16-bit PC
Card Attribute Memory only, the value in this field must be multiplied by
2 to obtain the physical address of the first data byte. This is done for
consistency with the usage of the offset field in the Checksum tuple.
Each format tuple implicitly begins a partition tuple set. Subsequent geometry, byte order, software
interleave and data organization tuples are implicitly associated with the preceding format tuple.
Byte one of the tuple specifies the link to the next tuple, and, therefore, (implicitly) the length of this
tuple. Two ranges of values are permitted. Normally, the value will be at least 20 (014H), however,
if the format tuple is specifying a memory-like format, the value may be as little as 12 (0CH), as
bytes 13 through 21 must be zero for memory-like formats. If the partition does not use error-
detecting codes, then the TPLFMT_EDCLOC field may be omitted.
Byte two of the tuple, TPLFMT_TYPE, specifies the kind of format used for this partition. The
permitted values for this field are given below.
TPLFMT_TYPE Format Type Codes.
0 TPLFMTTYPE_DISK This partition uses a disk-like format.
1 TPLFMTTYPE_MEM This partition uses a memory-like format.
02Háá7FH (Reserved for future standardization.)
80HááFFH TPLFMTTYPE_VS This partition uses a vendor-specific format.
· Byte 3, TPLFMT_EDC, specifies the error-detection method, and the length of the error-detection
code. Byte 3 is generally only meaningful for disk-like formats. Bit 7 is reserved; it must be
zero. Bits 3-6 specify the error-detection code. The legal values are given in Table 5-48. Bits 0-2,
TPLFMT_EDCLEN, specify the length in bytes of the error-detection code; this is a number
between 0 and 7. The legal values for the length field are determined by the error-detection
method in use.
· Memory-like regions may use the PCC method of error detection.

TPLFMT_EDC Error Detection Type Codes

0 TPLFMTEDC_NONE No error-detection code is used. If the length field is non-zero, space
will be reserved for the check code, but no checking will be
performed.
1 TPLFMTEDC_CKSUM An arithmetic checksum is used to check the data. The length field
must be 1 if this code is selected. See text for details in calculating the
checksum.
2 TPLFMTEDC_CRC A cyclical redundancy check is used to check the data. The length
field must be 2 if this code is selected. The CRC value is always
recorded low-order byte first.
3 TPLFMTEDC_PCC An arithmetic checksum is used to check the data. However, a single
checksum is provided for the entire data partition. This technique is
intended for use with static data on ROM or OTPROM cards.
The PCC code itself is recorded in byte 18 of the tuple (field
TPLFMT_EDCLOC, byte 0).
The length field must be 1 if this option is selected.
4Háá7H (Reserved for future standardization.)
8HááFH TPLFMTEDC_VS A vendor-specific method of error checking is used.
The code in TPLFMT_EDC only specifies the method to be used to verify data integrity. The value
in TPLFMT_EDCLOC must be consulted to determine whether the code is to be interleaved with
the data, or stored in a separate table.
Bytes 4-7, TPLFMT_OFFSET, specify the absolute byte address of the first data byte governed by
this tuple. The value is stored as a 32-bit quantity with LSB first.
Bytes 8-11, TPLFMT_NBYTES, specify the number of bytes in the partition, including (if present)
the error-detection codes. The value is stored as a 32-bit quantity with LSB first.
4.2.2.1 The Format Tuple for Disk-like Regions

When the TPLFMT_TYPE field of the format tuple has the value TPLFMTTYPE_DISK, bytes 12
through 21 of the tuple are interpreted as shown in below.
Table 4Ð6 Format Tuple for Disk-like Regions

Byte 7 6 5 4 3 2 1 0
12áá13 TPLFMT_BKSZ Block size. For unblocked formats, this value should be 0. This field corresponds to the number
of data bytes per sector. The value in this field must be a power of 2.
14áá17 TPLFMT_NBLOCKS Number of data blocks in this partition.
18áá21 TPLFMT_EDCLOC Location of the error-detection code. If zero, the error-detection code is interleaved with the data
blocks. If non -zero, the error-detection code is stored in a linear table starting at the specified
address on the card. If using PCC, the first byte of this field contains the check code and bytes
19áá21, if present, must be zero.
22 TPLFMT_BAR CardBus PC Card Base Address Register Indicator (CardBus PC Card only).
Bytes 12-13, TPLFMT_BKSZ, specify the number of data bytes in each block in the partition. This
value does not include error-check bytes. The value in this field must be a power of 2 between 128
and 2048. This Standard recommends that 512 be used wherever possible. The value is stored as a
16-bit quantity with LSB first.
Bytes 14-17, TPLFMT_NBLOCKS, specify the number of data blocks in the partition. This value is
stored as a 32-bit quantity with LSB first. The quantity:

TPLFMT_NBLOCKS *(TPLFMT_BKSZ + TPLFMT_EDCLEN)

shall be less than or equal to TPLFMT_NBYTES.
Bytes 18-21, TPLFMT_EDCLOC, specify where the error-detection codes are stored. This value is
stored as a 32-bit quantity with LSB first. If the value stored in this location is zero, or if this field is
not present, then codes (if present) are interleaved with the data blocks, with the code for a given
data block to follow immediately after that block. If the value stored in this location is non-zero, it
shall be the address of the first byte of the error-detection code table. This table shall be an array of
values, with TPLFMT_NBLOCKS entries, containing the error-detection codes for each data block.
Each entry in the table shall have a byte length as indicated by TPLFMT_EDCLEN. The value
stored in TPLFMT_EDCLOC shall be at least the value in TPLFMT_OFFSET, and shall be no
greater than the result of TPLFMT_OFFSET + TPLFMT_NBYTES - (TPLFMT_EDCLEN á
TPLFMT_NBLOCKS). In other words, the table must be entirely contained in the range of bytes
between TPLFMT_OFFSET and TPLFMT_OFFSET + TPLFMT_NBYTES - 1. Since the first data byte
of block 0 resides at TPLFMT_OFFSET, this Standard requires that the EDC table appear after all
the data blocks in the partition. This Standard does not require that the table occur immediately
after the last block, nor does it preclude the use of spare space for vendor-specific purposes.
If PCC error checking is selected, then the TPLFMT_EDCLOC field is used to add the actual CRC
value, rather than pointing to the cell that holds the PCC.
The bit TPLFMT_EDC_RFU is reserved for future use and shall always be zero.
The following table summarizes some possible error-detection strategies.
Error Detection Format Summary
EDC Format EDC EDC Description
Length Location
TPLFMTEDC_NONE 0 0 No error checking is performed and no room is reserved for error-
detection tables. The data blocks are recorded sequentially.
TPLFMTEDC_NONE 2 0 No error checking is performed, but room is reserved for a two-byte
error-detection code after each data block.
TPLFMTEDC_NONE 1 non-zero No error checking is performed, but room is reserved for an out-of-
line table of error-detection codes, with one byte per data block. The
data blocks themselves are recorded contiguously.
TPLFMTEDC_CKSUM 1 non-zero Data is checked using a one-byte arithmetic checksum of the data.
The checksum is stored in an out-of-line table. The data blocks
themselves are recorded contiguously.
TPLFMTEDC_CRC 2 0 Data is checked using SDLC CRC codes. The check-code for a data
block is stored immediately following the data block.
TPLFMTEDC_PCC 1 special Entire partition is checked using a one byte arithmetic checksum. The
checksum is stored in the TPLFMT_EDCLOC field of the tuple itself.
Byte 22, TPLFMT_BAR, is present only on CardBus PC Cards and indicates the Base Address
Register which is being defined. The TPLFMT_BAR field is identical for disk-like and memory-like
partitions. (See 4.2.2.2 The Format Tuple for Memory-like Regions.)
4.2.2.2 The Format Tuple for Memory-like Regions

When the TPLFMT_TYPE field of the format tuple has the value TPLFMTTYPE_MEM, bytes 12
through 21 of the tuple are interpreted as shown below.

Table 4Ð7 Format Tuple for Memory-like Regions

Byte 7 6 5 4 3 2 1 0
12 TPLFMT_FLAGS Various flags
(Reserved) AUTO ADDR
13 (Reserved; must be zero)
14áá17 TPLFMT_ADDRESS Physical address at which this memory partition should be mapped, if so indicated by
TPLFMT_FLAG. Four bytes stored with LSB first.
18áá21 TPLFMT_EDCLOC Error-detection code location, with same meaning as for disk-like regions. Used for PCC
checking only. Byte 18 holds the check value, and bytes 19áá21 must be zero or omitted.
22 TPLFMT_BAR CardBus PC Card Base Address Register Indicator (CardBus PC Card only).
As with the format tuple for disk-like regions, zero bytes may be omitted at the end of the format
tuple for memory-like regions. To do this, the next tuple must begin immediately after the last non-
zero byte in the format tuple.
Byte 12, TPLFMT_FLAGS, contains several control bits.
· Bit 0, TPLFMTFLAGS_ADDR, if set, indicates that bytes 14-17, TPLFMT_ADDRESS, represent a
physical address to be associated with the first byte of this region. If clear, bytes 14-17 do not
represent a physical address and must be zero.
· Bit 1, TPLFMTFLAGS_AUTO, tells the system whether to automatically map the region into
memory when the card is inserted (or at system start-up). If set, the system should attempt to
map the region into memory. If TPLFMTFLAGS_ADDR is set, the system should attempt to
map the code at the specified address. A system shall ignore these fields if it cannot perform the
specified mapping. It may also, at the designerÕs option, ignore these fields even if it could
perform the mapping.
Byte 13 is reserved and, if present, must be set to zero.
Bytes 14 through 17, TPLFMT_ADDRESS, represent the physical address at which the partition
should be mapped into the hostÕs address space. For x86 architecture machines, this is a linear
address, not a segment/offset address. If the flag TPLFMTFLAGS_ADDR is not set, then this field is
reserved and must be zero.
Note: A system can comply fully with this Standard and not honor these fields.
The automatic mapping feature is not intended for general-purpose use, or
for building interchangeable BIOS extensions for general-purpose systems.
This StandardÕs automatic mapping feature is included for use in low-cost
embedded systems, and is not intended as a general, eXecute-In-Place,
specification. Many important issues are deliberately not addressed here,
such as what to do when the card is removed, or how to resolve conflicts
when cards in different sockets both need to be mapped to a specific
physical address. It is anticipated that general purpose DOS-based systems
will ignore these fields.
Bytes 18-21, TPLFMT_EDCLOC, have the same meaning for memory-like regions that they have
for disk-like regions. A memory-like region has only two options for error checking: none or PCC.
Therefore, if this field is used, byte 18 contains the check code, and bytes 19-21 are reserved and
must be zero.
Byte 22, TPLFMT_BAR, is present only on CardBus PC Cards and indicates the Base Address
Register which is being defined.

TPLFMT_BAR field
7 6 5 4 3 2 1 0
Reserved, must be 0. Address Space Indicator
Field Description
Address Space Same encoding as the Address Space Indicator field in the CISTPL_LONGLINK_CB tuple.
Indicator 0 illegal value - zero indicates CardBus PC Card configuration space.
7 the Expansion ROM Base Address Register.
4.2.2.3 Arithmetic Checksums As Error-Detection Codes

Arithmetic checksums shall be computed by summing together all the data bytes of the block using
eight-bit, twos-complement addition and ignoring any overflow that occurs. The resulting sum shall
be stored in an external table (for block-by-block checksum,) or in the format tuple itself (for PCC
checking). This method has the disadvantage that the checksum of a block of zero data is also zero;
however, it is consistent with current practice.
4.2.2.4 CRC Error-Detection Codes

CRC codes shall be computed using the SDLC algorithm1.
The SDLC CRC has a convenient property. When the check code is appended to the data stream,
and the algorithm is run on the result, the remainder will always be x12 + x11 + x10 + x8 + x3 + x2 + x1
+ x0 (assuming that neither the data nor the CRC have been corrupted).
Despite its complicated formal definition, the SDLC CRC is quite easy to compute both in hardware
and in software. Commercially available chips (such as the 9401) can compute the CRC directly from
a serial-data stream. There are several well-known methods for computing the CRC, one-byte-at-a-
time, using a lookup table. Even so, computing a CRC in software is somewhat slower than
computing a simple checksum.
4.2.2.5 Byte Mapping for Disk-Like Media

Within a disk-like partition, cards with 16-bit data paths shall be byte mapped with the lowest-byte
address of each word corresponding to the least-significant byte of that word, and with increasing-
byte addresses corresponding to increasingly significant bytes.
1 Also known as CRC-ITU-T(CCITT) or HDLC CRC. In this algorithm, the data to be checked is considered as a
serial-bit stream, with the low-order bit of the first byte taken as the first bit of the stream. This bit stream is
conceptually taken as the coefficients of a polynomial in x n, where n is the number of bits in the stream, and where
the first bit is the coefficient of the term in x n-1. This polynomial is multiplied by x16 and then divided (modulo 2)
by the polynomial x16 + x12 + x5 + 1, leaving a remainder of order 15 or less. If the register initial-condition is set to
all ones, the CRC code for a block of all zeros will be non-zero. The oneÕs complement of this remainder is the
error-check code. It is recorded with the complemented coefficient of x15 as its least-significant bit, and with the
complemented coefficient of x0 as its most-significant bit.

4.2.3 CISTPL_GEOMETRY: The Geometry Tuple

This tuple shall only appear in partition descriptors for disk-like partitions. It provides instructions
to those operating systems that require that all mass-storage devices be divided into cylinders,
tracks and sectors.
Table 4Ð8 CISTPL_GEOMETRY: Geometry Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_GEOMETRY (42H).
1 TPL_LINK Link to next tuple. (at least 4)
2 TPLGEO_SPT Sectors per track.
3 TPLGEO_TPC Tracks per cylinder.
4áá5 TPLGEO_NCYL Number of cylinders, total.
Byte 2, TPLGEO_SPT, specifies the number of sectors per simulated track on the memory card. This
is a number between 1 and 255. A value of zero is not permitted.
Byte 3, TPLGEO_TPC, specifies the number of tracks per simulated cylinder on the device. This is a
number between 1 and 255. A value of zero is not permitted.
Bytes 4-5, TPLGEO_NCYL, specify the number of simulated cylinders on the device. This is a
number between 1 and 65535, stored as a 16-bit integer with LSB first (this value is one greater than
the same quantity as represented by the PC BIOS). This Standard records the number of simulated
cylinders; the PC BIOS records the maximum cylinder number. Since cylinder numbers on the PC
start at zero , the maximum cylinder number on the PC is one less than the number of cylinders.
The product
TPLGEO_NCYL * TPLGEO_TPC * TPLGEO_SPT
shall be less than or equal to the number of blocks recorded in field TPLFMT_NBLOCKS of the
format tuple.

4.2.4 CISTPL_SWIL: Software Interleave Tuple

This tuple allows the software interleaving of data within a partition on a card. The presence of this
tuple depicts that the partition that it is associated with is 2n (n = TPL_SWIL_INTRLV) interleaved.
The presence of this tuple implies the non-sequential physical address sequence used to read and
write data. The data is reconstructed after reading the data from the card using an n-way
interleaved sequence. Note, this tuple is associated with the previous format tuple.
Table 4Ð9 CISTPL_SWIL: Software Interleave Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_SWIL (23H).
2 TPL_SWIL_INTRLV Value = n, where data is recorded via software interleaving by a factor of 2n. The partition
total size divided by this interleaving factor defines the higher-order address ÒoffsetÓ by
which addresses are incremented until the interleave ÒloopÓ is completed. Between loops,
low-order addresses are incremented to the next physical word whereupon offset
increments are used through the next loop (and so on).
The value of n = 0 is reserved and shall not be used.
Assumptions:
The software interleave tuple must be associated with a Format Tuple (partition tuple set) that
describes a homogeneous partition beginning and ending on a physical device boundary and hence
referring to one and only one Device Info entry and associated Device Geometry Info entry within
the Device Information Tuple and the Device Geometry Tuple respectively.
The DGTPL_HWIL field within the Device Geometry Info entry must equal 1, i.e. non-hardware
interleaved.
The following provide the association of the Software Interleave Tuple and the implied Òsoftware
interleave partitionÓ with the Device Information Tuple, Device Geometry Tuple and Format Tuple.
Òsoftware interleaved partitionÓ base address = TPLFMT_OFFSET
Òsoftware interleaved partitionÓ length = TPLFMT_NBYTES
The size or length of the partition must be a multiple of the stride (below).
Òsoftware interleaved partitionÓ interleave width = DGTPL_WBS * DGTPL_BUS
Òsoftware interleaved partitionÓ stride = DGTPL_BUS * (size in bytes of a physical device)
The device size is determined from the Device Info entry of the Device Information Tuple.

4.3 Standard Data Recording Formats

This Standard allows great flexibility in adjusting the card format to meet specific requirements. For
simplicity, this Standard further specifies recommended formats for low-level data recordingÑ
formats which are expected to be commonly used. Higher level data formats will be specified in
addition to this level.
· Generic Ñ the bytes are recorded in 512-byte blocks with no error checking. The cardÕs first
data byte appears at byte address 512 (200H).
· Single-byte checksum format Ñ the bytes are recorded in 512-byte blocks, with a separate
region reserved for error-checking codes, and with a sector buffer.
· Two-byte Embedded CRC format Ñ the bytes are recorded in 512-byte blocks, with each block
followed by a 16-bit CRC.
· Raw- byte format Ñ the bytes are recorded sequentially in an unblocked form.
In order to maintain a reasonable degree of interchangeability, this Standard recommends that all
Layer-2 conforming implementations be able to read and write generic-format cards.
When an implementation is presented with a card, whose format is not supported by that
implementation, the implementation shall refuse to write on the card, except to reinitialize it. If the
basic format is not supported by the implementation at all, the implementation shall return an error
to applications whenever they attempt to access the card. The implementation may allow read-only
access to a card whose basic format is supported, but whose error-detecting code is not.
For example, an implementation that only supports the creation of generic-format cards could allow
single-byte-checksum cards to be read by ignoring the checksum bytes. With a little more
sophistication, the implementation could also allow embedded-CRC format cards to be read.
4.4 Mixed Data Formats

Layer 2 allows a card to have multiple partitions, with each partition having its own data-recording
format. In this case, there shall be one format tuple in the Card Information Structure for each
partition on the card. The additional tuples that refer only to a given partition shall appear
immediately following the format tuple that defines the partition.
An implementation is not required to support multiple partitions on a single card. When presented
with a card with multiple partitions, an implementation may:
· Only allow access to the first partition (if supported),
· Scan the CIS for the first partition of a supported type, and only allow access to that partition.
· Deny access to the card.
Note: In most applications only one or two regions will be needed. (Two regions
would be used by a ROM card that contained both executable ROM images
and a DOS file system).

5 . D AT A O R G A N I Z AT I O N ( L AY E R 3 )
This layer defines the data organization of a particular partition on a memory card. At this level, the
possibilities become complex. Some examples are:
· A partition can contain a DOS-file system (or a file system for some other operating system).
This can be used with any disk-like, Level-2 format.
· A partition can contain a Flash file system (used with memory-like formats).
· A partition can use a vendor-specific organization.
· A partition can use an application-specific organization.
Layer 3 of this Standard provides an unambiguous means of specifying the organization of the
partition. (See also the Media Storage Formats Specification.)
5.1 Data Organization Tuples

All information about the organization of a given partition is given in special tuples in the Card
Information Structure. Each card that conforms to Layer 3 of this Standard shall contain at least one
data-organization tuple for each partition defined on the card.
At present, the data-organization tuple is the only defined Layer 3 tuple.

DATA ORGANIZATION (LAYER 3)
5.1.1 CISTPL_ORG: The Organization Tuple

The Organization Tuple appears in the series of partition-specific tuples that follows each format
tuple. It has the format shown below.
Table 5Ð1 CISTPL_ORG: Data Organization Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_ORG (46H)
1 TPL_LINK Link to next tuple (at least n-1).
2 TPLORG_TYPE Data organization code
3áán TPLORG_DESC Text description of this organization, terminated by NULL (00H).
Byte 2, TPLORG_TYPE, specifies the type of data organization in use. The possible values of this
byte are given below:
TPLORG_TYPE Codes
0 TPLORGTYPE_FS This partition contains a file system. The description field specifies
the file system type and version.
1 TPLORGTYPE_APP This partition contains application-specific information. The
description field specifies the application name and version.
2 TPLORGTYPE_ROMCODE This partition contains executable code images. The description field
specifies the name and version of the organization scheme.
03Háá7FH (Reserved for future standardization.)
80HááFFH TPLORGTYPE_VS This partition uses a vendor-specific organization. The contents of the
description field are vendor-specific.
Bytes 3 through the end of the tuple, TPLORG_DESC, contain a NULL-terminated ASCII-text
description of the organization. For file-system organizations, this field should specify the file-
system type. This field shall contain only characters in the printing ASCII set, 020 H through 07EH.
(For international use, one or more CISTPL_ALTSTR tuples can follow this tuple.)
The intent of this field is two-fold:
· For operating systems with sufficient flexibility, it allows the appropriate file-system driver to
be selected based on the value of this field.
· If a card cannot be read due to software incompatibilities, a utility program can display to the
user the contents of this field along with other card information. This would inform the user
what kind of information is actually on the card.
A summary of the defined TPLORG_DESC codes follows.

TPLORG_DESC Codes
TPLORG_TYPE Card TPLORG_DESC Description
Services
Index
RESERVED 0000H none This value is used by Card Services to indicate
that there is no CISTPL_ORG.
TPLORGTYPE_FS 0001H "DOS" DOS-file systems
TPLORGTYPE_FS 0002H "Flash" Microsoft Flash File System - Version 1
TPLORGTYPE_FS 0003H "FFS20" Microsoft Flash File System - see the Media
Storage Formats Specification.
TPLORGTYPE_FS 0004H "FTL100" Flash Translation Layer - see the Media Storage
TPLORGTYPE_FS 0005H "LFS100" Linear File Store - see the Media Storage Formats
Specification.
TPLORGTYPE_FS 0006H "VS" Vendor-Specific partition
RESERVED 7FFFH Card Services returns this value when indicating
an ÒUnknown partitionÓ to a client.
Note: All TPLORG_DESC fields must be null terminated.
The Card Services GetFirst/NextPartition services return values listed in the Card Services Index
field. (See the Card Services Specification.)

6 . SYSTEM-SPECIFIC STANDARDS (LAYER 4)

Layer 4 of this standard specifies items that are only relevant in certain operating environments.
The following DOS-specific items are defined in other volumes of this Standard:
· An interchange format for cards formatted with the DOS FAT-based file system. (See the Media
Storage Formats Specification.)
· A standard for directly-executable programs. (See the XIP Specification.)
6.1 System-Specific Standard Tuples
6.1.1 CISTPL_SPCL: Special Purpose Tuple

The Special Purpose Tuple is identified by a thirty-two (32) bit field assigned by PCMCIA or JEIDA.
An eight (8) bit field allows a series of Special Purpose Tuples to be used when the data exceeds the
size that can be stored in a single tuple; the maximum data area of a series of Special Purpose
Tuples is unlimited. Another eight (8) bit field gives the number of bytes in the data field in this
tuple.
When the Special Purpose Tuple is used to address IPL from a PC Card, the tuple provides only
enough information to allow a bootstrap loader to fetch significant data bytes and place them in host
system memory for execution. Once in memory, it is the responsibility of the loader to determine
whether they are appropriate for the environment. The Special Purpose Tuple contains the
following fields:
Table 6Ð1 CISTPL_SPCL: Special Purpose Tuple

Byte 7 6 5 4 3 2 1 0
0 TPL_CODE CISTPL_SPCL (90H)
1 TPL_LINK Link to next tuple (n-2 minimum)
2áá5 TPLSPCL_ID This 32-bit field contains a PCMCIA or JEIDA assigned value that identifies this series of one or
more Special Purpose Tuples. TPLSPCL_ID values are assigned by contacting either PCMCIA
or JEIDA.
6 TPLSPCL_SEQ The last tuple in the series has END (bit 7 in this field) set to one (1); any other tuples in the
series have END reset to zero (0). SEQUENCE (bits 0áá6 in this field) is assigned ascending
values starting with zero (0). When SEQUENCE reaches 127 (1111111B) and END is not set to
one (1) the next tuple SEQUENCE value is set to zero (0).
END SEQUENCE
7 TPLSPCL_BYTES The number of bytes in TPLSCPL_DATA, the data component of this tuple.
8áán TPLSPCL_DATA The data component of this tuple (8 £ n £ 257)
If more data is required than will fit in a single tuple, additional Special Purpose Tuples appear in
the CIS. A grouping of Special Purpose Tuples with identical TPLSPCL_ID values is called a series
of Special Purpose Tuples. A TPLSPCL_ID value can appear in only one series of Special Purpose
Tuples in a CIS; it may never be repeated in another series of Special Purpose Tuples in the same
CIS.
The TPLSPCL_SEQ field is divided into a single bit flag, END (bit 7), and a seven bit field,
SEQUENCE (bits 0áá6). SEQUENCE is assigned values ranging from zero (0) to one hundred twenty-
seven (127) in ascending order beginning with zero (0) and resetting to zero (0) after reaching one

SYSTEM-SPECIFIC STANDARDS (LAYER 4)
hundred twenty-seven (127). The last tuple in the series is indicated by setting the END bit to one
(1). A series consisting of a single tuple has a TPLSPCL_SEQ field with a value of one hundred
twenty-eight (10000000B).
The TPLSPCL_BYTES field contains the number of data bytes in the TPLSPCL_DATA field.
A series of Special Purpose Tuples must be placed in the CIS in the order that it is to be processed in
the host environment.

7 . C O M P AT I B I L I T Y I S S U E S
7.1 Buffer Pages

Some vendors use a buffer page to improve the reliability of memory cards in the face of power
failures. This standard does not directly provide a means for specifying the location of the buffer
page. Space can easily be reserved for a buffer page by proper adjustment of the values in the
format tuple. If needed, a vendor-specific tuple can be added to specify the location of the buffer
page within the partition.
7.2 Media Storage Formats

See the Media Storage Formats Specification.

Volume 6
Socket Services Specification
PCMCIA
JEIDA
1030 East Duane Avenue, Suite G IMMUNITY AGREEMENT
Sunnyvale, CA 94086 USA CONTAINED ELSEWHERE IN
+1-408-720-9416 (Fax) IMPORTANT:
+81-3-3433-1923 PCMCIA
+81-3-3433-6350 (Fax) 1030 East Duane Avenue, Suite G
Sunnyvale, CA 94086, USA
INFRINGEMENT,
YOU ÒAS IS.Ó

SOCKET SERVICES SPECIFICATION
CONTENTS
1. Introduction____________________________________________1
1.1 Purpose................................................................................................................................1
1.2 Scope....................................................................................................................................1
2. Overview ______________________________________________3
3. Functional Description __________________________________5
3.1 System Architecture ............................................................................................................5
3.2 Initialization.........................................................................................................................5
3.3 Configuration.......................................................................................................................5
3.4 Status Change Notification.................................................................................................6
3.5 Power Management.............................................................................................................6
3.6 Docking................................................................................................................................6
3.7 Overview of Services............................................................................................................7
3.7.1 Non-specific Service..................................................................................................................................................................7
3.7.2 Adapter Services........................................................................................................................................................................7
3.7.3 Socket Services............................................................................................................................................................................8
3.7.4 Window Services.......................................................................................................................................................................8
3.7.5 Error Detection and Correction Services..........................................................................................................................8
3.7.6 Status Change Handling .........................................................................................................................................................8
3.7.7 Reserved Services ......................................................................................................................................................................9
4. Assumptions and Constraints ___________________________11

4.1 ROM Located.....................................................................................................................11
4.2 Hardware Implementation................................................................................................11
4.3 Adapters Supported .........................................................................................................11
4.4 Sockets Supported.............................................................................................................11
4.5 Windows Supported .........................................................................................................12
4.6 EDC Generators.................................................................................................................13
4.7 Power Management and Indicators..................................................................................13
4.8 Calling Conventions...........................................................................................................13
4.8.1 Reserved Fields ........................................................................................................................................................................1 3
4.8.2 Register Usage ..........................................................................................................................................................................1 3
4.9 Socket Services Generally Not Re-entrant .........................................................................14

CONTENTS
4.10 Critical Areas and Disabled Interrupts ..........................................................................14

4.11 Request Rejection.............................................................................................................14
5. Program Interface _____________________________________ 15

5.1 Presence Detection.............................................................................................................15
5.2 Data Types ........................................................................................................................15
5.3 Service Descriptions...........................................................................................................17
5.3.1 AccessConfigurationSpace [PC32] ....................................................................................................................................1 8
5.3.2 AcknowledgeInterrupt [BOTH] .........................................................................................................................................1 9
5.3.3 GetAccessOffsets [PC16] .......................................................................................................................................................2 1
5.3.4 GetAdapter [BOTH] ...............................................................................................................................................................2 3
5.3.5 GetAdapterCount [BOTH] ...................................................................................................................................................2 4
5.3.6 GetBridgeWindow [BOTH] ................................................................................................................................................2 5
5.3.7 GetEDC [BOTH].......................................................................................................................................................................2 7
5.3.8 GetPage [PC16] .........................................................................................................................................................................2 8
5.3.9 GetSetPriorHandler [BOTH]...............................................................................................................................................3 0
5.3.10 GetSetSSAddr [BOTH] .......................................................................................................................................................3 2
5.3.11 GetSocket [BOTH].................................................................................................................................................................3 5
5.3.12 GetSSInfo [BOTH].................................................................................................................................................................3 8
5.3.13 GetStatus [BOTH] .................................................................................................................................................................3 9
5.3.14 GetVendorInfo [BOTH] ......................................................................................................................................................4 1
5.3.15 GetWindow [PC16] ..............................................................................................................................................................4 2
5.3.16 InquireAdapter [BOTH] .....................................................................................................................................................4 4
5.3.17 InquireBridgeWindow [BOTH] ......................................................................................................................................4 8
5.3.18 InquireEDC [BOTH].............................................................................................................................................................5 4
5.3.19 InquireSocket [BOTH] .........................................................................................................................................................5 6
5.3.20 InquireWindow [PC16].......................................................................................................................................................5 9
5.3.21 PauseEDC [BOTH]................................................................................................................................................................6 7
5.3.22 ReadEDC [BOTH].................................................................................................................................................................6 8
5.3.23 ResetSocket [BOTH] .............................................................................................................................................................6 9
5.3.24 ResumeEDC [BOTH]............................................................................................................................................................7 0
5.3.25 SetAdapter [BOTH]..............................................................................................................................................................7 1
5.3.26 SetBridgeWindow [BOTH]...............................................................................................................................................7 3
5.3.27 SetEDC [BOTH] .....................................................................................................................................................................7 5
5.3.28 SetPage [PC16]........................................................................................................................................................................7 6
5.3.29 SetSocket [BOTH]..................................................................................................................................................................7 8
5.3.30 SetWindow [PC16] ...............................................................................................................................................................8 1
5.3.31 StartEDC [BOTH] .................................................................................................................................................................8 3
5.3.32 StopEDC [BOTH] ..................................................................................................................................................................8 4
5.3.33 VendorSpecific [BOTH]......................................................................................................................................................8 5
6. Using Socket Services__________________________________ 87

6.1 Determining Socket Services Resources ............................................................................87
6.2 Status Change Handling ...................................................................................................87
6.3 Bus-Expanders or Docking Stations .................................................................................88

6.4 Using XIP...........................................................................................................................88
6.5 Power Management...........................................................................................................88
7. Service Codes _________________________________________89

8. Return Codes _________________________________________91
9. Socket Services Bindings _______________________________93
9.1 Overview............................................................................................................................93
9.2 Presence Detection and Installation Notification .............................................................93
9.3 Making Socket Services Requests......................................................................................93
9.4 Argument Passing.............................................................................................................94
9.5 Power Management and Indicators..................................................................................94
9.6 x86 Architecture Binding...................................................................................................94
9.6.1 Overview ....................................................................................................................................................................................9 4
9.6.2 Presence Detection ...................................................................................................................................................................9 5
9.6.3 Installation Notification .......................................................................................................................................................9 5
9.6.4 Making Socket Services Requests......................................................................................................................................9 6
9.6.5 Argument Passing ...................................................................................................................................................................9 6
9.6.5.1 CPU Register Interface Usage...............................................................................................................................9 6
9.6.5.2 Packet Interface Usage............................................................................................................................................9 7
9.6.5.2.1 Overview ...........................................................................................................................................................9 7
9.6.5.2.2 Packet Interface - real-mode x86...............................................................................................................9 9
9.6.5.2.3 Packet Interface - OS/2 .................................................................................................................................9 9
9.6.5.2.4 Packet Interface - Win-16 ..........................................................................................................................100
9.6.5.2.5 Packet Interface - Win32 VxD .................................................................................................................101
9.6.6 Assumptions and Constraints .........................................................................................................................................102
9.6.6.1 ROM BIOS Located ..............................................................................................................................................102
9.6.6.2 Adapters Supported .............................................................................................................................................102
9.6.6.3 EDC Generators .....................................................................................................................................................102
9.6.6.4 Sockets Supported .................................................................................................................................................102
9.6.6.5 Windows Supported ............................................................................................................................................102
9.6.7 Individual Service Bindings ............................................................................................................................................103
9.6.7.1 CPU Register Usage Bindings...........................................................................................................................103
9.6.7.1.1 AccessConfigurationSpace.......................................................................................................................103
9.6.7.1.2 AcknowledgeInterrupt ..............................................................................................................................1 03
9.6.7.1.3 GetAccessOffsets..........................................................................................................................................104
9.6.7.1.4 GetAdapter ....................................................................................................................................................104
9.6.7.1.5 GetAdapterCount ........................................................................................................................................105
9.6.7.1.6 GetBridgeWindow .....................................................................................................................................105
9.6.7.1.7 GetEDC............................................................................................................................................................106
9.6.7.1.8 GetPage............................................................................................................................................................106
CONTENTS
9.6.7.1.9 GetSetPriorHandler....................................................................................................................................106
9.6.7.1.10 GetSetSSAddr ............................................................................................................................................107
9.6.7.1.11 GetSocket......................................................................................................................................................109
9.6.7.1.12 GetSSInfo......................................................................................................................................................110
9.6.7.1.13 GetStatus ......................................................................................................................................................110
9.6.7.1.14 GetVendorInfo ...........................................................................................................................................110
9.6.7.1.15 GetWindow.................................................................................................................................................111
9.6.7.1.16 InquireAdapter ..........................................................................................................................................111
9.6.7.1.17 InquireBridgeWindow ...........................................................................................................................112
9.6.7.1.18 InquireEDC..................................................................................................................................................112
9.6.7.1.19 InquireSocket ..............................................................................................................................................113
9.6.7.1.20 InquireWindow .........................................................................................................................................113
9.6.7.1.21 PauseEDC.....................................................................................................................................................114
9.6.7.1.22 ReadEDC......................................................................................................................................................114
9.6.7.1.23 ResetSocket ..................................................................................................................................................114
9.6.7.1.24 ResumeEDC.................................................................................................................................................115
9.6.7.1.25 SetAdapter...................................................................................................................................................115
9.6.7.1.26 SetBridgeWindow....................................................................................................................................115
9.6.7.1.27 SetEDC ..........................................................................................................................................................116
9.6.7.1.28 SetPage ..........................................................................................................................................................116
9.6.7.1.29 SetSocket.......................................................................................................................................................117
9.6.7.1.30 SetWindow..................................................................................................................................................117
9.6.7.1.31 StartEDC ......................................................................................................................................................117
9.6.7.1.32 StopEDC .......................................................................................................................................................118
9.6.7.1.33 VendorSpecific...........................................................................................................................................118
9.6.7.2 Packet Usage Bindings ........................................................................................................................................119
9.6.7.2.1 AccessConfigurationSpace.......................................................................................................................119
9.6.7.2.2 AcknowledgeInterrupt ..............................................................................................................................1 20
9.6.7.2.3 GetAccessOffsets..........................................................................................................................................121
9.6.7.2.4 GetAdapter ....................................................................................................................................................122
9.6.7.2.5 GetAdapterCount ........................................................................................................................................123
9.6.7.2.6 GetBridgeWindow .....................................................................................................................................124
9.6.7.2.7 GetEDC............................................................................................................................................................125
9.6.7.2.8 GetPage............................................................................................................................................................126
9.6.7.2.9 GetSetPriorHandler....................................................................................................................................127
9.6.7.2.10 GetSetSSAddr ............................................................................................................................................128
9.6.7.2.11 GetSocket......................................................................................................................................................130
9.6.7.2.12 GetSSInfo......................................................................................................................................................131
9.6.7.2.13 GetStatus ......................................................................................................................................................132
9.6.7.2.14 GetVendorInfo ...........................................................................................................................................133
9.6.7.2.15 GetWindow.................................................................................................................................................134
9.6.7.2.16 InquireAdapter ..........................................................................................................................................135
9.6.7.2.17 InquireBridgeWindow ...........................................................................................................................136
9.6.7.2.18 InquireEDC..................................................................................................................................................137
9.6.7.2.19 InquireSocket ..............................................................................................................................................138
9.6.7.2.20 InquireWindow .........................................................................................................................................139
vi © 1999 PCMCIA/JEIDA
9.6.7.2.21 PauseEDC.....................................................................................................................................................140
9.6.7.2.22 ReadEDC......................................................................................................................................................140
9.6.7.2.23 ResetSocket ..................................................................................................................................................141
9.6.7.2.24 ResumeEDC.................................................................................................................................................141
9.6.7.2.25 SetAdapter...................................................................................................................................................142
9.6.7.2.26 SetBridgeWindow....................................................................................................................................143
9.6.7.2.27 SetEDC ..........................................................................................................................................................144
9.6.7.2.28 SetPage ..........................................................................................................................................................145
9.6.7.2.29 SetSocket.......................................................................................................................................................146
9.6.7.2.30 SetWindow..................................................................................................................................................147
9.6.7.2.31 StartEDC ......................................................................................................................................................148
9.6.7.2.32 StopEDC .......................................................................................................................................................148
9.6.7.2.33 VendorSpecific...........................................................................................................................................149
9.6.8 Assembly Language Definitions.....................................................................................................................................150

TABLES
Table 7Ð1 Service CodesÐNumerical Order..................................................................................89
Table 7Ð2 Service Codes  Alphabetic Order..............................................................................90
Table 8Ð1 Return Codes  Numerical Order...............................................................................91
Table 8Ð2 Return Codes  Alphabetic Order..............................................................................92
1.1 Purpose
This document describes the software interface provided by PC Card Standard Socket Services. This
interface provides a hardware independent method of managing PC Card sockets in a host system.
1.2 Scope
This document is intended to provide enough information to software developers to utilize PC Card
sockets in a host system without any knowledge of how the actual hardware performs the desired
services. It is also intended to provide enough information for an implementer to create a Socket
Services handler for a particular adapter.

Volume 11: PC Card Host Systems Specification
2. O V E R V IE W
Socket Services is the lowest layer in a multi-layer architecture that manages resources on PC Card
Standard compatible memory and I/O cards (collectively known as PC Cards). Socket Services
provides a universal software interface to the hardware that controls sockets for PC Cards. It masks
the details of the hardware used to implement these sockets, allowing higher-level software to be
developed which is able to control and utilize PC Cards without any knowledge of the actual
hardware interface.
Software layers above Socket Services provide additional capabilities. Immediately above Socket
Services is Card Services which arbitrates the use of Socket Services resources. Card Services is
responsible for taking requests from multiple processes and sharing the resources provided by
Socket Services among these processes. In this manner, Card Services may actually provide the
same hardware to different processes allowing the use of the hardware to be time-multiplexed.
For example, if a BPBÐFAT partition and a Flash File System partition both reside on a Flash card,
Card Services might provide the same windows into the host system memory address space for both
of the device drivers involved in accessing those partitions. Card Services is responsible for
handling overlapping requests, ensuring that the appropriate partition is available at the right
time.
Socket Services approaches the handling of the hardware it manages by addressing it as a number
of objects with different areas of functionality. Adapters are the hardware that connects a host
systemÕs bus to PC Card sockets. Host systems may have more than one adapter. Socket Services
reports the number of sockets, windows and EDC generators provided by each adapter installed.
Adapter power consumption and status change reporting may be controlled separately for each
adapter.
An adapter may have one or more sockets. Sockets are receptacles for PC Cards. Socket Services
describes the characteristics of each socket and allows socket resources to be manipulated and
current settings determined.
Socket Services also provides services to deal with PC Cards. These services report on current card
status, allow data to be read and/or written on 16-bit PC Cards which are not mapped into system
memory address space, and allow configuration space to be read and/or written on CardBus PC
Cards.
For performance reasons, it is often beneficial to map PC Cards into host system memory or I/O
address space. (XIP requires the ability to map PC Card memory arrays into system memory
address space.) Adapters may or may not provide this capability. An area of PC Card memory
and/or I/O address space is mapped into a corresponding host system area through a window.
From the Socket Services perspective, there are three types of hardware that may be involved in
mapping a PC CardÕs address space into a host systemÕs address space.
Adapters for 16-bit PC Cards have windows on the adapter that map PC Card address space into the
host systemÕs address space. These windows map memory and/or I/O address space. Devices on a
16-bit PC Card are always located at the same PC Card address. The area of a PC Card mapped into
a host systemÕs address space is determined by a combination of adapter decoding and PC Card
decoding.
Adapters for CardBus PC Cards do not perform any mapping of PC Card address space into a host
systemÕs address space. Base Address Registers on the PC Card itself are programmed to decode
host system addresses directly.
OVERVIEW
If an adapter also acts as a bridge to another host system bus, it may have bridge windows. Bridge
windows are used to route a range of host system addresses across the bridge to a PC Card. Bridge
windows are controlled separately from the windows on a 16-bit PC Card adapter or the Base
Address Registers on a CardBus PC Card. If an adapter uses bridge windows, the address ranges
routed by the bridge windows must include the ranges used by 16-bit PC Card adapter windows or
the ranges programmed into the Base Address Registers on a CardBus PC Card.
3 . FU N C T ION AL DE S C R IP T ION
3.1 System Architecture

Socket Services is a software interface to the hardware used to manage PC Card sockets in a host
system. Above Socket Services, an operating system-specific layer known as Card Services
virtualizes Socket Services to allow it to be shared by multiple processes. These processes may
include such things as eXecute-In-Place (XIP), Flash File System (FFS), and other types of device
drivers.
Socket Services provides only the lowest level access to PC Cards. For example, Socket Services
allows the 16-bit PC Card attribute memory space to be read, but it does not interpret the Card
Information Structure (CIS).
Socket Services is invoked in a platform dependent manner. All service arguments are passed to
Socket Services in a binding specific fashion. Status of a Socket Services request is returned in the
status argument. (See Appendix-C, 9. Socket Services Bindings.) Using functional notation, a Socket
Services request generically can be considered as:
status = Service(arg1, arg2 ...)
While this notation resembles a C language function call, Socket Services is implemented in an
appropriate manner for its environment. For example, on an x86 architecture platform a ROM BIOS
Socket Services interface is handled through Interrupt 1AH with services based at 80H. A client
simply sets the host processorÕs registers for the service desired and executes the Socket Services
software interrupt. Status is returned using the Carry flag ([CF]) and registers specific to the service
invoked.
Special handling is required to be able to write many types of memory cards. It is not feasible to
attempt to include all the necessary handlers within Socket Services for all the possible types of
write/erase routines. Handling of technology-specific write requirements is intended to be
performed by a software layer above Socket Services. Socket Services provides access to the
hardware for these card technology routines.
3.2 Initialization
Socket Services is internally initialized during installation and no specific installation is required by
the client before making service requests. It is expected the client of Socket Services will check the
Socket Services Compliance to determine the level of service available. (See 5.3.12 GetSSInfo
[BOTH].)
3.3 Configuration
The next step is to enumerate the capabilities of the implementation. This entails determining the
number of adapters installed, how many sockets, bridge and 16-bit PC Card windows are supported
by each adapter, and exploring the power management and indicators available for each adapter.
As noted above, it is expected that Socket Services is virtualized by Card Services. Above Card
Services are device drivers for different types of PC Cards. These drivers map PC Cards into system
I/O and/or memory space to implement their functions. Multiple drivers may share PC Cards and
FUNCTIONAL DESCRIPTION
sockets and may even share windows. Card Services arbitrates requests for Socket Services resources
and is responsible for preserving any state information required to share these resources.
3.4 Status Change Notification

A Socket Services client may desire notification when a status change occurs. Status changes include,
but are not limited to, the following: card removal or insertion, battery low or dead, and READY
changes. Socket Services supports steering and enabling status change interrupts from an adapter.
A client installs a status change interrupt handler on the host interrupt level selected to receive such
interrupts. A client may choose to poll for changes in socket and card status.
When an adapter configured for status change interrupts detects a status change, it generates an
interrupt which invokes the clientÕs status callback handler. This handler uses the Socket Services
AcknowledgeInterrupt service to determine which socket or sockets experienced the status change.
It records this information and completes the hardware interrupt processing. Later, during
background processing, the client notes which sockets require attention and uses the GetStatus
service to determine current PC Card and socket state. This state is used to determine what action
should be taken by the client. Status change interrupt handling is provided by Card Services. (See
the Card Services Specification.)
3.5 Power Management

The Socket Services interface provides controls for conserving adapter power. Two power
conservation modes are provided: reduced with all state information maintained and reduced
without state information being maintained. These levels are established with the SetAdapter
service.
Socket Services may also be used to manage power to PC Card sockets. Independent controls and
levels are provided for VCC, VPP1 and VPP2. Since available power levels are generally limited,
Socket Services provides a list of supported levels and then allows power adjustment based on an
index into that list. Power management is performed at the socket level. How Socket Services
resolves power management requests in hardware implementations that only allow control of power
at the adapter level is vendor specific. Socket Services reports the level of power management
control available through the InquireAdapter service.
3.6 Docking
Whether or not Socket Services is dynamically loaded (or unloaded) there is a general sequence of
things that Socket Services needs to perform in order to handle dock events. Considering all
possible dock scenarios Socket Services really is performing one of three actions: add support (dock
where new controllers are present requiring new Socket Services handlers), remove support
(undock where controllers are gone requiring removal of Socket Services handlers) or
change/replace support (either dock or undock using same socket services instance). This leads to
the following sequences for communications between Socket Services and Card Services:
I. Replace Support
A. Socket Services issues ReplaceSocketServices to Card Services w/ Base log. Socket #
(obtained via MapPhyLogSocket) and number of sockets to replace. Until Socket Services
receives GetSetPriorHandler or Card Services returns from ReplaceSocketServices this
Socket Services rejects any request (except GetSSInfo, see below for more info) w/ BUSY
return code.
B. Upon receipt of GetSetPriorHandler
1. If previous is NULL then return w/ adapter 0; else,

2. Add itself as supporting next adapter (if any such adapter exists that needs support else
may take steps to remove itself from memory if environment supports this).
C. Receives return from ReplaceSocketServices request.
D. Receives and processes normal ÒinitializationÓ requests from Card Services.
II. Add Support
A. Socket Services issues AddSocketServices to Card Services
B. Socket Services receives GetSetPriorHandler and before returning numbers his adapter (via
GetSSInfo) and return
C. Returns proper data to GetSSInfo
D. Receives return from AddSocketServices
E. Receives and processes normal ÒinitializationÓ requests from Card Services.
III. Remove Support
A. Use same logic flow as Replace Support except return zero (0) supported adapters for
GetSSInfo request.
NOTE: The GetSetPriorHandler request is used by Card Services implementations

that expect Socket Services handlers to track the chain of handlers. Some
Card Services implementations will track the handlers themselves and in
this situation Socket Services may not receive any GetSetPriorHandler
requests during processing of dock events.
3.7 Overview of Services
3.7.1 Non-specific Service

There is one Socket Services service which applies to the interface in general and not to any objects
manipulated by the interface. It is:
GetAdapterCount
3.7.2 Adapter Services

Socket Services addresses adapters with the following services:
AcknowledgeInterrupt GetSSInfo
GetSetPriorHandler GetVendorInfo
GetSetSSAddr InquireAdapter
GetAccessOffsets SetAdapter
GetAdapter VendorSpecific
FUNCTIONAL DESCRIPTION
3.7.3 Socket Services

Socket Services addresses sockets with the following services:
GetSocket ReSetSocket
GetStatus SetSocket
InquireSocket AccessConfigurationSpace
3.7.4 Window Services

Socket Services addresses windows with the following services:
GetBridgeWindow SetBridgeWindow
GetPage SetPage
GetWindow SetWindow
InquireWindow InquireBridgeWindow
WA R N IN G :
Windows which map 16-bit PC Cards into host system memory address space
may have one or more pages. If a Window contains multiple pages, each page
must be 16 KBytes and windows must be sized as a multiple of the 16 KByte
page size.
3.7.5 Error Detection and Correction Services

Adapters and/or Sockets may optionally provide error detection and correction support. The
following services handle EDC capabilities:
GetEDC ResumeEDC
InquireEDC SetEDC
PauseEDC StartEDC
ReadEDC StopEDC
3.7.6 Status Change Handling

Socket Services provides for asynchronous notification when a socketÕs status changes. Each adapter
may provide a hardware interrupt when there is a status change. This interrupt is processed by a
handler installed by the Socket Services client.
While only one interrupt per adapter is anticipated, the Socket Services interface allows status
changes to be masked on a per socket basis. Masking must be performed in hardware since the
hardware interrupt is handled directly by the Socket Services client.
If status change interrupts are supported, each Socket Services client determines which interrupt it
uses for status changes based on the set of supported interrupts reported by InquireAdapter. A
Socket Services client may enable or disable this capability and may steer the interrupt to a
supported host interrupt level.
3.7.7 Reserved Services

Depending on the binding, some Socket Services service codes may be reserved for historical
reasons and should not be used. If a client uses one of these service codes, an implementation
should return BAD_SERVICE.
4. AS S U MP T ION S AN D CON S T R AIN T S
4.1 ROM Located

The Socket Services interface is intended to allow the handler to be located in ROM on a host
platform. To promote this capability, the use of RAM to store status and/or state information is
minimized.
4.2 Hardware Implementation

While the Socket Services interface has been developed to mask the details of the actual hardware
used to implement PC Card sockets, some hardware implementations do provide advantages. As
noted above, Socket Services is intended to be located in ROM. This requires that the amount of
RAM used by Socket Services is as small as possible. Using hardware registers which are
read/write, rather than write-only, allows state information to be determined by reading the
hardware and not by maintaining RAM-based copies of values previously written to write-only
registers.
Another area where hardware implementation can simplify or complicate Socket Services is status
reporting. Hardware registers that are automatically reset when read force Socket Services to keep
RAM-based copies of values read to ensure status information is not lost when read by routines not
interested in the particular status returned. On the other hand, if status registers require explicit
resets, status information is maintained until acknowledged by the appropriate software routine.
This provides a positive acknowledgment that the status condition has been noted and resolved. For
the same reason, if multiple status bits reside in the same register, they must be able to be reset on
an individual basis.
4.3 Adapters Supported

The Socket Services interface allows multiple adapters containing one or more PC Card sockets. The
actual number of adapters supported is limited by several factors. These include: the specifics of the
platform binding, the constraints imposed by locating Socket Services in ROM, and a particular
vendorÕs implementation.
Adapters are numbered from zero (0) to the maximum (one less than the number of adapters
installed as returned by GetAdapterCount).
4.4 Sockets Supported

The Socket Services interface allows multiple PC Card sockets per adapter. The maximum number
of sockets an adapter can support is primarily limited by the fact that a bit-map of assignable sockets
is returned by the InquireWindow service. As with adapters, the constraints imposed by locating
Socket Services in ROM may impose a smaller limit on the number of sockets supported. An
adapter may support any number of sockets, from one to the theoretical maximum imposed by the
number of bits in the field used to return the bit-map of assignable sockets. If a system has more
than one adapter, each adapter may support a different number of sockets.
ASSUMPTIONS AND CONSTRAINTS
Sockets are numbered from zero (0) to one less than the number on the adapter (as returned by
InquireAdapter). The maximum number of sockets that may be supported depends on the Socket
Services binding.
4.5 Windows Supported

The Socket Services interface is designed without any assumptions about how or whether PC Cards
are mapped into the hostÕs I/O or memory space. This requires a mechanism to indicate which
windows can be mapped to a particular socket. Socket Services uses a bit-map to return this
information as described in the InquireWindow and InquireBridgeWindow services.
There are two types of windows managed by Socket Services. The InquireAdapter service returns
the number of both types of windows on the adapter.
The first window type supports memory or I/O accesses to a 16-bit PC Card. Hardware on the
adapter performs initial decoding of a host system access. If this access is within the address range of
the window, the window hardware asserts the Card Enable signal to the PC Card socket. This
informs the PC Card that it needs to perform further decoding to respond to the access. 16-bit PC
Card address decoding is a combination of the adapter and PC Card hardware.
The InquireWindow service returns the characteristics of 16-bit PC Card windows. The current
configuration of these windows is returned by the GetWindow service and the window is
configured using the SetWindow service.
CardBus PC Cards do not use this first type of window. CardBus PC Cards perform all address
decoding using Base Address Registers on the card that have been programmed for a specific host
system address range.
The second type of window managed by Socket Services is used only when the PC Card adapter is a
bridge to a host system bus. Bridge windows route a range of host system memory or I/O accesses
to a PC Card socket. 16-bit PC Card address decoding is a combination of window hardware on the
adapter (as noted above) and decoding on the card. CardBus PC Card address decoding is
performed entirely by the card based on value programmed into the cardÕs Base Address
Register(s). The characteristics of a bridge window are returned by InquireBridgeWindow. The
current configuration is returned by GetBridgeWindow and a bridge window is configured using
SetBridgeWindow.
A particular implementation may choose not to provide any mapping of 16-bit PC Cards into the
host systemÕs I/O or memory space. In this case the number of windows supported by a particular
adapter should be set to zero (0).
If a hardware implementation provides a single window per socket, the InquireAdapter service
indicates the same value as the number of sockets supported by the adapter. If a hardware
implementation allows any of an adapterÕs windows to be mapped to any of its sockets, the number
of windows available should be returned. (Do not multiply the number of windows by the number
of sockets, in this case, just use the number of individual windows on the adapter.)
There is no requirement that hardware allow a window to be mapped to more than one socket.
However, the Socket Services interface does not prevent a window from being assignable to more
than one socket. It is assumed that a window is mapped to only one socket at a time. A window
may be shared between sockets if it is specifically remapped between uses by the Socket Services
client.
Higher-level software is expected to evaluate the window descriptions returned by Socket Services
to determine capabilities available. Socket Services shall fail requests that are invalid, such as
attempting to map a window to an unsupported socket. As noted above, Socket Services does not
consider it an error to map a window that has been previously mapped. Window mapping state
information must be preserved by the Socket Services client. While Socket Services does not
preserve prior state information, the client may request current state information. In this case, the
client uses the various ÔGetÕ services prior to setting new state with the various ÔSetÕ services.
Windows are numbered from zero (0) to one less than the number on the adapter (as returned by
InquireAdapter). The maximum number of windows that may be supported depends on the Socket
Services binding.
4.6 EDC Generators

Error Detection Code generators are optional. EDC generators are numbered from zero (0) to one
less than the number on the adapter (as returned by InquireAdapter). The maximum number of
EDC generators that may be supported depends on the Socket Services binding.
4.7 Power Management and Indicators

Power management and indicators may be available on a per adapter or per socket basis. To
provide a consistent interface, Socket Services provides access to these services on a socket basis. It is
expected that a hardware implementation that only provides power management and/or indicator
control at the adapter level shall provide a Socket Services handler that manages those resources for
the entire adapter based on requests to individual sockets.
Socket Services does indicate whether power management and indicator control is performed at the
adapter or socket level. However, by providing only one control point (the socket), a client of Socket
Services is not required to provide two types of controlling routines.
4.8 Calling Conventions

The Socket Services interface uses a common set of conventions for all services. They are described
below.
4.8.1 Reserved Fields

Any reserved fields or undefined bits in entry fields may be ignored by a handler implementing
this release of Socket Services. However, reserved fields and undefined bits should be reset to zero
before invoking a Socket Services service because future releases of Socket Services may define
them. Future releases will use the reset value for behavior compliant with this release of Socket
Services.
Any reserved fields or undefined bits in fields returned by Socket Services are reset to zero by
Socket Services so future releases of Socket Services will be able to notify clients in a manner
compliant with this release.
4.8.2 Register Usage

The use of registers to pass arguments and return status is specific to the binding defined for the
host platform. See the appropriate binding for register usage conventions. Please note that
conventions are guidelines used to develop the service interfaces and exceptions have been made in
specific cases.
Whenever possible the interface preserves the contents of all arguments unless they are used to
return information. For bit-mapped fields, bits within a field (or register) are numbered beginning
with zero. The location of Bit 0 in a field is binding specific.
ASSUMPTIONS AND CONSTRAINTS
4.9 Socket Services Generally Not Re-entrant

Except for the AcknowledgeInterrupt service, Socket Services is not intended to be re-entrant.
Attempting any other Socket Services service while there is a thread of execution within Socket
Services may be invalid depending on the implementation. Should a client attempt to re-enter
Socket Services for any request other than AcknowledgeInterrrupt, the request may be failed
returning BUSY.
4.10 Critical Areas and Disabled Interrupts

Socket Services handlers should strive to minimize the amount of time interrupts are disabled.
However, a Socket Services handler NEVER enables interrupts during AcknowledgeInterrupt
processing.
4.11 Request Rejection

Socket Services validates all parameters before changing any hardware. A client is assured that if a
request is rejected due to an invalid parameter, no hardware changes have been made based on the
request.
5 . PR OGR AM I N T E R F AC E
5.1 Presence Detection

The presence of Socket Services is determined by performing the GetAdapterCount request. (See
5.3.5 GetAdapterCount [BOTH].) If this service returns with a RETCODE other than SUCCESS,
the client may assume that services provided by Socket Services are not available. If it returns
SUCCESS in the status field and the ASCII characters 'SS' in the Signature field, at least one Socket
Services handler is installed.
5.2 Data Types

Socket Services uses a number of defined data types to describe arguments and return codes. Each
Socket Services binding describes how these types are defined within the binding. The data types
used to describe service parameters are listed below:
Data Type Meaning
ADAPTER Specifies a physical adapter. Ranges from zero to one less than the number of adapters present in the host
system as reported by GetAdapterCount.
BASE Describes the base address of a window used to map a PC CardÕs address space into a host system's address
space.
BCD Binary Coded Decimal value. For example, 0221H represents 2.21.
BYTE An 8-bit quantity.
COUNT Number of objects of the specified type.
DWORD A 32-bit quantity.
Double Word A 32-bit quantity, see DWORD.
EDC Specifies an Error Detection Code generator. Ranges from zero to one less than the number of EDC generators
on the adapter as reported by InquireAdapter.
FLAGS8 Bit-mapped field with up to 8 significant bits.
IRQ IRQ status or control. Includes host system IRQ level, active level (low or high) and state (enabled or disabled).
OFFSET An address in any of the PC CardÕs memory address spaces. For a 16-bit PC Card this includes both the
attribute and common memory plane. For a CardBus PC Card this includes configuration space, any of the 6
possible memory spaces and the expansion ROM.
PAGE Subdivision of a window. Ranges from zero to one less than the number of pages in a window. Windows may be
a single page of any size or multiple pages of 16 KBytes.
PTR A pointer to a location in system memory.
PWRENTRY An entry in an array of items returned by InquireAdapter. Describes a specific power level and its valid signals
(VCC, VPP1 and VPP2).
PWRINDEX Index into power management table. Ranges from zero to one less than the number of power levels in the array
of PWRENTRY items returned by InquireAdapter.
RETCODE Value returned by Socket Services when a service has been processed.
SIGNATURE Two ASCII characters ('SS') used to validate a Socket Services handler is installed.
SIZE The size of a window. Memory and I/O windows may use different units.
SKTBITS Bit-map of valid sockets to which window or EDC generator may be assigned.
SOCKET Specifies a physical socket. Ranges from zero to one less than the number of sockets on an adapter as reported
by InquireAdapter.
SPEED Encoded value representing a memory window access speed. (See the Metaformat Specification.)
PROGRAM INTERFACE
Data Type Meaning

WINDOW Specifies a physical window. Ranges from zero to one less than the number of windows on an adapter as
reported by InquireAdapter.
WORD A 16-bit quantity.
5.3 Service Descriptions

Each Socket Services service is described in detail on the following pages. The descriptions are
intended to be processor and operating system independent. Specific bindings for particular
environments are specified in appendices to this specification.
Service names are constructed from an action verb and a noun. The noun identifies the type of
object being manipulated. If the verb is Inquire the capabilities of the object are returned by the
service. If the verb is Get the current configuration of the item is returned. If the verb is Set the item
is configured by the service.
The following notation conventions are used:
Convention Meaning
bold Bold type is used for keywords. For example, the names of services, data types, structures, and macros. These
names are spelled exactly as they should appear in source programs. Defined data types are also in uppercase.
italics Italic type is used to indicate the name of an argument. The name must be replaced by an actual argument. Italics
are also used to show emphasis in text.
monospace Monospace type is used for example program code fragments.
ALL_UPPER Type in all uppercase is used to indicate a constant value with the exception that defined data types are all
uppercase and bold.
The description of each service begins with a heading that contains the service name as described
above on the left and an indicator on the right as follows:
[PC16] Service only applies to 16-bit PC Cards
[PC32] Service only applies to CardBus PC Cards
[BOTH] Service applies to both 16-bit PC Cards and CardBus PC Cards
PROGRAM INTERFACE
5.3.1 AccessConfigurationSpace [PC32]

RETCODE = AccessConfigurationSpace (Adapter, Socket, Function, Action, Location, Data)
ADAPTER Adapter;
SOCKET Socket;
BYTE Function;
FLAGS8 Action;
OFFSET Location;
FLAGS32 Data;
Provides an interface for Card Services to read and write values in CardBus configuration space.
This is used to support the Card Services AccessConfigurationRegister service as well as to allow
Card Services to allocate windows for CardBus PC Card functions by writing to the functionÕs Base
Address Registers.
Parameter I/O Description
Adapter I Specifies a physical adapter on the host system.
Socket I Specifies a physical socket on the adapter.
Function I Specifies the card function whose configuration space is to be accessed.
Action I The READ (00H) or WRITE (01H) operation to be performed.
Location I The offset into the functionÕs configuration space where the data is to be obtained or written.
This value must be aligned on a four-byte boundary.
Data I/O If Action is READ, this field returns the data read. If Action is WRITE, this field contains the
data to be written. This field always contains a DWORD value.
Return Codes
SUCCESS Operation was successful
BAD_ADAPTER Specified Adapter is invalid
BAD_ATTRIBUTE Specified Action is not READ or WRITE.
BAD_OFFSET Location is beyond the legal configuration space or is not aligned on a four byte
boundary.
BAD_SOCKET Specified Socket and/or Function is invalid
5.3.2 AcknowledgeInterrupt [BOTH]

RETCODE = AcknowledgeInterrupt (Adapter, Sockets)
ADAPTER Adapter;
SKTBITS Sockets;
The AcknowledgeInterrupt service returns information about which socket or sockets on the adapter
specified by the input parameters has experienced a change in status.
Sockets O Returns a bit-map representing the sockets which have experienced a status change, e.g.
0021H indicates sockets 0 and 5.
Return Codes
SUCCESS if Adapter is valid
BAD_ADAPTER if Adapter is invalid
Comments
A Socket Services client enables status change interrupts from adapter hardware with the
SetAdapter service. The client is responsible for installing an interrupt handler on the appropriate
vector. Specific events are masked or unmasked on a per socket basis using the SetSocket service.
When a status change occurs, the handler installed by the client receives control. For each adapter
capable of generating that interrupt, the interrupt handler makes an AcknowledgeInterrupt
request.
The AcknowledgeInterrupt request allows Socket Services to prepare the adapter hardware for
generating another interrupt if another status change occurs. Socket Services also informs the client
which socket or sockets have experienced a status change. Socket Services must preserve state
information relating to the cause of the status change interrupt if it is not preserved by the adapter
hardware. This information will later be requested with the GetStatus service.
After polling all possible adapters with the AcknowledgeInterrupt request, the clientÕs interrupt
handler prepares the host system for another status change interrupt for the adapter. Some time
later, outside of the hardware interrupt handler, the client polls Socket Services for new socket state
using GetStatus. This service returns a combination of socket and card state information.
By separating the acknowledgment of the interrupt from the retrieval of specific socket and card
status, the client may reduce the amount of RAM required to store state information. The client may
elect to recover state information only when it is able to fully process the information. In this
manner, a client only needs to evaluate complete state information for one socket at a time.
Note: Since adapters may share a status change interrupt, it is possible for this
service to be called even if no status change has occurred on the adapter
specified. In this case, Socket Services returns indicating success with all bits
in Sockets reset to zero (0).
PROGRAM INTERFACE
WA R N IN G :
AcknowledgeInterrupt takes place within the status change hardware

interrupt. Socket Services must not enable interrupts at any time during the
processing of an AnknowledgeInterrupt request.
See Also GetStatus
5.3.3 GetAccessOffsets [PC16]

RETCODE = GetAccessOffsets (Adapter, Mode, NumDesired, pBuffer, NumAvail)
ADAPTER Adapter;
BYTE Mode;
COUNT NumDesired;
PTR pBuffer;
COUNT NumAvail;
The GetAccessOffsets service fills the buffer pointed to by pBuffer with an array of offsets for low-
level, adapter-specific, optimized PC Card access routines for adapters using register-based (I/O
port) access to PC Card memory address space. Adapters which access PC Card memory address
space through windows mapped into host system memory address space do not support this service.
Mode I Specifies the processor mode. This is specific to the type of host platform. See the platform-
specific binding for additional detail.
NumDesired I Specifies the number of access offsets desired. Indirectly specifies the size of the client-
supplied buffer.
pBuffer I A pointer to a client-supplied buffer for the array of access offsets. NumDesired specifies the
number of entries that will fit in the buffer.
The offsets are specific to the type of host platform. See the platform-specific bindings for
additional details.
NumAvail O Returns the number of access offsets supported by this Socket Services handler for the
specified adapter.
Return Codes
BAD_SERVICE if request is not supported
BAD_MODE if Mode is not supported
Comments
All of these offsets are in the Socket Services code segment. All sockets on an adapter must use the
same entry points for a mode. However, these offsets may vary depending upon the mode
specified.
A client uses the returned values to create the MAT passed to MTDs which allows these routines to
be called in a manner appropriate to the mode in which they will be used.
There is no requirement that an implementation support every possible mode. If a mode is not
supported, this request should return BAD_MODE.
PROGRAM INTERFACE
Offsets for the access routines are returned in the following order:
Set Address
Set Auto Increment
Read Byte
Read Word
Read Byte with Auto Increment
Read Word with Auto Increment
Read Words
Read Words with Auto Increment
Write Byte
Write Word
Write Byte with Auto Increment
Write Word with Auto Increment
Write Words
Write Words with Auto Increment
Compare Byte
Compare Byte with Auto Increment
Compare Words
Compare Words with Auto Increment
Definitions for the arguments passed to the above access routines are binding specific. (See the Card
Services Specification.)
See Also GetSetSSAddr
5.3.4 GetAdapter [BOTH]

RETCODE = GetAdapter (Adapter, State, SCRouting)
ADAPTER Adapter;
FLAGS8 State;
IRQ SCRouting;
The GetAdapter service returns the current configuration of the specified adapter.
AdapterState O Current state of the adapter hardware. This parameter can be a combination of the following
values:
Value Meaning
AS_POWERDOWN If set, adapter hardware is attempting to conserve power. Before
using adapter, full power must be restored using the SetAdapter
service.
If reset, adapter hardware is fully powered and fully functional.
AS_MAINTAIN If set, all adapter and socket configuration information is maintained
while power consumption is reduced.
If reset, adapter and socket configuration information must be
maintained by the client.
This value is only valid if the AS_POWERDOWN value is set.
SCRouting O Returns status change interrupt routing status. This parameter is an IRQ data type. It is a
combination of a binary value representing the IRQ level used for routing the status change
signal and the following optional bit-masks:
Value Meaning
IRQ_HIGH If set, status change interrupt is active-high.
If reset, status change interrupt is active-low.
IRQ_ENABLE If set, status change interrupt is enabled. If an unmasked status
change event occurs, the adapter generates a hardware interrupt of
the specified level.
If reset, status change interrupts are not generated by the adapter.
Return Codes
Comments
Preserving state information may not allow the same level of power reduction as not preserving
state information. The ability to reduce power consumption is vendor specific and reduced power
settings may not result in any power savings.
All parameters have been designed to map directly to the values required for the SetAdapter
service. This is intended to allow clients of Socket Services to retrieve current configuration
information with this service, make changes and then use the SetAdapter service to modify the
configuration without having to create initial values for each parameter.
See Also InquireAdapter, SetAdapter
PROGRAM INTERFACE
5.3.5 GetAdapterCount [BOTH]

RETCODE = GetAdapterCount (TotalAdapters, Signature)
COUNT TotalAdapters;
SIGNATURE Signature;
The GetAdapterCount service returns the number of adapters supported by all Socket Services
handlers in the host system. It is also used to determine if one or more Socket Services handlers are
installed.
TotalAdapters O Number of adapters in host environment, if there is a Socket Services handler installed. Must
return the total number of adapters in the system, including both 16-bit PC Card-only and
CardBus PC Card adapters.
Signature O If RETCODE is set to SUCCESS and this field is set to the ASCII characters 'SS' on return,
there is at least one Socket Services handler installed and TotalAdapters is set to the number
of adapters in the host environment.
Comments
The client should ensure Signature does not contain 'SS' before calling this service. This ensures the
client does not use TotalAdapters if the routine handling the request does not support Socket Services
but still returns SUCCESS.
If a Socket Services handler is not installed, the returned parameters are undefined. Most
environments return an undefined value not equal to SUCCESS. However, an environment may
use a calling mechanism shared with another, unrelated handler. There is no guarantee the other
handler will properly reject an unrecognized Socket Services request. Before accepting the value in
TotalAdapters as the number of adapters installed, the client must confirm Signature contains the
ASCII characters 'SS'.
Even if a Socket Services handler is present, there might not be any adapter hardware present. In
this case, SUCCESS is returned, Signature contains 'SS' and TotalAdapters is zero (0). Clients must be
prepared for this situation.
Return Codes
See Also GetSSInfo
5.3.6 GetBridgeWindow [BOTH]

RETCODE = GetBridgeWindow (Adapter, Window, Socket, Size, State, Base)
ADAPTER Adapter;
WINDOW Window;
SOCKET Socket;
SIZE Size;
FLAGS8 State;
BASE Base;
The GetBridgeWindow service returns the current configuration of the bridge window specified by
the input parameters. If present on the adapter, PC Card bridge windows are required to allow
access to devices on PC Cards.
Window I Specifies a bridge window on the adapter.
Socket O Physical socket to which the bridge window is currently assigned.
Size O Returns the window's current size in bytes.
State O Defined as below. Current state of the window hardware. This parameter can be a
combination of the following values:
Value Meaning
WS_IO If set, this bridge window routes host system I/O accesses to the
PC Card socket.
If reset, this bridge window routes host system memory accesses
to the PC Card socket.
WS_ENABLED If set, the bridge window is enabled and routing host system
accesses to a PC Card socket.
If reset, the bridge window is disabled.
WS_PREFETCH If set, the bridge windowÕs prefetch hardware is enabled.
If reset, the bridge windowÕs prefetch hardware is not enabled (or
does not exist).
WS_CACHABLE If set, the bridge windowÕs cache coherency and prefetch hardware
are enabled.
If reset, the bridge windowÕs cache coherency hardware is not
enabled (or does not exist).
Note: All cachable windows are prefetchable.
Base O Returns the current base address of the specified bridge window. It is the first address within
the host system memory or I/O address space routed to the PC Card socket.
Return Codes
SUCCESS if Adapter and Window are valid
BAD_WINDOW if Window is invalid
Comments
All parameters have been designed to map directly to the values required for the
SetBridgeWindow service. This is intended to allow clients of Socket Services to retrieve current
configuration information with this service, make changes and then use the SetBridgeWindow
service to modify the configuration without having to create initial values for each parameter.
PROGRAM INTERFACE
See Also InquireBridgeWindow, SetBridgeWindow, InquireWindow, GetWindow, SetWindow,

AccessConfigSpace.
5.3.7 GetEDC [BOTH]

RETCODE = GetEDC (Adapter, EDC, Socket, State, Type)
ADAPTER Adapter;
EDC EDC;
SOCKET Socket;
FLAGS8 State;
FLAGS8 Type;
The GetEDC service returns the current configuration of the EDC generator specified by the input
parameters.
EDC I Specifies a physical EDC generator on the adapter.
Socket O Returns the physical socket on the adapter that the EDC generator is assigned.
State O Returns the current state of the EDC generator. This field may be combination of the following
values:
Value Meaning
EC_UNI If set, EDC generator is computing in only one direction.
EC_WRITE determines whether computation is on read or write
accesses.
If reset, EDC generator is computing on both read and write
accesses.
EC_WRITE If set, EDC generator is computing only on write accesses.
If reset, EDC generator is computing only on read accesses.
This value is only valid if EC_UNI is set.
Type O Returns type of EDC generated. This parameter may be one of the following values:
Value Meaning
ET_CHECK8 EDC generated is 8-bit checksum.
ET_SDLC16 EDC generated is 16-bit CRC-SDLC.
Return Codes
SUCCESS if Adapter and EDC are valid
BAD_EDC if EDC is invalid
Comments
All parameters have been designed to map directly to the values required by the SetEDC service.
This is intended to allow clients of Socket Services to retrieve current configuration information with
this service, make changes and then use SetEDC to modify the configuration without having to
create initial values for each parameter.
See Also InquireEDC, SetEDC, StartEDC, PauseEDC, ResumeEDC, StopEDC, ReadEDC
PROGRAM INTERFACE
5.3.8 GetPage [PC16]

RETCODE = GetPage (Adapter, Window, Page, State, Offset)
ADAPTER Adapter;
WINDOW Window;
PAGE Page;
FLAGS8 State;
OFFSET Offset;
The GetPage service returns the current configuration of the page specified by the input
parameters. It is only valid for memory windows (WS_IO is reset for the window).
Window I Specifies a physical window on the adapter.
Page I Specifies the page within the Window.
State O Current state of the Page within the Window. This parameter can be a combination of the
following values:
Value Meaning
PS_ATTRIBUTE If set and Page is enabled, PC Card attribute memory is mapped
into host system memory space.
If reset and Page is enabled, PC Card common memory is mapped
into host system memory space.
PS_ENABLED If set, Page is enabled and PC Card is mapped into the host system
memory or I/O space.
If reset, Page is disabled.
Some hardware implementations may not allow individual pages to
be disabled, only entire windows. Such implementations always
return with PS_ENABLED set unless the entire window is disabled.
PS_WP If set, Page is write-protected by page mapping hardware in socket.
If reset, Page is not write-protected by socketÕs page-mapping
hardware. However, PC Card memory may be write-protected in
other ways.
Offset O The offset of a PC CardÕs memory being mapped into host system memory space by this
page. The following formula may be used to calculate the system memory address to access
the PC Card memory being mapped by the page:
Base + (Page * 16 KBytes)
Return Codes
SUCCESS if Adapter, Page and Window are valid
BAD_PAGE if Page is invalid
Comments
All parameters have been designed to map directly to the values required for the SetPage service.
this service, make changes and then use the SetPage service to modify the configuration without
having to create initial values for each parameter.
All pages in windows which are subdivided into multiple pages are 16 KBytes in size. A window
with only a single page may be any size meeting the constraints returned by InquireWindow.
To map PC Card memory into system memory requires that both the WS_ENABLED value of the
State field used by Get/SetWindow be set and the PC_ENABLED value of the State field used by
Get/SetPage be set. For windows with WS_PAGED reset, the PS_ENABLED value is ignored by
SetPage. The window is enabled and disabled by the WS_ENABLED value of SetWindow. GetPage
for windows with WS_PAGED reset reports the value of WS_ENABLED for PS_ENABLED.
For windows with WS_PAGED set, WS_ENABLED acts as a global enable/disable for all pages
within the window. Once WS_ENABLED has been set using SetWindow, individual pages may be
enabled and disabled using SetPage and PS_ENABLED.
If WC_WENABLE is reported as set by InquireWindow, Socket Services preserves the state of
PS_ENABLED for each page in the window whenever WS_ENABLED is changed by SetWindow. If
WC_ENABLE is reported as reset by InquireWindow, the client must use SetPage to set the
PS_ENABLED state for each page within the window after WS_ENABLED is set with SetWindow.
See Also InquireWindow, GetWindow, SetWindow, SetPage
PROGRAM INTERFACE
5.3.9 GetSetPriorHandler [BOTH]

RETCODE = GetSetPriorHandler (Adapter, Mode, pHandler)
ADAPTER Adapter;
FLAGS8 Mode;
PTR pHandler;
The GetSetPriorHandler service replaces or obtains the entry point of a prior handler for the
Adapter specified by the input parameters.
Mode I Specifies whether the request is to Get the prior handler or Set a new handler.
If Mode is zero, the request is to Get the prior handler,
If Mode is one, the request is to Set the prior handler.
pHandler I/O If Mode is Get (equal to zero), this parameter is ignored on input and used to return the entry
point of the prior handler.
If Mode is Set (equal to one), this parameter contains a pointer to a new prior handler and is
used to return the entry point of the old prior handler.
Return Codes
BAD_SERVICE if request is to Set a prior handler for a ROM-based handler which is hard-coded
to chain to another type of handler
Comments
If the handler responding to this request is installed in ROM and is the first handler on the Socket
Services chain, a request to Set the prior handler may be failed.
One reason a Set request would fail is the Socket Services it is addressing is in ROM as the first
extension of another type of handler which is sharing the call chain. In this case, the vector to the
prior handler is probably hard-coded into the ROM and not in RAM prohibiting it from being
updated. This should not cause any difficulty to a client wishing to revise the chain, since this Socket
Services handler may be bypassed by registering the values returned from a Get request to this
Socket Services with a replacement Socket Services handler as its prior handler.
Note: The entry point of the prior handler is always returned, even on Set
requests, if the service succeeds.
WA R N IN G :
This service should only be used with the first adapter serviced by a Socket
Services handler as returned by the GetSSInfo service. If a handler services
more than one adapter, subsequent requests to the handler for adapters other
than the first return the same information and set the same internal data
variables.
WA R N IN G :
To support additional adapters and/or sockets, new Socket Services handlers

should be added to the head of the handler chain. Adjusting internal prior
handler values should be used only to replace a Socket Services handler with
an updated version.
PROGRAM INTERFACE
5.3.10 GetSetSSAddr [BOTH]

RETCODE = GetSetSSAddr (Adapter, Mode, Subfunc, NumAddData, pBuffer)
ADAPTER Adapter;
BYTE Mode;
BYTE Subfunc;
COUNT NumAddData;
PTR pBuffer;
The GetSetSSAddr service returns code and data area descriptions and provides a way to pass
mode-specific data area descriptors to a Socket Services handler.
Mode I Specifies the processor mode. This is specific to the type of host platform. See the platform-
specific binding for additional detail.
Subfunc I Specifies the type of request.
If Subfunc is zero (0), Socket Services returns a description of the code and main data areas in
the client-supplied buffer.
If Subfunc is one (1), Socket Services returns a description of any additional data areas in the
client-supplied buffer.
If Subfunc is two (2), Socket Services accepts an array of mode-specific pointers to additional
data areas in the client-supplied buffer.
If Subfunc is three (3), Socket Services returns a description of the I/O port range or ranges
used by the adapter hardware managed by Socket Services in the client supplied buffer.
If Subfunc is four (4), Socket Services returns in the client supplied buffer a description of the
main data area and the code area and entry point that utilizes the packet interface
NumAddData I/O Number of additional data areas.
If Subfunc is zero (0), Socket Services returns the number of additional data areas in this
parameter.
If Subfunc is one (1), the client-supplied buffer returns this number of descriptors for additional
data areas.
If Subfunc is two (2), Socket Services accepts this number of mode-specific pointers to
additional data areas in the client-supplied buffer.
If Subfunc is three (3), the NumAddData field returns the number of I/O address ranges in this
parameter.
If Subfunc is four (4), this field is reserved and must be reset to zero (0).
pBuffer I/O A pointer to a client-supplied buffer of the appropriate length for the request.
If Subfunc is zero (0), Socket Services returns a description of the code and main data
segment in the buffer.
If Subfunc is one (1), Socket Services returns a description of the additional data areas in the
client-supplied buffer.
If Subfunc is two (2), the client-supplied buffer contains mode-specific pointers to additional
data areas as input to Socket Services.
If Subfunc is three (3), the client supplied buffer contains a list of I/O address ranges that are
used to control the sockets for this adapter.
If Subfunc is four (4), Socket Services returns in the buffer a mode-specific entry point that
utilizes the packet interface.
Comments
Some Socket Services handlers may require access to other memory regions than their main data
area. If this is the case, the value in NumAddData reflects the number of unique memory regions the
Socket Services handler needs to address besides the main data segment.
A Card Services using an entry point returned by this service is expected to establish the
appropriate mode-specific pointers to the code and main data area prior to calling the entry point.
When using the entry point returned by this service, the client uses the absolute adapter number
within the host environment. For example, if two Socket Services handlers are installed, with the
first handler supporting two adapters and the second handler supporting three adapters, the client
should use adapter values of zero through one for the first handler and values of two through four
for the second handler.
When Subfunc is zero (0), the buffer pointed to by pBuffer has the following format:
Offset Size Description
00H Double Word 32-bit linear base address of code segment in system memory
04H Double Word Limit of code segment
08H Double Word Entry point offset
0CH Double Word 32-bit linear base address of main data segment in system memory
10H Double Word Limit of data segment
14H Double Word Data area offset
When Subfunc is one (1), there are entries in the client-supplied buffer pointed to by pBuffer
returned for each of the additional data segments. Each entry in the buffer has the following format:
00H Double Word 32-bit linear base address of additional data segment
When Subfunc is two (2), there are entries in the client-supplied buffer pointed to by pBuffer for
each additional data area. These entries are mode-specific pointers created by the client for each
additional data area. Each entry in the buffer has the following format:
00H Double Word 32-bit offset
04H Double Word Selector
08H Double Word Reserved
When Subfunc is three (3), there are entries in the client-supplied buffer pointed to by pBuffer for
each additional data area. Each entry in the buffer has the following format:
00H Double Word 32-bit I/O base address for control ports
04H Double Word Number of I/O ports consumed for this entry
When Subfunc is four (4), the buffer pointed to by pBuffer has the following format:
04H Double Word Limit of code segment
08H Double Word Entry point offset (entry point that utilizes the stack-packet interface)
0CH Double Word 32-bit linear base address of main data segment in system memory
PROGRAM INTERFACE
WA R N IN G :
This service should only be used with the first adapter serviced by a Socket
Services handler as returned by the GetSSInfo service. If a handler services
more than one adapter, subsequent requests to the handler for adapters other
than the first return the same information and set the same internal data
variables.
Return Codes
SUCCESS if Adapter, Mode, and Subfunc are valid
BAD_SERVICE if request is not supported
BAD_ATTRIBUTES if number of additional data segments specified when Subfunc is one (1) or two (2)
does not equal the number of additional data segments returned when Subfunc is
zero (0)
See Also GetAccessOffsets
5.3.11 GetSocket [BOTH]

RETCODE = GetSocket (Adapter, Socket, SCIntMask, Vcontrol, VccLevel, VppLevels, State,
CtlInd, IREQRouting, IFType, IFIndex)
ADAPTER Adapter;
SOCKET Socket;
FLAGS8 SCIntMask;
PWRINDEX Vcontrol;
PWRINDEX VccLevel;
PWRINDEX VppLevels;
FLAGS8 State;
FLAGS8 CtlInd;
IRQ IREQRouting;
FLAGS8 IFType;
WORD IFIndex;
The GetSocket service returns the current configuration of the socket identified by the input
parameters.
SCIntMask O Returns current setting of mask for events that generate a status change interrupt when they
occur on the socket. If a value is set the event generates a status change interrupt if the
following conditions are met: The event is supported as indicated by the SCIntCaps parameter
of InquireSocket and status change interrupts have been enabled by SetAdapter.
This parameter is a combination of the SBM_x values defined in InquireSocket.
Vcontrol O This parameter takes on the following values:
Value Meaning
VCTL_CISREAD If reset, the VCC level and VPP[2::1] levels are controlled by the
VccLevel and VppLevels fields.
If set, the VCC level and VPP[2::1] levels are set to the value
indicated by the voltage sense signaling from the PC Card.
VCTL_OVERRIDE If reset, the VCC level matches the value indicated by the voltage
sense signaling from the PC Card.
If set, the VCC level does not match the value indicated by the
voltage sense signaling from the PC Card.
Note: The VCTL_CISREAD and VCTL_OVERRIDE bits are mutually exclusive. In
addition, Socket Services will reset these bits upon card removal.
The following values are mutually exclusive and are only valid when a PC Card is inserted in
the socket. They may be read before the socket is powered. They indicate the voltage sense
value the PC Card is signaling (VS[2::1] signals, see the Electrical Specification) for
reading the Card Information Structure (CIS):
VCTL_50V Use 5.0 V to read the CIS.
VCTL_33V Use 3.3 V to read the CIS.
VCTL_XXV Use X.X V to read the CIS.
Note: When initially powering a PC Card with SetSocket, if the VCTL_CISREAD value is
set, the PC Card is powered to the value indicated by the voltage sense signaling
from the card.
PROGRAM INTERFACE
VccLevel O Returns current power level of VCC signal. This is an index into the array of PWRENTRY
items returned by InquireAdapter. Valid values range from zero to one less than the number
of levels returned by InquireAdapter.
VppLevels O Returns current power level of VPP[2::1] signals. This is two indices into the array of
PWRENTRY items returned by InquireAdapter. Separate values are returned in this
parameter for the VPP1 and VPP2 signals. Valid values range from zero to one less than the
number of levels returned by InquireAdapter.
Note: The VccLevel and VppLevels always return the actual levels currently applied to the
card.
State O Returns latched values representing state changes experienced by the socket hardware. Only
those values set in the InquireSocket SCRptCaps parameter will ever be set. Once set,
values must be explicitly reset using SetSocket.
This parameter is a combination of the SBM_x values defined in InquireSocket for the
SCIntCaps and SCRptCaps parameters.
CtlInd O Returns current setting of socket controls and indicators. If a value is set, the corresponding
control or indicator is on. If a value is reset, the corresponding control or indicator is off. Values
supported by the socket are defined by the CtlIndCaps parameter returned by InquireSocket.
CtlIndCaps parameter.
IREQRouting O Returns PC Card IREQ# routing status. This parameter is an IRQ data type. It is a
combination of a binary value representing the IRQ level used for routing the PC Card IREQ#
signal and the following optional values:
Value Meaning
IRQ_HIGH If set, the PC Card IREQ# signal is inverted.
If reset, the PC Card IREQ# signal is routed without inversion.
IRQ_ENABLE If set, IREQ# routing is enabled.
If reset, IREQ# routing is not enabled and interrupts from a PC
Card in the socket are ignored.
IFType O Returns the current interface and DMA settings. Only one of the following interface settings is
valid at a time: IF_IO, IF_MEMORY, IF_CARDBUS, or IF_CUSTOM. The DREQ and DMA
Channel values are only valid if the interface is set to IF_IO and the socket supports DMA as
indicated by the IF_DMA value returned by InquireSocket.
Value Meaning
IF_MEMORY Socket interface is set to Memory-Only. (See the Electrical
Specification.)
IF_IO Socket interface is set to I/O and Memory interface. (See the
Electrical Specification.)
IF_CARDBUS Socket interface is set to CardBus PC Card mode, i.e. the card
inserted in the socket is a CardBus PC Card. (See the Electrical
Specification.)
IF_CUSTOM Socket interface is set to a custom interface. The index of the
current custom interface is returned in IFIndex. (See the Electrical
Specification and see also the Metaformat Specification.)
DREQ Binary value describing the PC Card signal used for DREQ#. If
reset to zero, a DMA channel is not currently assigned to this
socket.
If set to one (1), DREQ# is assigned to the SPKR# pin.
If set to two (2), DREQ# is assigned to the IOIS16# pin.
If set to three (3), DREQ# is assigned to the INPACK# pin.
DMA Channel Binary value of the DMA channel currently assigned to this socket.
If DREQ is reset to zero, this value is undefined and should be
ignored.
IFIndex O Returns the current Custom Interface setting when IFType is set to IF_CUSTOM. This is an
index into the array of dCustomIF items returned by InquireSocket. Valid values range from
zero to one less than the number of interface numbers returned by InquireSocket.
Return Codes
SUCCESS if Adapter and Socket are valid
BAD_SOCKET if Socket is invalid
Comments
All parameters have been designed to map directly to the values required by the SetSocket service.
this service, make changes and then use SetSocket to modify the configuration without having to
See Also InquireSocket, SetSocket
PROGRAM INTERFACE
5.3.12 GetSSInfo [BOTH]

RETCODE = GetSSInfo (Adapter, Compliance, NumAdapters, FirstAdapter)
ADAPTER Adapter;
BCD Compliance;
COUNT NumAdapters;
ADAPTER FirstAdapter;
The GetSSInfo service returns the compliance level of the Socket Services interface supporting the
adapter specified by the input parameters and identifies the adapters serviced by the handler.
Each adapter may be handled by a different Socket Services handler. This argument identifies
a specific Socket Services handler. If a Socket Services handler supports more than one
adapter, the same information is returned for any adapter the handler supports.
Compliance O Returns the Socket Services Interface Specification compliance level as a Binary Coded
Decimal (BCD) value. If the handler is compliant with Release 12.98 of the PC Card Socket
Services specification, 1298H is returned.
Publication Compliance
PC Card Standard, February 1999 (Release 7.0) 0700H (7.00)
PC Card Standard, April 1998 (Release 6.1) 0610H (6.10)
PC Card Standard, March 1997 (Release 6.0) 0600H (6.00)
PC Card Standard, February 1995 (Release 5.0) 0500H (5.00)
PCMCIA 2.1 / JEIDA 4.2 0210H (2.10)
PCMCIA 2.0 / JEIDA 4.1 0200H (2.00)
PCMCIA 1.0 / JEIDA 4.0 0100H (1.00)
NumAdapters O Returns the number of adapters supported by this specific Socket Services handler.
FirstAdapter O Returns the first adapter number supported by this specific Socket Services handler. The first
Socket Services handler installed always returns zero (0) to indicate it supports the first
adapter in the system.
Return Codes
Example
If a host system had five adapters, two Socket Services handlers and the first handler supported
three (3) adapters, this request returns with FirstAdapter equal to zero (0) and NumAdapters equal to
three (3), for Adapter values of zero, one or two (0, 1 or 2). If this request was made with Adapter set
to three or four (3 or 4), it would return with FirstAdapter set to three (3) and NumAdapters set to two
(2).
See Also GetAdapterCount
5.3.13 GetStatus [BOTH]

RETCODE = GetStatus (Adapter, Socket, CardState, SocketState, CtlInd, IREQRouting, IFType)
ADAPTER Adapter;
SOCKET Socket;
FLAGS8 CardState;
FLAGS8 SocketState;
FLAGS8 CtlInd;
IRQ IREQRouting;
FLAGS8 IFType;
The GetStatus service returns the current status of the card, socket, controls and indicators for the
socket identified by the input parameters.
CardState O Returns instantaneous state. This parameter represents the current state of the socket and PC
Card, if inserted. It is a combination of the SBM_x values defined in InquireSocket for the
SBM_LOCKED, SBM_EJECT and SBM_INSERT are vendor specific and may not be
supported. See InquireSocket SCRptCaps.
For 16-bit PC Cards, SBM_WP is the output of WP (pin 33). SBM_BVD1 is the output of
BVD1 (pin 63). SBM_BVD2 the output of BVD2 (pin 62). SBM_RDYBSY is the output of
READY (pin 16) and SBM_CD is the AND-ed value of the CD1# (pin 36) and CD2# (pin 67)
outputs. Note that these bits are set when the defined states are true. This is the inverted output
of BVD1, BVD2 and the Card Detect signals.
If the interface is set to I/O and Memory mode, the meaning of many of these signals change.
Values reported are always based on the signal levels at the socket. If the IFType is IF_IO, this
service does NOT read status from the Pin Replacement Register. This is the responsibility of
the client.
For CardBus PC Cards, the state of the card is read from the Function Present State register
resident on the card. This register shows the current value for such states as SBM_BVD1.
SocketState O Returns same latched information as State parameter of GetSocket.
CtlInd O Returns same information as CtlInd parameter of GetSocket, the current setting of socket
controls and indicators. If a value is set, the corresponding control or indicator is on. If a value
is reset, the corresponding control or indicator is off. Values supported by the socket are
defined by the CtlIndCaps parameter returned by InquireSocket.
IREQRouting O Returns same information as IREQRouting parameter of GetSocket.
IFType O Returns the same information as IFType parameter of GetSocket.
Return Codes
PROGRAM INTERFACE
WA R N IN G
This service must NOT be invoked during hardware interrupt processing. It

is intended to be used by a client during foreground and background
processing, but outside of the status change hardware interrupt handler.
See Also InquireSocket, GetSocket, SetSocket
5.3.14 GetVendorInfo [BOTH]

RETCODE = GetVendorInfo (Adapter, Type, pBuffer, Release)
ADAPTER Adapter;
BYTE Type;
PTR pBuffer;
BCD Release;
The GetVendorInfo service returns information about the vendor implementing Socket Services for
the adapter specified in the input parameters.
Type I Specifies the type of vendor information to return in the client-supplied buffer. The only Type
currently defined is zero (0) which is an ASCIIZ string describing the implementer.
pBuffer I If Type is zero (0), this parameter points to a client-supplied buffer to be filled with an ASCIIZ
string describing the implementer. The buffer has the following form:
typedef struct tagVISTRUCT {
WORD wBufferLength = (BUF_SIZE - 4);
WORD wDataLength;
char szImplementor[BUF_SIZE - 4];
} VISTRUCT;
The wBufferLength field is set by the client to the length of the VISTRUCT structure
provided less the size of the first two fields (4 bytes). The wDataLength field is set by Socket
Services to the size of the information it has to return. Only the information that fits in the buffer
is copied. If the wDataLength is greater than wBufferLength, the information is truncated.
Release O VendorÕs release number in BCD format. Each time a vendor releases a new version of their
Socket Services handler, they should change the value returned. The initial Release should
use the value 0100H to represent Release 1.00 of a vendorÕs Socket Services handler. A
subsequent release of an updated version compliant with the same level of the Socket
Services Interface Specification should change this value according to the vendorÕs change
control procedures.
The first release of an Socket Services handler compliant with a new specification should
again use 0100H to indicate this is the vendorÕs first release compliant with the new Socket
Services specification. Each Socket Services released by a vendor must be uniquely identified
by the combination of the compliance level returned by the Compliance parameter of
GetSSInfo and this parameter.
Return Codes
SUCCESS if Adapter and Type are valid
BAD_SERVICE if Type is invalid
PROGRAM INTERFACE
5.3.15 GetWindow [PC16]

RETCODE = GetWindow (Adapter, Window, Socket, Size, State, Speed, Base)
ADAPTER Adapter;
WINDOW Window;
SOCKET Socket;
SIZE Size;
FLAGS8 State;
SPEED Speed;
BASE Base;
The GetWindow service returns the current configuration of the window specified by the input
parameters.
Window I Window number. Specifies a physical window on the adapter.
Socket O Returns the physical socket the Window is currently assigned. Socket numbers range from
zero to fifteen using bits 0 to 3. The rest of the bits in this field are binding specific.
Size O Returns the windowÕs current size. If Size is equal to zero (0), the window is the maximum
size that may be represented by the data type used for this parameter plus one. For example, if
the data type used for Size is a word and it is expressed in units of a byte, a value of zero
represents a window size of 65,536 bytes.
State O Defined as below. Current state of the window hardware. This parameter can be a
Value Meaning
WS_IO If set, window maps registers on a 16-bit PC Card into the host
system's I/O address space.
If reset, window maps memory address space on a 16-bit PC Card
into the host system's memory address space.
WS_ENABLED If set, window is enabled and mapping a cardÕs address space into
the host system memory or I/O address space.
If reset, window is disabled.
WS_16BIT If set, window is programmed for a 16-bit data bus width.
If reset, window is programmed for an 8-bit data bus width.
WS_PAGED If set, window is subdivided into multiple 16 KByte pages whose
card offset addresses may be set individually using SetPage.
If reset, window is a single page.
This value is only valid for memory windows (WS_IO reset).
WS_EISA If set, window is using EISA I/O mapping.
If reset, window is using ISA I/O mapping.
This value is only valid for I/O windows (WS_IO set).
WS_CENABLE If set, accesses to I/O ports in EISA common I/O areas generate
card enables.
If reset, accesses to I/O ports in EISA common I/O areas are
ignored.
This value is only valid for I/O windows (WS_IO set) that have
WS_EISA set.
Speed O This parameter is the actual access speed being used by the window. It uses the format of the
Device Speed Code and Extended Device Speed Codes of the Device Information Tuple. (See
the Metaformat Specification.)
The Device Speed Code Values are used when what would be the mantissa of an Extended
Device Speed Code is reset to zero (0). If the mantissa is non-zero, supported device speeds
are coded according to the Extended Device Speed Code.
This parameter may not match the value specified by a successful SetWindow request. If
Socket Services does not support the speed requested, it uses the next slowest speed it
supports.
For Socket Services, Bit 7 of Speed is reserved and is reset to zero (0).
This parameter is not used and should be ignored for I/O windows (WS_IO set).
Base O Returns the current base address of the specified window. It is the first address within the host
system memory or I/O address space to which the window responds.
Return Codes
Comments
All parameters have been designed to map directly to the values required for the SetWindow
information with this service, make changes and then use the SetWindow service to modify the
For memory mapping windows, the area of the PC Card memory array mapped into the host
system memory space may be managed by GetPage and SetPage requests.
To map 16-bit PC Card memory into system memory requires that both the WS_ENABLED value of
the State field used by Get/SetWindow be set and the PS_ENABLED value of the State field used by
See Also InquireWindow, SetWindow, GetPage, SetPage, InquireBridgeWindow,

GetBridgeWindow, SetBridgeWindow
PROGRAM INTERFACE
5.3.16 InquireAdapter [BOTH]

RETCODE = InquireAdapter (Adapter, pBuffer, NumSockets, NumWindows, NumEDCs,
NumBridgeWindows)
ADAPTER Adapter;
PTR pBuffer;
COUNT NumSockets;
COUNT NumWindows;
COUNT NumEDCs;
COUNT NumBridgeWindows;
The InquireAdapter service returns information about the capabilities of the adapter specified by
the input parameters.
pBuffer I Points to a client-supplied buffer to be filled with information about the adapter. The buffer has
the following form:
typedef struct tagAISTRUCT {
WORD wBufferLength;
WORD wDataLength;
ACHARTBL CharTable;
WORD wNumPwrEntries = NUM_ENTRIES;
PWRENTRY PwrEntry[NUM_ENTRIES];
} AISTRUCT;
The wBufferLength field is set by the client to the size in bytes of AISTRUCT less the size of
the first two fields (4 bytes). The wDataLength field is set by Socket Services to the size of the
information it has to return. Only the information that fits in the buffer is copied. If the
wDataLength is greater than wBufferLength, the information is truncated.
The ACHARTBL structure is defined on page 46.
A PWRENTRY is a structure which has two members. One member is a binary value
representing a DC voltage level in tenth of a volt increments (25.5 V DC maximum). The other
member indicates which power signals may be set to the specified voltage level. It may be set
to a combination of the following: VCC, VPP1, and/or VPP2.
A PWRENTRY is a structure which has two members. One member is a binary value
representing a DC voltage level in tenth of a volt increments (25.5 V DC maximum). The other
member indicates which power signals may be set to the specified voltage level. It may be set
to a combination of the following: VCC, VPP1, and/or VPP2.
The PWRENTRY structure is defined on page 47.
NumSockets O Returns the number of sockets provided by the adapter.
NumWindows O Returns the number of 16-bit PC Card windows provided by the adapter.
NumEDCs O Returns the number of Error Detection Code (EDC) generators provided by the adapter.
NumBridgeWindows O Returns the number of bridge windows provided by the adapter.
Return Codes
Comments
By convention, all sockets on an adapter use the same PWRENTRY array. There is one PWRENTRY
for each supported voltage.
The PWRENTRY only indicates it is possible to set one or more of the power pins to that power
level. The PWRENTRY does not indicate acceptable power combinations for the power pins. The
example below indicates VCC, VPP1 and VPP2 can be set to No Connect and that VPP1 and VPP2
can be set to 12 V. This table does not define any relationships between VPP1, VPP2, and VCC; for
example, implementations may fail requests to set VCC to 0 V and either VPP1 or VPP2 to 12 V. . It
is up to the Socket Services client to determine if a particular combination of power levels is valid for
the PC Card in the socket.
Example
AISTRUCT AdapterInfo = {
18, //Size of client-supplied buffer is 18 bytes
18, //Size of data returned is 18 bytes
{0, //Indicators, power and data bus width
//controlled at the socket
0, //No cache support on adapter
0xDEB8, //Status changes may be routed to IRQ levels
// 3, 4, 5, 7, 9, 10, 11, 12, 14, and 15
// as an active high signal
0}, //Status changes are not available on any
// level as an active low signal
3, //Number of PWRENTRY elements
((VCC | VPP1 | VPP2) << 8) | 0, // Vcc, Vpp1 and Vpp2 - No connect
((VCC | VPP1 | VPP2) << 8) | 50, // Vcc, Vpp1 and Vpp2 - 5.0 VDC
((VPP1 | VPP2) << 8) | 120 // Vpp1 and Vpp2 - 12.0 VDC
};
See Also GetAdapter, SetAdapter
PROGRAM INTERFACE
Adapter Characteristics Structure

typedef struct tagACHARTBL {
FLAGS8 AdpCaps;
BYTE CacheLineSize;
FLAGS32 ActiveHigh;
FLAGS32 ActiveLow;
} ACHARTBL;
Member Description
AdpCaps Flags indicating whether certain characteristics are controlled at an adapter level or at a socket level. If
set, the characteristic is controlled at the adapter level. This member can be a combination of the
following values:
Value Meaning
AC_IND Indicators - If AC_IND is set, indicators for write-protect, card lock, battery
status, busy status and XIP status are shared for all sockets on the adapter.
If AC_IND is reset, there are individual indicators for each socket on the
adapter.
AC_PWR Power Level - If AC_PWR is set, even though the interface provides for
separate power level controls for each socket using the SetSocket service,
the adapter requires that all sockets be set to the same value.
Socket Services is responsible for resolving conflicts between settings for
individual sockets. When the AC_PWR flag is set, setting VPP[2::1] to 12 V
results in 12 V being applied to all of the sockets on the adapter. Socket
Services does not remove 12 V from the VPP[2::1] lines until all sockets set
VPP[2::1] back to the VCC level.
If AC_PWR is reset, power levels may be individually set for each socket on
the adapter.
AC_DBW Data Bus Width - If AC_DBW is set, all windows on the adapter must use the
same data bus width.
If AC_DBW is reset, the data bus width is set individually for each window on
the adapter.
AC_CARDBUS CardBus PC Card capable. If set, all sockets are CardBus PC Card-capable.
If reset, then all sockets are not CardBus PC Card-capable.
CacheLineSize Host system cache line size in units of 32-bit words. CardBus PC Cards participating in caching protocol
need this information to know when to retry burst accesses at cache line boundaries. If bridge windows
on the adapter do not support caching or there are no bridge windows on the adapter, this field is reset to
zero. This field is also reset to zero if the adapter does not support CardBus PC Cards.
ActiveHigh Bit-map of IRQ levels the Status Change interrupt may be routed with an active high state when an
unmasked event occurs.
ActiveLow Bit-map of IRQ levels the Status Change interrupt may be routed with an active low state when an
unmasked event occurs.
Power Entry Structure

typedef struct tagPWRENTRY {
PWRINDEX PowerLevel;
FLAGS8 ValidSignals;
} PWRENTRY;
Member Description
PowerLevel DC voltage level in tenth of a volt increments. The power level ranges from zero (meaning No Connect)
to 25.5 V DC in tenth of a volt increments.
ValidSignals Flags indicating whether voltage is valid for specific signals. This member can be a combination of the
following values:
Value Meaning
VCC Voltage level is valid for VCC signal.
VPP1 Voltage level is valid for VPP1 signal.
VPP2 Voltage level is valid for VPP2 signal.
PROGRAM INTERFACE
5.3.17 InquireBridgeWindow [BOTH]

RETCODE = InquireBridgeWindow (Adapter, Window, pBuffer, WndCaps, Sockets)
ADAPTER Adapter;
WINDOW Window;
PTR pBuffer;
FLAGS8 WndCaps;
SKTBITS Sockets;
The InquireBridgeWindow service returns information about the capabilities of the bridge window
specified by the input parameters.
pBuffer I Points to a client-supplied buffer to be filled with information about the bridge window. The
buffer has the following form:
typedef struct tagBWISTRUCT {
WORD wBufferLength;
WORD wDataLength;
BWINTBL WinTable[NUM_TYPES];
} BWISTRUCT;
The wBufferLength field is set by the client to the size in bytes of BWISTRUCT less the size of
A bridge window may support either I/O or memory accesses. Each window type has
associated characteristics described in tables returned in the client-supplied buffer.
Bridge window characteristics vary if the hardware is used as a memory or as an I/O window.
For that reason, this service provides two tables of information. The BMEMWINTBL
structure is defined on page 50. The BIOWINTBL structure is defined on page 52.
If a bridge window supports both memory and I/O access, both characteristics tables are
copied to the client-supplied buffer. When a bridge window supports both types of access, the
memory window characteristics table is first in the buffer, followed by the I/O window
characteristics table. If only one type of access is supported, only the appropriate
characteristics table is copied into the buffer by Socket Services.
WndCaps O This parameter indicates the capability of the specified window. It can be a combination of the
following values:
Value Meaning
WC_IO If set, bridge window may be used to route host system I/O
WC_MEMORY If set, bridge window may be used to route host system memory
Sockets O Depending on the hardware implementation, bridge windows may be dedicated to a particular
socket or may allow assignment to a given socket on an adapter.
If a bridge window may be assigned to a socket on the adapter, the corresponding bit in this
parameter is set. If a socket does not exist on an adapter its corresponding bit is reset.
The first socket on the adapter is represented by the least significant bit of this parameter.
Note: The size of this field constrains the number of sockets that may be supported by an
adapter.
Return Codes:
See Also GetBridgeWindow, SetBridgeWindow, InquireWindow, GetWindow, SetWindow,

AccessConfigSpace.
PROGRAM INTERFACE
Bridge Memory Window Characteristics Table

typedef struct tagBMEMWINTBL {
FLAGS16 MemWndCaps;
BASE FirstByte;
BASE LastByte;
SIZE MinSize;
SIZE MaxSize;
SIZE ReqGran;
SIZE ReqBase;
} BMEMWINTBL;
Member Description
MemWndCaps Flags indicating memory bridge window characteristics. This member can be a combination of the
following values.
Value Meaning
WC_BASE If set, the base address of the bridge window is programmable within the
range specified by the FirstByte and LastByte members.
If reset, the base address of the bridge window is fixed in system memory
space at the address specified in the FirstByte member. When reset, the
LastByte member is undefined.
WC_SIZE If set, the bridge window size is programmable within the range specified by
the MinSize and MaxSize members.
If reset, the bridge window size is fixed to the size indicated by the MinSize
member. When reset, both the MinSize and MaxSize members should be the
same value.
WC_WENABLE If set, the window may be disabled and enabled without reprogramming its
characteristics.
If reset, the client must preserve window state information before disabling the
window.
WC_BALIGN If set, the bridge window base address must be programmed to align with a
multiple of the bridge window size. For example, a bridge window 16 MBytes
in size needs to start on a 16 MByte boundary in the host system memory
address space.
If reset, the bridge window base address may be programmed anywhere in
the bridge window's valid range, subject to any constraint specified by
ReqBase.
WC_POW2 If set, a bridge window with WC_SIZE also set must be sized between the
MinSize and MaxSize members as a power of two of the ReqGran member.
If reset, a bridge window with WC_SIZE set may be any multiple of the
ReqGran member between the MinSize and MaxSize members.
WC_FETCHABLE If set, this bridge window supports prefetching CardBus PC Card memory.
If reset, this bridge window does not support prefetching CardBus PC Card
memory.
WC_CACHABLE If set, this bridge window supports caching CardBus PC Card memory.
If reset, this bridge windows does not support caching CardBus PC Card
memory.
FirstByte First byte addressable in host system memory address space by bridge window. If bridge window base
is not programmable, this is the fixed base address of the bridge window.
LastByte Last byte addressable in host system memory address space by bridge window. The last byte of the
bridge window (base address programmed plus bridge window size minus one) may not exceed this
value.
If bridge window base is not programmable, this member is undefined.
MinSize The minimum bridge window size. When a bridge window size is programmed with SetBridgeWindow
it must lie in the range of the MinSize and MaxSize members and meet all granularity and base
requirements.
MaxSize The maximum bridge window size. When bridge window size is programmed with SetBridgeWindow
requirements.
The bridge window size may be further limited by the base address of the bridge window. The base
address plus the bridge window size minus one must not exceed the LastByte member for bridge
windows with programmable sizes.
If MaxSize is zero, bridge window size is the largest value that may be represented by the SIZE data type
plus one.
ReqGran This member describes the required units for expressing bridge window size due to hardware
constraints. If the bridge window size is fixed (WC_SIZE is reset), this member will be the same as the
MinSize and MaxSize members.
ReqBase If WC_BALIGN is reset, this member describes any alignment boundary requirement for programming
the bridge window's base address with SetBridgeWindow.
If WC_BALIGN is set, this field is undefined.
Comments
Memory bridge windows are used to route host system memory accesses to a PC Card. Not all
adapters have bridge windows. For those that do, both a bridge window and the hardware used to
map PC Card memory address space into the host system must be enabled at overlapping
addresses. For 16-bit PC Cards, a mapping window on the adapter and one or more pages within
the window must be enabled. For CardBus PC Cards, a Base Address Register on the card must be
programmed. A single bridge window assigned to a socket may be used with multiple mapping
windows or Base Address Registers.
For CardBus PC Cards, a given bridge window may be capable of both prefetchable and cacheable
memory accesses. However, only one of these capabilities may be enabled at a time. The
characteristics of the PC Card memory accessed by programming a Base Address Register on the
card must match the bridge windowÕs characteristics.
PROGRAM INTERFACE
Bridge I/O Window Characteristics Table

typedef struct tagBIOWINTBL {
FLAGS16 IOWndCaps;
BASE FirstByte;
BASE LastByte;
SIZE MinSize;
SIZE MaxSize;
SIZE ReqGran;
} BIOWINTBL;
Member Description
IOWndCaps Flags indicating I/O bridge window characteristics. This member can be a combination of the following
values:
Value Meaning
WC_BASE If set, the base address of the bridge window is programmable within the
range specified by the FirstByte and LastByte members.
If reset, the base address of the bridge window is fixed in system I/O address
space at the address specified in the FirstByte member. When WC_BASE is
reset, the LastByte member is undefined.
WC_SIZE If set, the bridge window size is programmable within the range specified by
the MinSize and MaxSize members.
If reset, the bridge window size is fixed to the size indicated by the MinSize
member. When WC_SIZE is reset, both the MinSize and MaxSize members
shall be the same value.
WC_WENABLE If set, the bridge window may be disabled and enabled without reprogramming
its characteristics.
If reset, the client must preserve bridge window state information before
disabling the window.
WC_POW2 If set, a bridge window with WC_SIZE set must be sized between the MinSize
and MaxSize members as a power of two of the ReqGran member.
If reset, a bridge window with WC_SIZE set may be any multiple of the
ReqGran member between the MinSize and MaxSize members.
FirstByte First byte addressable in host system I/O address space by the bridge window. If the bridge window base
is not programmable, this is the fixed base address of the bridge window.
LastByte Last byte addressable in host system I/O address space by the bridge window. The last byte of the bridge
window (base address programmed plus window size minus one) may not exceed this value.
If the bridge window base is not programmable, this member is undefined.
If LastByte is expressed in units other than bytes, any address bits of lesser significance not directly
expressed are assumed to be set to one (1). For example, if LastByte is expressed in 4 KByte units, a
value of A3H indicates the last addressable byte within the window is at location A3FFFH in the host
systemÕs I/O address space.
MinSize The minimum bridge window size. When bridge window size is programmed with SetBridgeWindow it
must lie in the range of the MinSize and MaxSize members and meet all granularity and base
requirements.
MaxSize The maximum bridge window size. When bridge window size is programmed with SetBridgeWindow
requirements.
The bridge window size may be further limited by the base address of the bridge window. The base
address plus the bridge window size minus one must not exceed the LastByte member for bridge
windows with programmable sizes.
If MaxSize is zero, bridge window size is the largest value that may be represented by the SIZE data type
plus one.
ReqGran This member describes the required units for expressing bridge window size due to hardware
constraints. If the bridge window size is fixed (WC_SIZE is reset), this member will be the same as the
I/O bridge windows are used to provide access to the host system I/O address space for PC Card
windows. Not all adapters have bridge windows. For those that do, both a bridge window and the
hardware used to map PC Card I/O address space into the host system must be enabled at
overlapping addresses.
PROGRAM INTERFACE
5.3.18 InquireEDC [BOTH]

RETCODE = InquireEDC (Adapter, EDC, Sockets, Caps, Types)
ADAPTER Adapter;
EDC EDC;
SKTBITS Sockets;
FLAGS8 Caps;
FLAGS8 Types;
The InquireEDC service returns the capabilities of the EDC generator specified by the input
parameters.
Sockets O A bit-map of the sockets the EDC generator may be assigned.
Caps O Returns the capabilities of the EDC generator. This field may be combination of the following
values:
Value Meaning
EC_UNI If set, EDC generator supports unidirectional code generation.
If reset, EDC generator does not support unidirectional code
generation.
EC_BI If set, EDC generator supports bi-directional code generation.
If reset, EDC generator does not support bi-directional code
generation.
EC_REGISTER If set, EDC generation is supported through register-based access.
If reset, EDC generation is not supported through register-based
access.
EC_MEMORY If set, EDC generation is supported during window access.
If reset, EDC generation is not supported during window access.
EC_PAUSABLE If set, EDC generation can be paused.
If reset, EDC generation cannot be paused.
This value is set if the EDC generator may be paused during
computation. This allows algorithms which require multiple
accesses to a single location on a card from computing an
erroneous EDC value.
If this value is not set, the PauseEDC and ResumeEDC services
are not available.
Types O Returns types of EDC generation supported. This parameter may be a combination of the
following values:
Value Meaning
ET_CHECK8 If set, EDC generator supports 8-bit checksum code generation.
If reset, EDC generator does not support 8-bit checksum code
generation.
ET_SDLC16 If set, EDC generator supports 16-bit CRC-SDLC code generation.
If reset, EDC generator does not support 16-bit CRC-SDLC code
generation.
ET_SDLC32 If set, EDC generator supports 32-bit CRC-SDLC code generation.
If reset, EDC generator does not support 32-bit CRC-SDLC code
generation.
Return Codes
Comments
A hardware implementation may or may not provide EDC generation. This service describes the
capability of a particular EDC generator. EDC generators may be shared between sockets. Higher-
level software must arbitrate the use of EDC generators.
If EDC generation is available, InquireAdapter returns the number of EDC generators available for
all the sockets supported by the adapter. The capabilities of each generator can be enumerated by
calling this service for each generator.
Socket Services supports two types of EDC generation: checksums for 8-bit transfers and CRC-SDLC
calculations for 16-bit and 32-bit transfers. EDC generation may be produced by read or write
accesses. Special programming algorithms which require a combination of reads and writes must be
aware of how EDC generation is performed to avoid erroneous computations. Bi-directional EDC
generation may not be usable with Flash programming algorithms since these algorithms typically
require a combination of reads and writes.
EDC generation may not be available with memory-mapped implementations. EDC generators
must be configured before use with the SetEDC service.
See Also GetEDC, SetEDC, StartEDC, PauseEDC, ResumeEDC, StopEDC, ReadEDC
PROGRAM INTERFACE
5.3.19 InquireSocket [BOTH]

RETCODE = InquireSocket (Adapter, Socket, pBuffer, SCIntCaps, SCRptCaps, CtlIndCaps)
ADAPTER Adapter;
SOCKET Socket;
PTR pBuffer;
FLAGS8 SCIntCaps;
FLAGS8 SCRptCaps;
FLAGS8 CtlIndCaps;
The InquireSocket service returns information about the capabilities of the socket specified by the
input parameters.
pBuffer I Points to a client-supplied buffer to be filled with information about the socket. The buffer has
the following form:
typedef struct tagSISTRUCT {
WORD wBufferLength;
WORD wDataLength;
SCHARTBL CharTable;
} SISTRUCT;
The wBufferLength field is set by the client to the size in bytes of SISTRUCT less the size of
The SCHARTBL structure is defined below.
SCIntCaps O Returns a bit-map of events which can trigger a Status Change interrupt. If an event can trigger
a status change interrupt, its value in this parameter is set. In order for the event to trigger a
status change event on a socket, the corresponding value in the SCIntMask parameter of
SetSocket must be set and status change interrupts must be enabled.
For 16-bit PC Cards the following values are implemented as signals.
For CardBus PC Cards several values are read from the Function Present State register on
the card, rather than being implemented as individual signals.
This parameter is a combination of the values described below:
Value Meaning
SBM_WP PC Card WP (write-protect).
SBM_LOCKED Externally generated indicating the state of a mechanical or
electrical card lock mechanism.
Not the same as SBM_LOCK which is used to control a card lock.
SBM_EJECT Externally generated indicating a request to eject a PC Card from
the socket has been made.
SBM_INSERT Externally generated indicating a request to insert a PC Card into
the socket has been made.
SBM_BVD1 PC Card BVD1. When set, this indicates the battery is no longer
serviceable.
SBM_BVD2 PC Card BVD2. When set, this indicates the battery is weak.
SBM_RDYBSY PC Card READY.
SBM_CD CD1# and CD2# (16-bit PC Card)
or CCD1# and CCD2# (CardBus PC Card).
SCRptCaps O Returns Status Change events that the socket is capable of reporting. This parameter is not the
same as SCIntCaps. Some events may be reportable by GetStatus, but not able to generate a
status change interrupt as indicated by SCIntCaps.
If an event is not reportable by GetStatus, its value in this parameter is reset. In this case,
corresponding values in the GetStatus CardStatus parameter are undefined.
This parameter is a combination of the SBM_x values described under the SCIntCaps
parameter.
CtlIndCaps O Returns control and indicator capabilities of the socket. If a value is set, the control or indicator
is supported. If a value is reset, the control or indicator is not supported. This parameter may
be a combination of the following values:
Value Meaning
SBM_WP Indicator for PC Card WP (write-protect) state.
SBM_LOCKED Indicator for externally generated event indicating the state of a
mechanical or electrical card lock mechanism
SBM_EJECT Control for motor to eject a PC Card from the socket.
SBM_INSERT Control for motor to insert a PC Card into the socket.
SBM_LOCK Control for card lock.
Not the same as SBM_LOCKED which reflects the state of an
externally generated card lock event.
SBM_BATT Indicator for BVD1 and BVD2 state.
SBM_BUSY Indicator for showing card is in-use.
SBM_XIP Indicator for eXecute-In-Place application in progress.
Return Codes
Example
SISTRUCT SocketInfo = {
20, // Size of client-supplied buffer is 20 bytes
20, // Size of data returned is 20 bytes
{IF_MEMORY | IF_IO, // Socket supports Memory-Only and
// I/O and Memory interfaces
0xDEB8, // PC Card IREQ# signal may be routed to IRQ levels
// 3, 4, 5, 7, 9, 10, 11, 12, 14, and 15
// as an active high signal
0, // PC Card IREQ# routing not available on any
// level as an active low signal
2, // Number of custom interfaces supported
0x0141, // Custom Interface Number dCustomIF[0], index 0
0x0241}, // Custom Interface Number dCustomIF[1], index 1
};
See Also GetSocket, SetSocket
PROGRAM INTERFACE
Socket Characteristics Structure

typedef struct tagSCHARTBL {
FLAGS16 SktCaps;
FLAGS32 ActiveHigh;
FLAGS32 ActiveLow;
FLAGS16 DMAChannels;
WORD wNumCustomIF = NUM_ENTRIES;
DWORD dCustomIF[NUM_ENTRIES];
} SCHARTBL;
Member Description
SktCaps Flags indicating socket characteristics. If set, the characteristic is supported. This member can be a
Value Meaning
IF_MEMORY Socket supports Memory-Only interface. (See the Electrical Specification.)
IF_IO Socket supports I/O and Memory interface. (See the Electrical
Specification.)
IF_CB Socket supports CardBus PC Card interface. (See the Electrical
Specification.)
IF_33VCC Socket supports 3.3 V Interface.
IF_XXVCC Socket supports X.X V Interface.
IF_VSKEY Socket supports Low Voltage Key.
IF_DMA Socket supports 16-bit PC Card DMA transfers. (See the Electrical
Specification and the Card Services Specification.)
ActiveHigh Bit-map of IRQ levels available for routing an inverted PC Card IREQ# signal when an unmasked event
occurs.
ActiveLow Bit-map of IRQ levels available for routing the normal PC Card IREQ# signal when an unmasked event
occurs.
It is assumed that PC Card IREQ# signals may be shared in a host system.
DMAChannels Bit-map of DMA channels supported by this socket. Bit 0 through 15 correspond to DMA channel 0
through 15. If a bit is set to one, the corresponding DMA channel is supported by the socket. The DMA
width supported by any DMA channel Is host system specific and beyond the scope of Socket Services.
If a socket does not support DMA operations, this field may be omitted.
wNumCustomIF The number of custom interfaces supported by this socket. If this number is non-zero the socket supports
custom interfaces in addition to the interfaces indicated in the SktCaps field.
dCustomIF Array of custom interface ID numbers supported by this socket. (See the Electrical Specification and
see also the Metaformat Specification.)
5.3.20 InquireWindow [PC16]

RETCODE = InquireWindow (Adapter, Window, pBuffer, WndCaps, Sockets)
ADAPTER Adapter;
WINDOW Window;
PTR pBuffer;
FLAGS8 WndCaps;
SKTBITS Sockets;
The InquireWindow service returns information about the capabilities of the window specified by
the input parameters.
Window I Window number. Specifies a physical window on the adapter
pBuffer I Points to a client-supplied buffer to be filled with information about the window. The buffer has
the following form:
typedef struct tagWISTRUCT {
WORD wBufferLength;
WORD wDataLength;
WINTBL WinTable[NUM_TYPES];
} WISTRUCT;
The wBufferLength field is set by the client to the size in bytes of WISTRUCT less the size of
A window may support two types of mapping: memory or I/O. Each window type has
associated characteristics described in tables returned in the client-supplied buffer.
Window characteristics vary if the hardware is used as a memory or as an I/O window. For
that reason, this service may provide multiple tables of information. The MEMWINTBL
structure is defined on page 61. The IOWINTBL structure is defined on page 65.
If a window supports both memory and I/O mapping, both characteristics tables are copied to
the client-supplied buffer. When a window supports both types of mapping, the memory
window characteristics table is first in the buffer, followed by the I/O window characteristics
table. If only one type of mapping is supported, only the appropriate characteristics table is
copied into the buffer by Socket Services.
EISA I/O and Memory windows may be selected, but the supported I/O map is not
programmable. Card enables are asserted based on the pre-defined address line settings
returned in the I/O window characteristics structure member EISASlot.
WndCaps O This parameter indicates the capability of the specified window. It can be a combination of the
following values:
Value Meaning
WC_COMMON If set, window may be used to map the common memory plane of a
16-bit PC Card into the host system memory address space.
WC_ATTRIBUTE If set, window may be used to map the attribute memory plane of a
16-bit PC Card into the host system memory address space.
WC_IO If set, window may be used to map I/O ports on a 16-bit PC Card
into the host system I/O address space.
WC_WAIT If set, window supports the use of the WAIT# signal from a 16-bit
PC Card to generate additional wait states.
PROGRAM INTERFACE
Sockets O Depending on the hardware implementation, windows may be dedicated to a particular socket
or may allow assignment to one or more sockets on an adapter.
If a window may be assigned to a socket, the corresponding bit in this parameter is set. If a
socket does not exist on an adapter its corresponding bit is reset.
The first socket on the adapter is represented by the least significant bit of this parameter.
Note: The size of this field constrains the number of sockets that may be supported by an
adapter.
Return Codes
See Also GetWindow, SetWindow, InquireBridgeWindow, GetBridgeWindow, SetBridgeWindow
Memory Window Characteristics Table

typedef struct tagMEMWINTBL {
FLAGS16 MemWndCaps;
BASE FirstByte;
BASE LastByte;
SIZE MinSize;
SIZE MaxSize;
SIZE ReqGran;
SIZE ReqBase;
SIZE ReqOffset;
SPEED Slowest;
SPEED Fastest;
} MEMWINTBL;
Member Description
MemWndCaps Flags indicating memory window characteristics. This member can be a combination of the following
values:
Value Meaning
WC_BASE If set, the base address of the window is programmable within the range
specified by the FirstByte and LastByte members.
If reset, the base address of the window is fixed in system memory address
space at the address specified in the FirstByte member. When reset, the
LastByte member is undefined.
WC_SIZE If set, the window size is programmable within the range specified by the
If reset, the window size is fixed to the size indicated by the MinSize member.
When reset, both the MinSize and MaxSize members should be the same
value.
characteristics.
window.
WC_8BIT If set, the window may be programmed for 8-bit data bus width.
If reset, the window may not be used for 8-bit data transfers.
WC_BALIGN If set, the window base address must be programmed to align with a multiple
of the window size. For example, a window 16 KBytes in size needs to start on
a 16 KByte boundary in the host system memory address space.
If reset, the window base address may be programmed anywhere in the
windowÕs valid range, subject to any constraint specified by ReqBase.
WC_POW2 If set, a window with WC_SIZE also set must be sized between the MinSize
and MaxSize members as a power of two of the ReqGran member.
If reset, a window with WC_SIZE set may be any multiple of the ReqGran
member between the MinSize and MaxSize members.
For example, if ReqGran is 4 KBytes, MinSize is 4 KBytes, MaxSize is 64
KBytes and WC_POW2 is set, the possible window sizes are 4, 8, 16, 32 and
64 KBytes.
If WC_POW2 is reset, possible windows sizes include all sixteen multiples of
4 KBytes between 4 and 64 KBytes.
PROGRAM INTERFACE
WC_CALIGN If set, 16-bit PC Card offsets are required to be specified to SetPage in

increments of the size of the window.
If reset, 16-bit PC Card offsets may be specified to SetPage without relation to
the size of the window.
For example, if WC_CALIGN is set and the window is 16 KBytes in size, all
16-bit PC Card offsets specified to SetPage must be on 16 KByte boundaries.
WC_PAVAIL If set, the window has hardware available which is capable of dividing the
window into multiple pages.
If reset, the entire window must be addressed as a single page.
WC_PSHARED If set, a windowÕs paging hardware is shared with another window. A request
to use the paging hardware may fail if the other window is using the paging
hardware.
If reset, the windowÕs paging hardware is dedicated and a request to use the
paging hardware should never fail.
This value is only valid if WC_PAVAIL is set.
A Socket Services client should check WC_PSHARED if intending to use
paging services. If set, the client must ensure that a subsequent SetWindow
request requiring paging hardware succeeds before attempting to utilize the
window as the paging hardware may have already been assigned to another
window.
To determine if the pager is available, attempt to assign it to a window using
SetWindow and check for successful return status from the request.
WC_PENABLE If set, the page may be disabled and enabled without reprogramming its
characteristics.
If reset, the client must preserve page state information before disabling the
page.
WC_WP If set, the window may be write-protected to prevent writing 16-bit PC Card
memory mapped into host system memory address space.
If reset, the window may not be write-protected to prevent writing 16-bit PC
Card memory mapped into host system memory address space.
Write-protection is enabled and disabled with the SetPage service which
requires this support to be available on a page basis for windows which have
multiple pages.
FirstByte First byte addressable in host system memory address space by window. If window Base is not
programmable, this is the fixed base address of the window.
LastByte Last byte addressable in host system memory address space by window. The last byte of the window
(base address programmed plus window size minus one) may not exceed this value.
If window Base is not programmable, this member is undefined.
systemÕs memory address space.
MinSize The minimum window size. When window size is programmed with SetWindow it must lie in the range
of the MinSize and MaxSize members and meet all granularity and base requirements.
MaxSize The maximum window size. When window size is programmed with SetWindow it must lie in the
range of the MinSize and MaxSize members and meet all granularity and base requirements.
The window size may be further limited by the base address of the window. The base address plus the
window size minus one must not exceed the LastByte member for windows with programmable sizes.
If MaxSize is zero, window size is the largest value that may be represented by the SIZE data type plus
one.
ReqGran This member describes the required units for expressing window size due to hardware constraints. If the
window size is fixed (WC_SIZE is reset), this member will be the same as the MinSize and MaxSize
members.
ReqBase If WC_BALIGN is reset, this member describes any alignment boundary requirement for programming
the windowÕs base address with SetWindow.
If WC_BALIGN is set, this field is undefined.
ReqOffset If WC_CALIGN is reset, this member describes any alignment boundary requirement for programming
the PC Card offset address with SetPage.
If WC_CALIGN is set, this field is undefined.
Slowest This member represents the slowest access speed supported by the window.
Fastest This member represents the fastest access speed supported by the window.
Comments
The Slowest and Fastest members use the format of the Device Speed Code and Extended Device
Speed Codes of the Device Information Tuple. (See the Metaformat Specification.) For Socket
Services, Bit 7 of the Slowest and Fastest members is reserved and is reset to zero (0).
The Device Speed Code values are used when what would be the mantissa of an Extended Device
Speed Code is reset to zero (0). If the mantissa is non-zero, supported device speeds are coded
according to the Extended Device Speed Code. (See the Metaformat Specification.)
Memory windows map accesses to host system memory address space into accesses to memory
address space located on a PC Card. How the socket hardware performs this mapping determines
the memory characteristics table definition. While memory windows are described by a number of
characteristics, most window mapping hardware falls into one of two categories with each category
having a single set of characteristics.
Direct window mapping hardware selects a fixed combination of high order address lines (typically
via mask and match registers) on the PC Card whenever an access is made within the host system
memory address range assigned to the window. Low order address lines are routed directly to the
PC Card.
The window size determines how many low order address lines are routed directly to the PC Card.
The fixed combination used for the high order address lines is set by the SetPage service. This type
of window mapping hardware requires the window size be a power of two and that the base
address be aligned on a multiple of the window size since mapping is related to the number of low
order address lines routed directly to the PC Card.
Translating window mapping hardware uses additional logic to compute a PC Card address. When
an access is made to a location within the host system address range mapped by the window, the
hardware computes the offset of this location from the beginning of the mapped range (typically via
base and length registers) and adds it to the starting offset on the PC Card as set by the SetPage
service.
While high order address lines may still be set to a fixed combination and some number of low
order address lines may be directly routed to the PC Card, mid-order address lines are computed
by the window mapping hardware. This type of hardware does not require the window be sized as
a power of two or aligned on a boundary related to the window size. However, the window size
must be a multiple of the ReqGran field.
In summary, if direct window mapping hardware is used, the WC_BALIGN, WC_POW2 and
WC_CALIGN parameters are set and the ReqBase and ReqOffset members are not used. If
translating window hardware is used, the WC_BALIGN, WC_POW2 and WC_CALIGN parameters
are reset and the ReqBase and ReqOffset members are significant.
PROGRAM INTERFACE
The ReqBase, ReqOffset and ReqGran members are related to the number of low order address lines
which are routed directly to the PC Card. For example, if the twelve (12) least significant address
lines are routed directly to the PC Card, the ReqGran member will indicate the window must be
sized as a multiple of 4 KBytes. If translating window hardware is used, the ReqBase and ReqOffset
will also indicate the requirement to align the window base address and the PC Card offset on a 4
KByte boundary.
The following table illustrates the relationship of Memory Window Characteristics Table members
to the type of hardware used to implement the window:
Member/Parameter Direct Translating
WC_BALIGN Set reset
WC_POW2 Set reset
WC_CALIGN Set reset
ReqGran Significant Significant
ReqBase Not Used Significant
ReqOffset Not Used Significant
I/O Window Characteristics Table

typedef struct tagIOWINTBL {
FLAGS16 IOWndCaps;
BASE FirstByte;
BASE LastByte;
SIZE MinSize;
SIZE MaxSize;
SIZE ReqGran;
COUNT AddrLines;
FLAGS8 EISASlot;
} IOWINTBL;
Member Description
IOWndCaps Flags indicating I/O window characteristics. This member can be a combination of the following values:
Value Meaning
WC_BASE If set, the base address of the window is programmable within the range
specified by the FirstByte and LastByte members.
If reset, the base address of the window is fixed in host system I/O address
space at the address specified in the FirstByte member. When WC_BASE is
reset, the LastByte member is undefined.
WC_SIZE If set, the window size is programmable within the range specified by the
If reset, the window size is fixed to the size indicated by the MinSize member.
When WC_SIZE is reset, both the MinSize and MaxSize members should be
the same value.
characteristics.
window.
WC_BALIGN If set, the window base address must be programmed to align with a multiple
of the window size. For example, an 8 byte window needs to start on an 8 byte
boundary in the host system I/O address space.
If reset, the window base address may be programmed anywhere in the
windowÕs valid range, subject to any constraint specified by ReqBase.
WC_POW2 If set, a window with WC_SIZE set must be sized between the MinSize and
MaxSize members as a power of two of the ReqGran member.
If reset, a window with WC_SIZE set may be any multiple of the ReqGran
member between the MinSize and MaxSize members.
For example, if ReqGran is 4 bytes, MinSize is 4 bytes, MaxSize is 64 bytes
and WC_POW2 is set, the possible window sizes are 4, 8, 16, 32 and 64
bytes.
If WC_POW2 is reset, possible windows sizes include all sixteen multiples of
4 bytes between 4 and 64 bytes.
PROGRAM INTERFACE
WC_INPACK If set, the window supports the INPACK# signal from a PC Card. This signal
allows I/O windows to overlap in the host systemÕs I/O address space.
If reset, the INPACK# signal from a PC Card is ignored by the window
hardware. In this case, I/O windows may not overlap in the host systemÕs I/O
address space.
WC_EISA If set, the window supports I/O mapping in a the same manner as host
systems with EISA buses. The EISASlot member describes the slot-specific
address decodes for this window.
If reset, the window does not support EISA-like I/O mapping.
WC_CENABLE If set, EISA-like common address space enables may be programmed to be
ignored.
If reset, if the window is programmed for EISA-like I/O mapping, the PC Card
will receive a card enable signal whenever an access is made to an EISA
common address.
This value is only valid if WC_EISA is set.
FirstByte First byte addressable in host system I/O address space by window. If window base is not
programmable, this is the fixed base address of the window.
LastByte Last byte addressable in host system I/O address space by window. The last byte of the window (base
address programmed plus window size minus one) may not exceed this value.
If window base is not programmable, this member is undefined.
systemÕs I/O address space.
MinSize The minimum window size. When window size is programmed with SetWindow it must lie in the range
of the MinSize and MaxSize members and meet all granularity and base requirements.
MaxSize The maximum window size. When window size is programmed with SetWindow it must lie in the
range of the MinSize and MaxSize members and meet all granularity and base requirements.
The window size may be further limited by the base address of the window. The base address plus the
window size minus one must not exceed the LastByte member for windows with programmable sizes.
If MaxSize is zero, window size is the largest value that may be represented by the SIZE data type plus
one.
ReqGran This member describes the required units for expressing window size due to hardware constraints. If the
window size is fixed (WC_SIZE is reset), this member will be the same as the MinSize and MaxSize
members.
AddrLines Number of address lines decoded by window. Typically ten (10) or sixteen (16). If a window only
decodes ten address lines, accesses to locations above 1 KByte will drive card enables to a PC Card
when the ten least significant address lines fall within the range defined by the base address and window
size.
EISASlot Upper byte used for window-specific EISA I/O address decoding. Describes the upper four address lines
used to determine EISA slot-specific addresses used to drive card enables.
This member is undefined if WC_EISA is reset.
5.3.21 PauseEDC [BOTH]

RETCODE = PauseEDC (Adapter, EDC)
ADAPTER Adapter;
EDC EDC;
The PauseEDC service pauses EDC generation on a configured and computing EDC generator
Return Codes
Comments
This service is used to pause EDC generation so some accesses to a PC Card are not involved in the
computation of an EDC value. This service is only supported if EC_PAUSABLE is set in the
InquireEDC Caps parameter.
See Also InquireEDC, GetEDC, SetEDC, StartEDC, ResumeEDC, StopEDC, ReadEDC
PROGRAM INTERFACE
5.3.22 ReadEDC [BOTH]

RETCODE = ReadEDC (Adapter, EDC, Value)
ADAPTER Adapter;
EDC EDC;
DWORD Value;
The ReadEDC service reads the EDC value computed by the EDC generator specified by the input
parameters.
Value O Returns computed EDC value. If the generator was set to ET_CHECK8, only the low byte is
significant. If the generator was set to ET_SDLC16, only the low word is significant. If the
generator was set to ET_SDLC32, all 32-bits are significant.
Return Codes
Comments
If the generator has been used inappropriately (generator not assigned a socket or a combination of
reads and writes were used), the computed Value may be erroneous.
See Also InquireEDC, GetEDC, SetEDC, StartEDC, PauseEDC, ResumeEDC, StopEDC
5.3.23 ResetSocket [BOTH]

RETCODE = ResetSocket (Adapter, Socket)
ADAPTER Adapter;
SOCKET Socket;
The ResetSocket service resets the PC Card in the socket and returns socket hardware to its power-
on default state.
Return Codes
SUCCESS if Adapter and Socket are valid and there is a PC Card in the socket
NO_CARD if there is no PC Card in the socket
Comments
This service toggles the RESET pin of the card in the specified socket on the specified adapter.
This service completes an entire RESET pulse, toggling the pin to the RESET state and back to the
normal state. It ensures the minimum RESET pulse width is observed. It does NOT wait after
returning the RESET pin to its normal state. The client must ensure that a card is not accessed
before it is READY after this service has returned.
All socket hardware is returned to its default power-on state:
• IFType set to IF_MEMORY if a 16-bit PC Card is in the socket or to IF_CARDBUS if a CardBus
PC Card is in the socket.
• IREQRouting disabled.
• VCC, VPP1 and VPP2 set to 5 V DC for a 5 volt only system, otherwise set to the voltage
specified by the VS1# and VS2# pins.
• All windows, pages and EDC generators disabled.
PROGRAM INTERFACE
5.3.24 ResumeEDC [BOTH]

RETCODE = ResumeEDC (Adapter, EDC)
ADAPTER Adapter;
EDC EDC;
The ResumeEDC service resumes EDC generation on a configured and paused EDC generator
Return Codes
Comments
This service is used to resume EDC generation so accesses to a PC Card are involved in the
computation of an EDC value. This service is only supported if EC_PAUSABLE is set in the
InquireEDC Caps parameter.
See Also InquireEDC, GetEDC, SetEDC, StartEDC, PauseEDC, StopEDC, ReadEDC
5.3.25 SetAdapter [BOTH]

RETCODE = SetAdapter (Adapter, State, SCRouting)
ADAPTER Adapter;
FLAGS8 State;
IRQ SCRouting;
The SetAdapter service sets the configuration of the specified adapter.

State I Requested state of the adapter hardware. This parameter can be a combination of the following
values:
Value Meaning
AS_POWERDOWN If set, adapter hardware should attempt to conserve power. Before
an adapter conserving power may be used, full power must be
restored using this service.
If reset, adapter hardware should enter the fully-powered, fully
functional state.
AS_MAINTAIN If set, all adapter and socket configuration information is maintained
while power consumption is reduced.
If reset, adapter and socket configuration information must be
maintained by the client.
This value is only valid if the AS_POWERDOWN value is set.
SCRouting I Sets status change interrupt routing. The routing level and active-state are validated even if
routing is being disabled.
This parameter is an IRQ data type. It is a combination of a binary value representing the
interrupt level the status change interrupt is currently routed to and the following optional bit-
masks:
Value Meaning
IRQ_HIGH If set, status change interrupt is set to be active-high.
If reset, status change interrupt is set to active-low.
On adapters that do not have programmable status change level
logic, the desired interrupt level must match the actual hardware or
the request is failed returning BAD_IRQ.
IRQ_ENABLE If set, status change interrupt is enabled. If an unmasked status
change event occurs, the adapter generates a hardware interrupt of
the specified level.
If reset, status change interrupts are not generated by the adapter.
Return Codes
BAD_IRQ if StatusChange specifies an unsupported State or IRQ level
Comments
Preserving state information may not allow the same level of power reduction as not preserving
state information. The ability to reduce power consumption is vendor specific and reduced power
settings may not result in any power savings. For example, if an adapter supports a reduced power
consumption mode, but is unable to preserve state information in that mode, requests for reduced
power consumption and state preservation may be ignored and SUCCESS returned. The actual
adapter configuration is returned by the GetAdapter request.
PROGRAM INTERFACE
All parameters have been designed to map directly to the values returned by the GetAdapter
information with GetAdapter, make changes and then use this service to modify the configuration
without having to create initial values for each parameter.
See Also InquireAdapter, GetAdapter
5.3.26 SetBridgeWindow [BOTH]

RETCODE = SetBridgeWindow (Adapter, Window, Socket, Size, State, Base)
ADAPTER Adapter;
WINDOW Window;
SOCKET Socket;
SIZE Size;
FLAGS8 State;
BASE Base;
The SetBridgeWindow service sets the current configuration of the bridge window specified by the
input parameters. If present on the adapter, PC Card bridge windows are required to allow access to
devices on PC Cards.
Socket I Sets physical socket the bridge window is currently assigned.
Size I Sets the size of the bridge window in bytes.
State I Defined as below. Sets the state of the bridge window hardware. This parameter can be a
Value Meaning
WS_IO If set, this bridge window routes host system I/O accesses to the
PC Card socket.
If reset, this bridge window routes host system memory accesses
to the PC Card socket.
WS_ENABLED If set, the bridge window is enabled and routing host system
If reset, the bridge window is disabled.
Base O Sets the base address of the specified bridge window. It is the first address within the host
system memory or I/O address space routed to the PC Card socket.
Return Codes:
SUCCESS if all parameters are valid
BAD_ATTRIBUTE if requested State does not match the window's capabilities
BAD_BASE if the Base is invalid
BAD_SIZE if Size is invalid
BAD_SOCKET if Socket is invalid for Window
BAD_TYPE if WS_IO setting is invalid
Comments
All parameters have been designed to map directly to the values returned by the
GetBridgeWindow service. This is intended to allow clients of Socket Services to retrieve current
configuration information with this service, make changes and then use the SetBridgeWindow
service to modify the configuration without having to create initial values for each parameter.
See Also InquireBridgeWindow, GetBridgeWindow, InquireWindow, GetWindow, SetWindow,

AccessConfigSpace.
PROGRAM INTERFACE
5.3.27 SetEDC [BOTH]

RETCODE = SetEDC (Adapter, EDC, Socket, State, Type)
ADAPTER Adapter;
EDC EDC;
SOCKET Socket;
FLAGS8 State;
FLAGS8 Type;
The SetEDC service sets the configuration of the EDC generator specified by the input parameters.
Socket I Specifies the physical socket on the adapter that the EDC generator is to be assigned.
State I Sets the current state of the EDC generator. This field may be combination of the following
values:
Value Meaning
EC_UNI If set, EDC generator is computes in only one direction.
EC_WRITE determines whether computation is on read or write
accesses.
If reset, EDC generator is computes on both read and write
accesses.
EC_WRITE If set, EDC generator is computes only on write accesses.
If reset, EDC generator is computes only on read accesses.
This value is only valid if EC_UNI is set.
Type I Sets type of EDC generated. This parameter may be one of the following values:
Value Meaning
ET_CHECK8 EDC generated is 8-bit checksum.
Return Codes
SUCCESS if Adapter, EDC, Socket, State and Type are valid
BAD_ATTRIBUTE if State or Type is invalid
Comments
All parameters have been designed to map directly to the values returned by the GetEDC service.
GetEDC, make changes and then use this service to modify the configuration without having to
See Also InquireEDC, GetEDC, StartEDC, PauseEDC, ResumeEDC, StopEDC, ReadEDC
PROGRAM INTERFACE
5.3.28 SetPage [PC16]

RETCODE = SetPage (Adapter, Window, Page, State, Offset)
ADAPTER Adapter;
WINDOW Window;
PAGE Page;
FLAGS8 State;
OFFSET Offset;
The SetPage service configures the page specified by the input parameters. It is only valid for
memory windows (WS_IO is reset for the Window). This service is unsupported by CardBus PC
Card.
Window I Specifies a physical window on the adapter.
Page I Specifies the page within the Window.
State I Programs the state of the Page within the Window. This parameter can be a combination of the
following values:
Value Meaning
PS_ATTRIBUTE If set and Page is enabled, page is programmed to map PC Card
attribute memory into host system memory space.
If reset and Page is enabled, page is programmed to map PC Card
common memory into host system memory space.
PS_ENABLED If set, Page is enabled and maps PC Card memory into the host
system memory or I/O space.
If reset, Page is disabled.
Some hardware implementation may not allow individual pages to
be disabled, only entire windows. If there is only a single page in the
window, the window is disabled by this request.
This request returns BAD_ATTRIBUTE for multi-paged windows if
the pages cannot be individually disabled.
PS_WP If set, Page is write-protected by page mapping hardware in socket.
If reset, Page is not write-protected by socketÕs page-mapping
hardware. However, the PC Card memory may be write-protected
in other ways.
If set and the window does not support write-protection,
BAD_ATTRIBUTE is returned.
Offset I The offset of a PC CardÕs memory to be mapped into host system memory space by this
page. The following formula may be used to calculate the system memory address to access
the PC Card memory being mapped by the page:
Base + (Page * 16 KBytes)
Return Codes
SUCCESS if Adapter, Offset, Page, State and Window are valid
BAD_ATTRIBUTE if State is invalid
BAD_OFFSET if Offset is invalid
BAD_PAGE if Page is invalid
Comments
All parameters have been designed to map directly to the values returned by the GetPage service.
GetPage, make changes and then use this service to modify the configuration without having to
All pages in windows which are subdivided into multiple pages are 16 KBytes in size. A window
with only a single page may be any size meeting the constraints returned by InquireWindow.
To map PC Card memory into system memory requires that both the WS_ENABLED value of the
State field used by Get/SetWindow be set and the PC_ENABLED value of the State field used by
See Also InquireWindow, GetWindow, SetWindow, GetPage
PROGRAM INTERFACE
5.3.29 SetSocket [BOTH]

RETCODE = SetSocket (Adapter, Socket, SCIntMask, Vcontrol, VccLevel, VppLevels, State,
CtlInd, IREQRouting, IFType, IFIndex)
ADAPTER Adapter;
SOCKET Socket;
FLAGS8 SCIntMask;
PWRINDEX Vcontrol;
PWRINDEX VccLevel;
PWRINDEX VppLevels;
FLAGS8 State;
FLAGS8 CtlInd;
IRQ IREQRouting;
FLAGS8 IFType;
WORD IFIndex;
The SetSocket service sets the current configuration of the socket identified by the input parameters.
SCIntMask I Sets mask for events that generate a status change interrupt when they occur on the socket. If
a value is set the event generates a status change interrupt if the following conditions are met:
The event is supported as indicated by the SCIntCaps parameter of InquireSocket and status
change interrupts have been enabled by SetAdapter.
This parameter is a combination of the SBM_x values defined in InquireSocket.
An attempt to set an event that is unsupported by SCIntCaps will not return an error.
GetSocket will only return values that are supported by SCIntCaps.
Vcontrol I This parameter takes on the following values:
Value Meaning
VCTL_CISREAD If reset, the VCC level and VPP[2::1] levels are controlled by the
VccLevel and VppLevels fields.
If set, the VCC level and VPP[2::1] levels are set to the value
indicated by the voltage sense signaling from the PC Card and the
VccLevel and VppLevels fields are ignored.
VCTL_OVERRIDE VCTL_OVERRIDE applies only to 16-bit PC Cards. The CardBus
PC Card interface requires the VCC level match the value indicated
by the voltage sense signaling from the PC Card or this service
returns an error.
If reset, the VCC level must match the value indicated by the voltage
sense signaling from the PC Card or this service returns an error.
If set, the VccLevel need not match the value indicated by the
voltage sense signaling from the PC Card.
If the VccLevel does match the voltage sense signaling from the PC
Card, VCTL_OVERRIDE is reset when returned by GetSocket.
Note: The VCTL_CISREAD and VCTL_OVERRIDE bits are mutually exclusive. If both
are set, BAD_ATTRIBUTE is returned. In addition, Socket Services will reset these
bits upon card removal.
Note: When initially powering a PC Card with SetSocket, if the VCTL_CISREAD value is
set, the PC Card is powered to the value indicated by the voltage sense signaling
from the card.
VccLevel I Sets current power level of VCC signal. This is an index into the array of PWRENTRY items
returned by InquireAdapter. Valid values range from zero to one less than the number of
levels returned by InquireAdapter.
On Low Voltage capable systems Socket Services must observe that state of the VS1# and
VS2# pins when requesting voltage changes on the VCC and VPP[2::1] pins to prevent
inappropriate voltages being applied to the card unless VCTL_OVERRIDE is set. The
VCTL_OVERRIDE is provided to protect the card from a Low Voltage unaware client. Proper
procedure must be used to determine appropriate voltage levels for the card, this includes
assuring that systems that are not X.X V capable must be X.X V aware to ensure that X.X V
cards are not damaged. (See the Electrical Specification.)
When changing from one non-zero VCC to another non-zero VCC, Socket Services is required
to observe a Power-up/Power-down timing sequence. (See the Electrical Specification.)
VppLevels I Sets current power level of VPP[2::1] signals. This is two indices into the array of
PWRENTRY items returned by InquireAdapter. Separate values are in this parameter for
the VPP1 and VPP2 signals. Valid values for each index range from zero to one less than the
number of levels returned by InquireAdapter.
Note: The VccLevel and VppLevels always return the actual levels currently applied to the
card.
State I Resets latched values representing state changes experienced by the socket hardware. Only
those values set in the InquireSocket SCRptCaps parameter are supported. Attempts to reset
unsupported values are ignored.
CtlInd I Sets socket controls and indicators. If a value is set, the corresponding control or indicator is
turned-on. If a value is reset, the corresponding control or indicator is turned-off. Values
supported by the socket are defined by the CtlIndCaps parameter returned by InquireSocket.
IREQRouting I Sets PC Card IREQ# routing. This parameter is an IRQ data type.
This parameter is ignored if IFType is not IF_IO or IF_CARDBUS. If IFType is IF_IO or
IF_CARDBUS, routing level and inverter state are validated even if routing is being disabled.
This parameter is a combination of a binary value representing the IRQ level used for routing
the PC Card IREQ# signal and the following optional values:
Value Meaning
IRQ_INVALID If set, the binary value representing the IRQ level is invalid and
should be ignored. This bit may not be set with IRQ_HIGH.
If reset, the binary value representing the IRQ level is valid.
IRQ_HIGH If set, the PC Card IREQ# signal is inverted.
If reset, the PC Card IREQ# signal is routed without inversion.
IRQ_ENABLE If set, IREQ# routing is enabled.
If reset, IREQ# routing is not enabled and interrupts from a PC
Card in the socket are ignored.
IFType I Sets the current interface type. Uses the same definitions as the IFType parameter of
GetSocket.
When a CardBus PC Card is inserted in a socket, this field is ignored. Sockets automatically
configure to IF_CARDBUS when a CardBus PC Card is inserted.
IFIndex I Sets the Custom Interface setting when IFType is set to IF_CUSTOM. This is an index into the
array of dCustomIF items returned by InquireAdapter. Valid values range from zero to one
less than the number of interface numbers returned by InquireAdapter.
This field is ignored when IFType is not set to IF_CUSTOM.
PROGRAM INTERFACE
Return Codes
BAD_IRQ if IREQRouting not supported
BAD_TYPE if IFType not supported
BAD_VCC if VCC level is invalid
BAD_VPP if VPP1 or VPP2 level is invalid
BAD_ATTRIBUTE if both CCTL_CISREAD and VCTL_OVERRIDE are set
Comments
All parameters have been designed to map directly to the values returned by the GetSocket
information with GetSocket, make changes and then use this service to modify the configuration
without having to create initial values for each parameter.
See Also InquireSocket, GetSocket
5.3.30 SetWindow [PC16]

RETCODE = SetWindow (Adapter, Window, Socket, Size, State, Speed, Base)
ADAPTER Adapter;
WINDOW Window;
SOCKET Socket;
SIZE Size;
FLAGS8 State;
SPEED Speed;
BASE Base;
The SetWindow service sets the configuration of the window specified by the input parameters.
Window I Window number. Specifies a physical window on the adapter. May refer to either a hardware
or an adapter window.
Socket I Assigns the Window to the specified socket. Socket numbers range from zero to fifteen using
bits 0 to 3. The rest of the bits in this field are binding specific.
Size I Sets the windowÕs size. If Size is equal to zero (0), the window is the maximum size that may
be represented by the data type used for this parameter plus one. For example, if the data type
used for Size is a word and it is expressed in units of a byte, a value of zero represents a
window size of 65,536 bytes.
State I Sets the state of the window hardware as defined as below. This parameter can be a
Value Meaning
WS_IO If set, window maps registers on a 16-bit PC Card into the host
system's I/O address space.
If reset, window maps memory address space on a 16-bit PC Card
into the host system's memory address space.
WS_ENABLED If set, window is enabled and mapping a 16-bit PC Card into the
host system memory or I/O address space.
If reset, window is disabled.
WS_16BIT This value is only valid for 16-bit PC Cards.
If set, window is programmed for a 16-bit data bus width.
If reset, window is programmed for an 8-bit data bus width.
WS_PAGED If set, window is subdivided into multiple 16 KByte pages whose
card offset addresses may be set individually using SetPage.
If reset, window is a single page.
This value is only valid for memory windows (WS_IO reset) on 16-
bit PC Cards.
WS_EISA If set, window is using EISA I/O mapping.
If rest, window is using ISA I/O mapping.
This value is only valid for I/O windows (WS_IO set).
WS_CENABLE If set, accesses to I/O ports in EISA common I/O areas generate
card enables.
If reset, accesses to I/O ports in EISA common I/O areas are
ignored.
This value is only valid for I/O windows (WS_IO set) that have
WS_EISA set.
PROGRAM INTERFACE
Speed I This parameter is the access speed the client wishes to use for the window. It uses the format
of the Device Speed Code and Extended Device Speed Codes of the Device Information Tuple.
(See the Metaformat Specification and the Electrical Specification.)
If Socket Services does not support the speed requested, it uses the next slowest speed it
supports.
For Socket Services, Bit 7 of the Speed is reserved and is reset to zero (0).
This parameter is ignored for I/O windows (WS_IO set).
Base I Programs the base address of the specified window. It is the first address within the system
memory or I/O space to which the window responds.
Return Codes
SUCCESS if all parameters are valid
BAD_ATTRIBUTE if requested State does not match the windowÕs capabilities
BAD_BASE if the Base is invalid
BAD_SIZE if Size is invalid
BAD_SOCKET if Socket is invalid for Window
BAD_SPEED if Speed is too slow
BAD_TYPE if WS_IO setting is invalid
Comments
All parameters have been designed to map directly to the values returned by the GetWindow
information with GetWindow, make desired changes and then use this service to modify the
The following comments apply to 16-bit PC Card only:
• For memory mapping windows, the area of the PC Card memory array mapped into the host
system memory space is managed by GetPage and SetPage requests.
• To map PC Card memory address space into host system memory address space requires that
both the WS_ENABLED value of the State parameter used by Get/SetWindow be set and the
PC_ENABLED value of the State parameter used by Get/SetPage be set. For windows with
WS_PAGED reset, the PS_ENABLED value is ignored by SetPage. The window is enabled and
disabled by the WS_ENABLED value of SetWindow. GetPage for windows with WS_PAGED
reset reports the value of WS_ENABLED for PS_ENABLED.
• For windows with WS_PAGED set, WS_ENABLED acts as a global enable/disable for all pages
within the window. Once WS_ENABLED has been set using SetWindow, individual pages may
be enabled and disabled using SetPage and PS_ENABLED.
• If WC_WENABLE is reported as set by InquireWindow, Socket Services preserves the state of
PS_ENABLED for each page in the window whenever WS_ENABLED is changed by
SetWindow. If WC_ENABLE is reported as reset by InquireWindow, the client must use
SetPage to set the PS_ENABLED state for each page within the window after WS_ENABLED is
set with SetWindow.
See Also InquireWindow, GetWindow, GetPage, SetPage, InquireBridgeWindow,

GetBridgeWindow, SetBridgeWindow
5.3.31 StartEDC [BOTH]

RETCODE = StartEDC (Adapter, EDC)
ADAPTER Adapter;
EDC EDC;
The StartEDC service starts a previously configured EDC generator specified by the input
parameters.
Return Codes
Comments
This service loads the EDC generator with any required initialization value to properly compute the
configured type of EDC.
See Also InquireEDC, GetEDC, SetEDC, PauseEDC, ResumeEDC, StopEDC, ReadEDC
PROGRAM INTERFACE
5.3.32 StopEDC [BOTH]

RETCODE = StopEDC (Adapter, EDC)
ADAPTER Adapter;
EDC EDC;
The StopEDC service stops EDC generation on a configured and computing EDC generator
Return Codes
See Also InquireEDC, GetEDC, SetEDC, StartEDC, PauseEDC, ResumeEDC, ReadEDC
5.3.33 VendorSpecific [BOTH]

RETCODE = VendorSpecific (Adapter É)
ADAPTER Adapter;
This service is vendor specific. The service is reserved for vendors to add proprietary extensions to
the Socket Services interface. No guarantee is made that any mode-specific pointer conversion will
be handled correctly. Vendors should attempt to use the registers in a non-mode specific manner.
Return Codes
SUCCESS if parameters are valid
Other return codes are specific to the Socket Services handler.
Comments
This service may have additional parameters that are specific to a particular vendorÕs handler.
Before using this service, a client should use the GetVendorInfo service to confirm the implementer
to validate whether the vendor specific services are available.
See Also GetVendorInfo
6. US IN G SOC K E T SE R V IC E S
This section describes how various services within Socket Services are intended to be used. This
section has been included as an aid to understanding how Socket Services is intended to work. The
approaches outlined in this section are for clarification only and may not be required.
6.1 Determining Socket Services Resources

The first task any client of Socket Services performs is determining that Socket Services is installed.
The GetAdapterCount service is used for presence detection returning Signature and TotalAdapters.
Next, the client verifies that a compatible Socket Services is installed. The client checks compatibility
by verifying the Socket Services Compliance level returned by GetSSInfo. If this Compliance level is
acceptable, the client may also wish to verify whether the vendorÕs version is acceptable by
checking the ASCIIZ string describing the implementer (Type = 0) and the Release number returned
by GetVendorInfo. This last step is optional.
Once an acceptable Socket Services handler has been verified, the client may begin to determine
the capabilities of the hardware. GetAdapterCount returns the number of adapters present in
NumAdapters. The client may then call InquireAdapter for each adapter to determine its capabilities.
InquireAdapter reports the number of sockets on each adapter, the number of memory or I/O
mapping windows available on the adapter, the number of EDC generators and whether certain
capabilities are available on individual sockets or are implemented on an adapter basis. For
instance, an adapter may support hardware indicators only at the adapter level. If a client sets the
indicator for Busy Status on one socket and resets it on another socket, the indicator will be left on
since the indicator must represent the state of all sockets.
Different hardware implementations may implement window management differently.
InquireAdapter reports the total number of windows available on the adapter. However, some
windows may only be available on specific sockets. In other implementations they may be
assignable to any socket. The InquireWindow service is used to determine a specific windowÕs
characteristics. The InquireSocket service is used to determine each socketÕs characteristics.
Error Detection capability is determined in the same manner, using the InquireEDC service. Error
detection generators may be dedicated to a particular socket, or useable with more than one socket.
Higher-level software determining Socket Services capabilities may construct RAM-based tables
describing the configuration found. These tables might contain information relating to the
assignment of Socket Services resources.
6.2 Status Change Handling

A Socket Services client may note status changes in two ways. First, the client may poll Socket
Services on a socket-by-socket basis to determine if a change has occurred. This polling may take
place at any time that Socket Services is allows entry. The software may poll at prescribed times
(such as before using a Socket Services resource) or as prompted by an external source (such as a
timer interrupt).
The second approach is to program one or more sockets to generate an interrupt when a status
change occurs. Different hardware implementations may limit the number of interrupts available.
In these situations more than one socket may be assigned to the same interrupt. The status change
interrupt handler uses the AcknowledgeInterrupt service to determine which socket experienced
the status change.
USING SOCKET SERVICES
The AcknowledgeInterrupt service returns a bit-map representing all of the sockets administered
by a particular adapter. If a bit is set, the corresponding socket has a condition that could have
caused the interrupt. This bit represents current socket status AND-ed with the socketÕs status
change enables.
The final act of the clientÕs status change interrupt handler is to complete interrupt processing by
resetting host hardware to prepare for future interrupts. The handler then returns to the interrupted
process concluding interrupt handling. Processing continues in the interrupted routine.
During background processing, outside of the hardware interrupt handler, the Socket Services client
polls each socket indicating a change with the GetStatus service. Returned values indicate the cause
of the interrupt.
6.3 Bus-Expanders or Docking Stations

In some instances, clients may choose to expand the number of PC Card sockets on a host by
plugging an expander of some type into a socket. An extension to Socket Services is required to
address these additional sockets, if they are to be handled transparently to Socket Services clients.
One approach might be to address these sockets as if they existed on another adapter. Software
resident in the host could intercept calls to Socket Services and filter the GetAdapterCount service
and all services addressing this new Ôadapter' and the sockets it contains.
The above approach is only one example. The actual implementation of expanding the number of
PC Card sockets using an existing socket is vendor specific.
Docking stations are another situation that is quite similar to bus-expanders. An algorithm for
handling hot-dock events is defined in section 3.6 Docking.
6.4 Using XIP

eXecute-In-Place (XIP) applications require sockets which support memory-mapped windows. In
addition, unlike many other clients of PC Card sockets, XIP applications require exclusive, full-time
access to the these resources. Higher-level software that utilizes Socket Services resources must
ensure that resources used by XIP are dedicated and are not shared with other applications.
6.5 Power Management

Power Management can be an extremely complex issue within host environments. Socket Services
merely provides a means to manipulate the power levels available on an adapter, if they are
adjustable in the hardware implementation. Socket Services does not deal with Power Management
capabilities available on installed cards. These capabilities are expected to be utilized by card-aware
drivers through a higher-level software service.
AP P E N D IX - A
7. SE R V IC E COD E S
Table 7Ð1 Service CodesÐNumerical Order
Service Code Value Service Code Value
GetAdapterCount 80H SetEDC 97H
Reserved for historical purposes 81HÐ82H StartEDC 98H
GetSSInfo 83H PauseEDC 99H
InquireAdapter 84H ResumeEDC 9AH
GetAdapter 85H StopEDC 9BH
SetAdapter 86H ReadEDC 9CH
InquireWindow 87H GetVendorInfo 9DH
GetWindow 88H AcknowledgeInterrupt 9EH
SetWindow 89H GetSetPriorHandler 9FH
GetPage 8AH GetSetSSAddr A0H
SetPage 8BH GetAccessOffsets A1H
InquireSocket 8CH AccessConfigurationSpace A2H
GetSocket 8DH InquireBridgeWindow A3H
SetSocket 8EH GetBridgeWindow A4H
GetStatus 8FH SetBridgeWindow A5H
ResetSocket 90H Reserved for future use A6HÐADH
Reserved for historical purposes 91HÐ94H VendorSpecific AEH
InquireEDC 95H Reserved for Card Services AFH
GetEDC 96H
Note: Reserved entries should not be used. They are reserved for historical
purposes, Card Services use, or for future expansion.
SERVICE CODES
Table 7Ð2 Service Codes  Alphabetic Order

Service Code Value Service Code Value
AccessConfigurationSpace A2H InquireWindow 87H
AcknowledgeInterrupt 9EH PauseEDC 99H
GetAccessOffsets A1H ReadEDC 9CH
GetAdapter 85H Reserved for Card Services AFH
GetAdapterCount 80H Reserved for future use A6HÐADH
GetBridgeWindow A4H Reserved for historical purposes 81HÐ82H
GetEDC 96H Reserved for historical purposes 91HÐ94H
GetPage 8AH ResetSocket 90H
GetSetPriorHandler 9FH ResumeEDC 9AH
GetSetSSAddr A0H SetAdapter 86H
GetSocket 8DH SetBridgeWindow A5H
GetSSInfo 83H SetEDC 97H
GetStatus 8FH SetPage 8BH
GetVendorInfo 9DH SetSocket 8EH
GetWindow 88H SetWindow 89H
InquireAdapter 84H StartEDC 98H
InquireBridgeWindow A3H StopEDC 9BH
InquireEDC 95H VendorSpecific AEH
InquireSocket 8CH
Note: Reserved entries should not be used. They are reserved for historical
purposes, Card Services use, or for future expansion.
AP P E N D IX - B
8. RE T U R N COD E S
Table 8Ð1 Return Codes  Numerical Order
Return Code Value Description
SUCCESS 00H The request succeeded
BAD_ADAPTER 01H Specified adapter is invalid
BAD_ATTRIBUTE 02H Specified attribute is invalid
BAD_BASE 03H Specified base system memory address is invalid
BAD_EDC 04H Specified EDC generator is invalid
Reserved 05H Reserved for historical purposes
BAD_IRQ 06H Specified IRQ level is invalid
BAD_OFFSET 07H Specified PC Card offset is invalid
BAD_PAGE 08H Specified page is invalid
READ_FAILURE 09H Unable to complete read request
BAD_SIZE 0AH Specified size is invalid
BAD_SOCKET 0BH Specified socket is invalid
Reserved 0CH Reserved for historical purposes
BAD_TYPE 0DH Specified window or interface type is invalid
BAD_VCC 0EH Specified VCC power index is invalid
BAD_VPP 0FH Specified VPP1 or VPP2 power index is invalid
BAD_WINDOW 11H Specified window is invalid
WRITE_FAILURE 12H Unable to complete write request
NO_CARD 14H No PC Card in socket
BAD_SERVICE 15H Service not supported
BAD_MODE 16H Requested processor mode is not supported
BAD_SPEED 17H Specified speed is invalid/unavailable
BUSY 18H Unable to process request at this time - retry later
Reserved 19H - FFH Reserved for Card Services and future expansion
Note: Return Codes common to Card Services use the same values. Reserved
values should not be used. They are reserved for historical purposes, Card
Services use, or for future expansion.
RETURN CODES
Table 8Ð2 Return Codes  Alphabetic Order

Return Code Value Description
BAD_ADAPTER 01H Specified adapter is invalid
BAD_ATTRIBUTE 02H Specified attribute is invalid
BAD_BASE 03H Specified base system memory address is invalid
BAD_EDC 04H Specified EDC generator is invalid
BAD_SERVICE 15H Service not supported
BAD_IRQ 06H Specified IRQ level is invalid
BAD_MODE 16H Requested processor mode is not supported
BAD_OFFSET 07H Specified PC Card offset is invalid
BAD_PAGE 08H Specified page is invalid
BAD_SIZE 0AH Specified size is invalid
BAD_SOCKET 0BH Specified socket is invalid
BAD_SPEED 17H Specified speed is invalid/unavailable
BAD_TYPE 0DH Specified window or interface type is invalid
BAD_VCC 0EH Specified VCC power index is invalid
BAD_VPP 0FH Specified VPP1 or VPP2 power index is invalid
BAD_WINDOW 11H Specified window is invalid
BUSY 18H Unable to process request at this time - retry later
NO_CARD 14H No PC Card in socket
READ_FAILURE 09H Unable to complete read request
Reserved 0CH Reserved for historical purposes
Reserved 19H - FFH Reserved for Card Services and future expansion
SUCCESS 00H The request succeeded
WRITE_FAILURE 12H Unable to complete write request
Note: Return Codes common to Card Services use the same values. Reserved
values should not be used. They are reserved for historical purposes, Card
Services use, or for future expansion.
AP P E N D IX - C
9. SOC K E T SE R V IC E S BIN D IN GS
9.1 Overview
A Socket Services binding answers the following three questions for a specific host environment:
How is the presence of Socket Services determined?
How are Socket Services requests made?
How are arguments passed to and from Socket Services?
A specific host environment for a Socket Services client is defined by the operating system in use
and the host platformÕs architecture. Multi-mode processors may require separate bindings for each
mode used by an operating system. Operating systems that emulate other operating systems may
also implement more than one Socket Services binding.
9.2 Presence Detection and Installation Notification

A client determines whether Sockets Services is available in the host environment through a
binding specific presence detection mechanism. All bindings specify a method of determining the
presence of Socket Services using operations that have well-defined responses whether Socket
Services is actually installed or not. A Socket Services client may use the Socket Services request
mechanism for presence detection if the binding guarantees a negative response is returned if
Socket Services is not installed.
Socket Services handlers may be installed before or after Card Services. If a Socket Services handler
is installed before Card Services, Card Services uses the binding specific presence detection
mechanism to locate the handler. If a Socket Services handler is installed after Card Services, the
Socket Services handler notifies Card Services of its installation using a binding specific method.
9.3 Making Socket Services Requests

Socket Services requests are made in a binding-specific manner. Software interrupts, far or near
calls, operating system device driver interfaces and other methods of making requests of Socket
Services may be appropriate depending on the host systemÕs environment. Environments which
emulate other environments may actually provide more than one method of making a Socket
Services request. If a Socket Services implementation is not able to satisfy a request from a client in
an emulated environment, it must insure the request is failed.
SOCKET SERVICES BINDINGS
9.4 Argument Passing

A Socket Services binding defines how arguments are passed to and from Socket Services.
Depending on the host environment, arguments may be passed in registers, in stack-based packets
or even in global data areas. There are a number of possible input arguments to a Socket Services
request. These include:
Service The service that Socket Services is being requested to perform.
Adapter The hardware which connects a host system bus to 68-pin PC Card sockets.
Window An area in a host systemÕs memory or I/O address space through which a PC Card may be
accessed.
Page A subdivision of a window. If there is more than one page in a window, all pages are 16
KBytes in size.
Socket The 68-pin socket a PC Card is inserted in.
Counts Number of items.
Attributes Typically a bit-mapped field that describes characteristics.
Data Area Pointer to a Socket Services data area. Provided to Socket Services by its clients in
environments where data pointers must be manufactured by the operating system.
Buffer Pointer to a data buffer.
Offset An offset into a PC CardÕs address space.
Many Socket Services interfaces do not use all of the arguments in every request. If an input
argument is not used for a service, but the binding provides for a consistent calling structure, the
argument is ignored.
Socket Services interfaces may modify arguments to return information. If Socket Services does not
use an argument to return information, it is returned unmodified.
All Socket Services interfaces return Status. This is a RETCODE as defined in a previous section. A
binding may use the same or an overlapping representation for the Service input argument and
Status.
9.5 Power Management and Indicators

Power management and indicators may be available on a per adapter or per socket basis. To
provide a consistent interface, Socket Services provides access to these services on a socket basis. It is
expected that a hardware implementation that only provides power management and/or indicator
control at the adapter level shall provide a Socket Services handler that manages those resources for
the entire adapter based on requests to individual sockets.
Socket Services does indicate whether power management and indicator control is performed at the
adapter or socket level. However, by providing only one control point (the socket), a client of Socket
Services is not required to provide two types of controlling routines.
9.6 x86 Architecture Binding
9.6.1 Overview
This section describes the Socket Services bindings for x86-based computers using various system
bus architectures.
There are a number of members of the x86 processor family offering up to three modes of
operations: real, protect and virtual (also known as V86). The x86 family also varies in addressable
memory space (1, 16 or 4096 megabytes), register size (16 or 32-bit) and memory management
capabilities (paging).
Processor Register Size Address Space Real Protect Virtual Paging

x86 16 1 MB Yes No No No
286 16 16 MB Yes Yes No No
386 and above 32 4096 MB Yes Yes Yes Yes
A real mode client is limited to one megabyte of address space and 16-bit registers. In protect mode,
clients can address much larger amounts of memory with 16 or, on some processors, 32-bit registers.
In V86 mode, multiple real mode clients operate independently as if they were the only real mode
client. A control program running in protect mode remaps memory space so each client believes it
is operating in the first megabyte of address space, addressing physical memory.
Different operating systems exploit different features of these processors. Due to the differences
between the capabilities of x86 processors and the manner that x86 operating systems use the
processor, this section actually defines four separate types of clients that use Socket Services.
An environment must provide a binding for each type of client it supports. The four types of clients
defined by this section are:
DOS real mode clients
OS/2 16-bit protect mode clients
Windows 16-bit protect mode clients
Windows 32-bit protect mode VxD clients
9.6.2 Presence Detection

Before Card Services has been loaded, all Socket Services clients determine the presence of Socket
Services by making a Socket Services GetAdapterCount request in real-mode. If the request returns
with the [CF] set or the Signature field is not equal to the ASCII characters 'SS', Socket Services is not
installed.
If the GetAdapterCount request returns with the [CF] reset and the Signature field is set to the ASCII
characters 'SS', Socket Services is installed. The Socket Services client then performs real-mode
GetSSInfo requests to determine how many Socket Services handlers are installed in the host
system and which adapters each Socket Services handler is managing. See the GetSSInfo service
description for details.
For each Socket Services handler located using the GetSSInfo request, the Socket Services client
performs a real-mode GetSetSSAddr request to determine the entry point to use for subsequent
Socket Services requests to the handler. Separate GetSetSSAddr requests are required for each
processor mode used by the Socket Services client. See the GetSetSSAddr service description for
details.
9.6.3 Installation Notification

If a Socket Services handler is installed after Card Services has loaded, the handler notifies Card
Services of its presence using Card Services AddSocketServices or ReplaceSocketServices requests.
How the Socket Services handler locates Card Services and makes Card Services requests is binding
specific. See the Card Services Specification for details.
9.6.4 Making Socket Services Requests

Until Card Services completes its installation, all Socket Services requests are made by placing the
appropriate values in the registers indicated below and performing an INT 1A H in real-mode. If a
Socket Services handler was installed prior to Card Services, requests made to the handler after
Card Services completes its initialization use the mode-specific entry point returned by
GetSetSSAddr as described above.
If a Socket Services handler is installed after Card Services, as described in the Installation
Notification Section above, Card Services uses the entry point provided with the arguments to the
Card Services AddSocketServices or ReplaceSocketServices requests.
9.6.5 Argument Passing

Two methods are used for passing arguments: directly in the CPU registers and in a packet that is
referenced by a binding specific pointer. The CPU register method is the standard method used
and is always available for backwards compatibility. The packet method is used with the entry-
point retrieved via GetSetSSAddr Subfunc=04h.
9.6.5.1 CPU Register Interface Usage

The Socket Services interface in the x86 environment passes arguments in registers using the
following guidelines:
Entry:
[AH] Service Desired
[AL] Adapter
[BH] Window
[BL] Page or Socket
[CX] Count
[DX] Attributes
[DS]:[(E)SI] Data Pointer Pointer to Socket Services data area, not required and ignored by real-mode Socket
Services requests. Card Services (the Socket Services client) determines the
appropriate value for protect-mode requests in one of two ways.
For each Socket Services handler installed before Card Services, this value is
determined by the information returned by a GetSetSSAddr request to the handler
made during presence detection operations.
For each Socket Services handler installed after Card Services, this value is
provided to Card Services by the Card Services AddSocketServices or
ReplaceSocketServices request used by each Socket Services handler to notify
Card Services of the handlerÕs presence.
For OS/2 and Windows 16-bit protect modes the [DS]:[SI] register pair are a
selector:offset pointer to the Socket Services data area. Windows 32-bit protect
mode (flat model) VxD clients pass the 32-bit offset of the Socket Services data
area in the [ESI] register.
[ES]:[(E)DI] Buffer Pointer to a data buffer for returning information to client.
For real-mode the [ES]:[DI] register pair are a segment:offset pointer to the buffer.
For OS/2 and Windows 16-bit protect modes the [ES]:[DI] register pair are a
selector:offset pointer to the buffer. For Windows 32-bit protect mode (flat model)
VxD clients the [EDI] register is the 32-bit offset of the buffer.
[DI] Offset Used by SetPage to set offset of PC CardÕs memory mapped into host system
memory space. Expressed in 4 KByte units.
Base Used by SetWindow to specify windowÕs base address in host system address
space. I/O window bases are expressed in bytes. Memory windows are expressed
in 4 KByte units.
Exit:
[CF] Status Set = error
Reset = success
If [CF] set
[AH] Non SUCCESS Return Code
else
[AH] SUCCESS Return Code
Please note that these are guidelines used to develop the service interfaces and exceptions have
been made for specific services. See the individual service bindings for the x86 architecture.
Whenever possible, the interface preserves the contents of all registers unless they are used to
return information. For bit-mapped fields, bits within a field (or register) are numbered beginning
with zero. Bit 0 is the least significant bit within the register.
For all services, the [CF] indicates whether the service was successful. If the [CF] is reset on exit, the
service was successful. If the [CF] is set on exit, the service failed. The [AH] register always contains
a RETCODE on exit. The only exception to this convention is determining the presence of Socket
Services with the GetAdapterCount service. There is no guarantee of the state of the [CF] or the
[AH] register if no Socket Services handler is present.
9.6.5.2 Packet Interface Usage
9.6.5.2.1 Overview
The packet interface passes parameters via a packet that is pointed to by a pointer on the stack. In
c-style notation, the entry point for the packet interface is defined as:
void SSPacketEntryPoint (FAR *fpArgPacket)
Note: The usage of a C-style function definition provides processor and mode
independence in the definition. Implementers using the packet interface
must take care in utilizing the correct mode.
For all packet entry point modes the parameters are passed in a packet that is generally structured
as shown below. Each entry mode binding (e.g. x86 real mode, OS/2, Win 16 and Win32) for
Socket Services has a separate section to illustrate the details of the packet for each. Where there are
differences, those are highlighted with shading.
Offset Size Description and Usage (RE: x86 register name)
0 2 Segment or Selector of Buffer (ES)
2 2 Segment or Selector of Data Pointer (DS)
4 4 Offset of Buffer ([E]DI)
8 4 Offset of Data Pointer ([E]SI)
12 4 Reserved (BP)
16 4 Reserved (SP)
20 1 Page or Socket (BL)
21 1 Window (BH)
22 2 Reserved (hi word EBX)
24 4 Attributes ([E]DX)
28 4 Count ([E]CX)
32 1 Adapter (AL)
33 1 Service Code and RETCODE (AH)
34 2 Reserved (hi word of EAX)
36 2 Reserved (IP)
38 2 Reserved (CS)
40 2 Status - bit 0 only, all others reserved (flags)
42 2 n = Additional Arguments Buffer Length
44 n Additional Arguments Buffer
The additional arguments are formatted where there is a control word before the data for the
argument and bit 0 of that control word is a Ôvalid/supportedÕ flag. This bit is set by Socket
Services to inform Card Services whether or not the feature is supported and that the data in the rest
of the argument is valid.
For example, lets imagine an additional argument named Foo that has two bytes of data. WeÕll use
offset of x for the start of this argument. Note that the actual purpose and data contents of 1 would
described in the functional portion of the Socket Services standard:
Offset Size Description and Usage
É É É
x 2 Control byte for Foo
Bit 0 = Supported/Valid
Bits 1-15 = Reserved
x+2 2 Foo
Please note that these are guidelines used to develop the service interfaces and exceptions have
been made for specific services. See the individual service bindings for the packet interface.
Whenever possible, the interface preserves the contents of all packet fields unless they are used to
return information. For bit-mapped fields, bits within a field are numbered beginning with zero.
Bit 0 is the least significant bit within the field.
For all services, bit 0 of the Status field (offset 40) indicates whether the service was successful. If this
bit is reset on exit, the service was successful. If this bit is set on exit, the service failed. The Return
Code field always contains a RETCODE on exit.
9.6.5.2.2 Packet Interface - real-mode x86

This packet is used when the Socket Services is running in x86 real mode. In this situation the
Buffer and Data Pointer arguments need x86 segments.
0 2 Segment of Buffer
2 2 Segment of Data Pointer
4 4 Offset of Buffer
8 4 Offset of Data Pointer
12 4 Reserved
16 4 Reserved
20 1 Page or Socket
21 1 Window
22 2 Reserved
24 4 Attributes
28 4 Count
32 1 Adapter
33 1 Service Code
34 2 Reserved
36 2 Reserved
38 2 Reserved
40 2 Status - bit 0 only, all others reserved
9.6.5.2.3 Packet Interface - OS/2

This packet is used when the Socket Services is running in OS/2 protected mode. In this situation
the Buffer and Data Pointer arguments need x86 selectors.

0 2 Selector of Buffer
2 2 Selector of Data Pointer
12 4 Reserved
16 4 Reserved
20 1 Page or Socket
21 1 Window
22 2 Reserved
24 4 Attributes
28 4 Count
32 1 Adapter
33 1 Service Code
34 2 Reserved
36 2 Reserved
38 2 Reserved
9.6.5.2.4 Packet Interface - Win-16

This packet is used when the Socket Services is running in Windows 16-bit protected mode. In this
situation the Buffer and Data Pointer arguments need x86 selectors.


0 2 Selector of Buffer
2 2 Selector of Data Pointer
12 4 Reserved
16 4 Reserved
20 1 Page or Socket
21 1 Window
22 2 Reserved
24 4 Attributes
28 4 Count
32 1 Adapter
33 1 Service Code
34 2 Reserved
36 2 Reserved
38 2 Reserved
9.6.5.2.5 Packet Interface - Win32 VxD

This packet is used when the Socket Services is running as a Windows protected mode VxD. In this
situation the Buffer and Data Pointer arguments are simple 32-bit pointers.
0 2 Reserved
2 2 Reserved
12 4 Reserved
16 4 Reserved
20 1 Page or Socket
21 1 Window
22 2 Reserved
24 4 Attributes
28 4 Count
32 1 Adapter
33 1 Service Code
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.6 Assumptions and Constraints

This section describes assumptions and constraints of the x86 architecture binding.
9.6.6.1 ROM BIOS Located

The Socket Services interface is intended to allow the handler to be located within an IBM-PC
compatible ROM BIOS. However, if Socket Services is not required for performing Initial Program
Load (IPL) or bootstrap loading, Socket Services may be implemented as a device driver or a
Terminate and Stay Resident (TSR) program.
9.6.6.2 Adapters Supported

The Socket Services interface allows multiple adapters containing one or more PC Card sockets.
Since the TotalAdaptors is passed in the eight-bit [AL] register the theoretical limit is two hundred
and fifty-five (255) adapters. However, the constraints imposed by locating Socket Services in ROM
BIOS may impose a smaller limit. The actual limit is vendor specific.
Adapters are numbered from zero (0) to the maximum (one less than the number of adapters
installed).
9.6.6.3 EDC Generators

Error Detection Code generators are optional. EDC generators are numbered from zero (0) to the
maximum (one less than the number returned by InquireAdapter).
9.6.6.4 Sockets Supported

The Socket Services interface allows multiple PC Card sockets per adapter. The socket number is
passed in the eight-bit [BL] register. However, due to the fact a bit-map of assignable sockets is used
in InquireWindow and in InquireEDC, the theoretical maximum is sixteen (16) sockets per adapter.
As with adapters, the constraints imposed by locating Socket Services in ROM BIOS may impose a
smaller limit on the number of sockets supported. An adapter may support any number of sockets,
from one to the theoretical maximum of sixteen. If a system has more than one adapter, each
adapter may support a different number of sockets.
Sockets are numbered from zero (0) to one less than the number installed with a maximum of
sixteen sockets per adapter.
9.6.6.5 Windows Supported

The Socket Services interface is designed without any assumptions about how or whether PC Cards
are mapped into the host systemÕs I/O or memory address space. This requires a mechanism to
indicate which windows can be mapped to a particular socket. Since the number of sockets per
adapter is limited to sixteen (16), the 16-bit [CX] register is used to indicate which sockets may be
mapped with a particular window.
Windows are numbered from zero (0) to the maximum (one less than the number available on the
adapter). Since the number of windows is returned in a byte-wide register, the theoretical
maximum number is two hundred and fifty-five (255). However, since windows are identified
starting with zero (0), the maximum window identifier is two hundred and fifty-four (254).

9.6.7 Individual Service Bindings
9.6.7.1 CPU Register Usage Bindings

The following sections describe how the individual services are bound when using the CPU register
binding for IBM-PC compatible architectures.
9.6.7.1.1 AccessConfigurationSpace
Entry:
[AH] ACCESS_CFG_SPACE
[AL] Adapter
[BH] Function 0⋅⋅7
[BL] Socket
[CH] Action Read = 00H
Write = 01H
[CL] Location On a four byte boundary
[EDX] Data
Exit:
[CF] Status set = error
reset = success
[AH] RETCODE
[EDX] Data
9.6.7.1.2 AcknowledgeInterrupt
Entry:
[AH] ACK_INTERRUPT
[AL] Adapter 0 .. Max_Adapter
Exit:
reset = success
[AH] RETCODE
[CX] Sockets

9.6.7.1.3 GetAccessOffsets
Entry:
[AH] ACCESS_OFFSETS
[AL] Adapter
[BH] Mode 00 = Real Mode
01 = 16:16 Protect
02 = 16:32 Protect
03 = 00:32 Protect
[CX] NumDesired
[ES]:[(E)DI] pBuffer
Exit:
reset = success
[AH] RETCODE
[DX] NumAvail
All modes return 16-bit offsets. These offsets need to be combined with information returned by
GetSSAddr describing the location of the code segment. Offsets returned by this service are relative
to the code segment.
For real-mode, 16:16 and 16:32, the routines at these offsets use FAR RET instructions to return to
the caller requiring they be invoked with a FAR CALL instruction. In 0:32 (flat) protect-mode, the
routines at the returned offsets use NEAR RET instructions and need to be invoked with a NEAR
CALL instruction.
9.6.7.1.4 GetAdapter
Entry:
[AH] GET_ADAPTER
[AL] Adapter
Exit:
reset = success
[AH] RETCODE
[DH] State Bit 0 = AS_POWERDOWN
Bit 1 = AS_MAINTAIN
[DI] SCRouting Bit 0⋅⋅4 = IRQ level
Bit 6 = IRQ_HIGH
Bit 7 = IRQ_ENABLED

9.6.7.1.5 GetAdapterCount
Entry:
[AH] GET_ADP_CNT
Exit:
reset = success
[AH] RETCODE
[AL] TotalAdapters If [CF] reset
[AH] is SUCCESS and Signature is 'SS'
[CX] Signature
Note: This service is used to determine if a Socket Services handler is installed in

the host system. The handler may share the Socket Services interrupt vector
with other, unrelated handlers. There is no guarantee these other, unrelated
handlers will properly reject a Socket Services GetAdapterCount request.
The client should confirm Signature contains 'SS' before using
TotalAdapters. It is suggested the client set Signature to a value other than
'SS' before invoking this service to insure the return value is from Socket
Services and not just left over in the register from prior client activity.
9.6.7.1.6 GetBridgeWindow
Entry:
[AH] GET_BWINDOW
[AL] Adapter
[BH] Window
Exit:
reset = success
[AH] RETCODE
[BL] Socket
[ECX] Size (Bytes)
[DH] State Bit 0 WS_IO
Bit 1 WS_ENABLED
Bit 3 WS_PREFETCH
Bits 3&4 WS_CACHABLE
Bits 2, 5..7 Reserved (reset to zero)
[EDI] Base (Bytes)
Note: If a bridge window is cachable, it is by definition prefetchable. For that

reason, cachable bridge windows return both Bits 3 and 4 of the State field
set to one.

9.6.7.1.7 GetEDC
Entry:
[AH] GET_EDC
[AL] Adapter
[BH] EDC
Exit:
reset = success
[AH] RETCODE
[BL] Socket
[DH] State Bit 0 = EC_UNI
Bit 1 = EC_WRITE
[DL] Type Bit 0 = ET_CHECK8
Bit 1 = ET_SDLC16
Bit 2 = ET_SDLC32
9.6.7.1.8 GetPage
Entry:
[AH] GET_PAGE
[AL] Adapter
[BH] Window
[BL] Page
Exit:
reset = success
[AH] RETCODE
[DL] State Bit 0 = PS_ATTRIBUTE
Bit 1 = PS_ENABLED
Bit 2 = PS_WP
[DI] Offset (4 KByte units)
9.6.7.1.9 GetSetPriorHandler
Entry:
[AH] PRIOR_HANDLER
[AL] Adapter
[BL] Mode 0 = Get
1 = Set
[CX]:[DX] pHandler
Exit:
reset = success
[AH] RETCODE
[CX]:[DX] pHandler

If this Socket Services handler is the first installed in the INT 1AH chain, the values returned by a
Get request should be the entry point of the Time of Day handler.
One reason a SetPriorHandler request would fail is the Socket Services it is addressing is in ROM
BIOS as the first extension to the Time of Day handler. In this case, the vector to the Time of Day
handler is probably hard-coded into the ROM BIOS and not in RAM prohibiting it from being
Services may be bypassed by registering the values returned from a GetPriorHandler request to
this Socket Services with a replacement Socket Services implementation.
9.6.7.1.10 GetSetSSAddr
Entry:
[AH] SS_ADDR
[AL] Adapter
[BH] Mode 00 = Real Mode
01 = 16:16 Protect
02 = 16:32 Protect
03 = 00:32 Protect
[BL] Subfunc
[CX] NumAddData
Exit:
reset = success
[AH] RETCODE
[CX] NumAddData
The entry points returned by this service must receive control from a CALL instruction. The real,
16:16 and 16:32 entry points require a FAR CALL instruction to be used. The 00:32 entry point
requires a NEAR CALL. When using an entry point returned by this service for any mode other
than real, the client must establish a pointer to the main data area in [DS]:[(E)SI].
Note: Subfunc 02 is invalid, if the desired processor mode is 00 indicating real-
mode.
WA R N IN G :
Any [CS] selector created should be readable in addition to being executable to

allow a Socket Services implementation to reference constant data which may
reside in a ROM-ed code segment. The client must also insure that Socket
Services has the appropriate privileges to allow I/O port access.
Mode specific comments have been added to the buffer entry descriptions in the tables below:

When Subfunc is zero (0):

04H Double Word Limit of code segmentÑMust be less than 64K in real and 16:16 protect-mode
08H Double Word Entry point offsetÑMust be less than 64K in real and 16:16 protect-mode
0CH Double Word 32-bit linear base address of main data segment in system memoryÑIgnored for 0:32
(flat) protect-mode
10H Double Word Limit of data segmentÑMust be less than 64K in real and 16:16 protect-mode
14H Double Word Data area offsetÑOnly used for 32-bit protect-modes
When Subfunc is one (1):

00H Double Word 32-bit linear base address of additional data segmentÑIgnored for 0:32 (flat) protect-
mode
When Subfunc is two (2):

00H Double Word 32-bit offsetÑIgnored for 16:16 protect-modes (which assumes zero)
04H Double Word SelectorÑIgnored for 0:32 (flat) protect-mode
When Subfunc is four (4):

08H Double Word Entry point offset (entry point that utilizes the packet interface)ÑMust be less than 64K in
real and 16:16 protect-mode
(flat) protect-mode

9.6.7.1.11 GetSocket
Entry:
[AH] GET_SOCKET
[AL] Adapter
[BL] Socket
Exit:
reset = success
[AH] RETCODE
[BH] SCIntMask (Uses the same bit masks as InquireSocket)
[CH] Lower Nibble = VccLevel
Upper Nibble = Vcontrol
Bit 4 = VCTL_CISREAD
Bit 5 = VCTL_OVERRIDE
Bit 6áá7 = Voltage Sense Signaling (read-only)
0 = VCTL_5V
1 = VCTL_33V
2 = VCTL_XXV
3 = Reserved (not used)
[CL] VppLevels Lower Nibble = VPP2
Upper Nibble = VPP1
[DH] State (Uses same bit masks as SCIntMask)
[DL] CtlInd (Uses same bit masks as InquireSocket)
[DI] Low Byte = IREQRouting
High Byte = IFType
Bit 0áá4 IRQ level
Bit 5 RESERVED
Bit 6 IRQ_HIGH
Bit 7 IRQ_ENABLE
Bit 8áá9 Interface type
0 = IF_CARDBUS,
1 = IF_MEMORY
2 = IF_IO
3 = IF_CUSTOM
Bits 10áá11 DREQ
0 = No DMA
1 = SPKR#
2 = IOIS16#
3 = INPACK#
Bits 12áá15 DMA Channel (0áá15)
[BP] IFIndex Index of custom interface when IFType = IF_CUSTOM

9.6.7.1.12 GetSSInfo
Entry:
[AH] GET_SS_INFO
[AL] Adapter
Exit:
reset = success
[AH] RETCODE
[AL] Zero (0) Insures backward compatibility with Release 1.01
[BX] Compliance
[CH] NumAdapters
[CL] FirstAdapter
9.6.7.1.13 GetStatus
Entry:
[AH] GET_STATUS
[AL] Adapter
[BL] Socket
Exit:
reset = success
[AH] RETCODE
[BH] CardState (same bit-masks as GetSocket SCIntMask)
[DH] SocketState (same as GetSocket)
[DL] CtlInd (same as GetSocket)
[DI] High Byte = IFType
Low Byte = IREQRouting
(same as GetSocket)
9.6.7.1.14 GetVendorInfo
Entry:
[AH] GET_VENDOR_INFO
[AL] Adapter
[BL] Type
Exit:
reset = success
[AH] RETCODE
[DX] Release

9.6.7.1.15 GetWindow
Entry:
[AH] GET_WINDOW
[AL] Adapter
[BH ] Window
Exit:
reset = success
[AH] RETCODE
[BL] Socket and parameter width
Bit 0áá3 = Socket Number
Bit 4 = Size and Base width
0 = 16 bits
1 = 32 bits
[(E)CX] Size If bit 4 of [BL] is reset, I/O windows are expressed in bytes, memory windows
are expressed in 4 KByte units and [CX] is used.
If bit 4 of [BL] is set, both I/O and memory windows are expressed in bytes and
[ECX] is used.
[DH] State Bit 0 = WS_IO
Bit 1 = WS_ENABLED
Bit 2 = WS_16BIT
Bit 3 = WS_PAGED (Memory window) or WS_EISA (I/O window)
Bit 4 = WS_CENABLE (I/O window with WS_EISA set)
[DL] Speed
[(E)DI] Base If bit 4 of [BL] is reset, I/O windows are expressed in bytes, memory windows
are expressed in 4 KByte units and [DI] is used.
If bit 4 of [BL] is set, both I/O and memory windows are expressed in bytes and
[EDI] is used.
9.6.7.1.16 InquireAdapter
Entry:
[AH] INQ_ADAPTER
[AL] Adapter
[ES]:[(E)DI] pBuffer for adapter characteristics and power levels
Exit:
reset = success
[AH] RETCODE
[BH] NumWindows
[BL] NumSockets
[CX] NumEDCs
[DX] NumBridgeWindows
[ES]:[(E)DI] pBuffer with adapter characteristics and power management tables

9.6.7.1.17 InquireBridgeWindow
Entry:
[AH] INQ_BWINDOW
[AL] Adapter
[BH] Window
[ES]:[(E)DI] pBuffer for window characteristics
Exit:
reset = success
[AH] RETCODE
[BL] WndCaps Bit 0 = WC_MEMORY
Bit 1 = Reserved (reset to zero)
Bit 2 = WC_IO
Bit 3áá7 = Reserved (reset to zero)
[CX] Sockets Bit 0áá15 = Bit-mask
Bit 0 is Socket 0
Bit 1 is Socket 1
etc.
[ES]:[(E)DI] pBuffer with window characteristics
Note: All BASE and SIZE values in the BIOWINTBL and BMEMWINTBL
structures returned by this service are 32-bits wide. That is, the BASE32 and
WSIZE32 data types are used for BASE and SIZE values.
9.6.7.1.18 InquireEDC
Entry:
[AH] INQ_EDC
[AL] Adapter
[BH] EDC
Exit:
reset = success
[AH] RETCODE
Bit 0 is Socket 0
Bit 1 is Socket 1
etc.
[DH] Caps Bit 0 = EC_UNI
Bit 1 = EC_BI
Bit 2 = EC_REGISTER
Bit 3 = EC_MEMORY
Bit 4 = EC_PAUSABLE
[DL] Types Bit 0 = ET_CHECK8
Bit 1 = ET_SDLC16
Bit 2 = ET_SDLC32

9.6.7.1.19 InquireSocket
Entry:
[AH] INQ_SOCKET
[AL] Adapter
[BL] Socket
[ES]:[(E)DI] pBuffer for socket characteristics
Exit:
reset = success
[AH] RETCODE
[BH] SCIntCaps Bit 0 = SBM_WP
Bit 1 = SBM_LOCKED
Bit 2 = SBM_EJECT
Bit 3 = SBM_INSERT
Bit 4 = SBM_BVD1
Bit 5 = SBM_BVD2
Bit 6 = SBM_RDYBSY
Bit 7 = SBM_CD
[DH] SCRptCaps (same as SCIntCaps)
[DL] CtlIndCaps Bit 0 = SBM_WP
Bit 1 = SBM_LOCKED
Bit 2 = SBM_EJECT
Bit 3 = SBM_INSERT
Bit 4 = SBM_LOCK
Bit 5 = SBM_BATT
Bit 6 = SBM_BUSY
Bit 7 = SBM_XIP
[ES]:[(E)DI] pBuffer with socket characteristics
9.6.7.1.20 InquireWindow
Entry:
[AH] INQ_WINDOW
[AL] Adapter
[BH] Window if [BH] is 0FFH then Window is passed in [DH] and the window characteristics
returned in the Buffer use 32-bit wide values for BASE and SIZE
[DH] Window if [BH] is 0FFH, otherwise undefined
[ES]:[(E)DI] pBuffer for window characteristics
Exit:
reset = success
[AH] RETCODE
[BL] WndCaps Bit 0 = WC_COMMON
Bit 1 = WC_ATTRIBUTE
Bit 2 = WC_IO
Bit 7 = WC_WAIT
Bit 0 is Socket 0
Bit 1 is Socket 1
etc.
[ES]:[(E)DI] pBuffer with window characteristics

Note: The data types used for the BASE and SIZE values in the IOWINTBL and
MEMWINTBL structures returned by this service vary depending on the
value passed in the [BH] register.
If [BH] is not FFH, the BASE and SIZE values are 16-bits wide using the
BASE16 and WSIZE16 data types. When [BH] is not FFH, BASE and SIZE
values in the IOWINTBL structure are expressed in bytes and BASE and
SIZE values in the MEMWINTBL structure are expressed in 4 KByte units.
If [BH] is FFH, the BASE and SIZE values are 32-bits wide using the BASE32
and WSIZE32 data types. When [BH] is FFH, BASE and SIZE values in both
the IOWINTBL and MEMWINTBL structures are expressed in bytes.
This encoding allows backward compatibility with prior releases of the
Socket Services binding for this service that only used 16-bit values for
BASE and SIZE.
9.6.7.1.21 PauseEDC
Entry:
[AH] PAUSE_EDC
[AL] Adapter
[BH] EDC
Exit:
reset = success
[AH] RETCODE
9.6.7.1.22 ReadEDC
Entry:
[AH] READ_EDC
[AL] Adapter
[BH] EDC
Exit:
reset = success
[AH] RETCODE
[DX] Value
9.6.7.1.23 ResetSocket
Entry:
[AH] RESET_SOCKET
[AL] Adapter
[BL] Socket
Exit:
reset = success
[AH] RETCODE

9.6.7.1.24 ResumeEDC
Entry:
[AH] RESUME_EDC
[AL] Adapter
[BH] EDC
Exit:
reset = success
[AH] RETCODE
9.6.7.1.25 SetAdapter
Entry:
[AH] SET_ADAPTER
[AL] Adapter
[DH] State (same as GetAdapter)
[DI] SCRouting (same as GetAdapter)
Exit:
reset = success
[AH] RETCODE
9.6.7.1.26 SetBridgeWindow
Entry:
[AH] GET_BWINDOW
[AL] Adapter
[BH] Window
[BL] Socket
[ECX] Size (Bytes)
[DH] State (Same as GetBridgeWindow)
[EDI] Base (Bytes)
Exit:
reset = success
[AH] RETCODE

9.6.7.1.27 SetEDC
Entry:
[AH] SET_EDC
[AL] Adapter
[BH] EDC
[BL] Socket
[DH] State (same as GetEDC)
[DL] Type (same as GetEDC)
Exit:
reset = success
[AH] RETCODE
9.6.7.1.28 SetPage
Entry:
[AH] SET_PAGE
[AL] Adapter
[BH] Window
[BL] Page
[DH] State (same as GetPage)
[DI] Offset (4 KByte units)
Exit:
reset = success
[AH] RETCODE

9.6.7.1.29 SetSocket
Entry:
[AH] SET_SOCKET
[AL] Adapter
[BL] Socket
[BH] SCIntMask (same as GetSocket)
[CH] Vcontrol (same as GetSocket)
[CL] VppLevels (same as GetSocket
[DH] State (same as GetSocket)
[DL] CtlInd (same as GetSocket)
[DI] High Byte = IFType
(same as GetSocket), plus:
Bit 5 IRQ_INVALID
[BP] IFIndex Index of custom interface when IFType = IF_CUSTOM
(same as GetSocket)
Exit:
reset = success
[AH] RETCODE
9.6.7.1.30 SetWindow
Entry:
[AH] SET_WINDOW
[AL] Adapter
[BH] Window
[BL] Socket
[CX] Size (same as GetWindow)
[DH] State (same as GetWindow)
[DL] Speed
[DI] Base (same as GetWindow)
Exit:
reset = success
[AH] RETCODE
9.6.7.1.31 StartEDC
Entry:
[AH] START_EDC
[AL] Adapter
[BH] EDC
Exit:
reset = success
[AH] RETCODE

9.6.7.1.32 StopEDC
Entry:
[AH] STOP_EDC
[AL] Adapter
[BH] EDC
Exit:
reset = success
[AH] RETCODE
9.6.7.1.33 VendorSpecific
Entry:
[AH] VEND_SPECIFIC
[AL] Adapter
All other registers are vendor specific.
Exit:
reset = success
[AH] RETCODE

9.6.7.2 Packet Usage Bindings

The following sections describe how the individual services are bound when using the packet
binding. Specifically, the packets are used as described in 9.6.5.2 Packet Interface Usage and these
sections describe only extensions or differences. When a parameter or field is different for entry and
exit then the syntax of 'entry/exit' is used for differentiation in the desciption.
9.6.7.2.1 AccessConfigurationSpace
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Socket
21 1 Function (0..7 only)
22 2 Reserved
24 4 Data
28 1 Location (on a four byte boundary)
29 1 Action (Read = 00h, Write = 01h)
30 2 Reserved
32 1 Adapter
33 1 ACCESS_CFG_SPACE and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
42 2 0 = Additional Arguments Buffer Length
44 0 Additional Arguments Buffer

9.6.7.2.2 AcknowledgeInterrupt
0 2 Segment or Selector of Buffer
2 2 Segment or Selector of Data Pointer
12 4 Reserved
16 4 Reserved
20 1 Page or Socket
21 1 Window
22 2 Reserved
24 4 Attributes
28 4 Reserved / Sockets
32 1 Adapter
33 1 ACK_INTERRUPT and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.3 GetAccessOffsets
Offset Size Description and Usage (RE: x86 register name)
0 2 Segment or Selector of pBuffer (ES)
2 2 Reserved
4 4 Offset of pBuffer
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 Mode
00 = Real Mode
01 = 16:16 Protect
02 = 16:32 Protect
03 = 00:32 Protect
22 2 Reserved
24 4 Reserved
28 4 NumDesired
32 1 Adapter
33 1 ACCESS_OFFSETS and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
All modes return 16-bit offsets. These offsets need to be combined with information returned by
GetSSAddr describing the location of the code segment. Offsets returned by this service are relative
to the code segment.
For real-mode, 16:16 and 16:32, the routines at these offsets use FAR RET instructions to return to
the caller requiring they be invoked with a FAR CALL instruction. In 0:32 (flat) protect-mode, the
routines at the returned offsets use NEAR RET instructions and need to be invoked with a NEAR
CALL instruction.

9.6.7.2.4 GetAdapter
0 2 Reserved
2 2 Reserved
4 4 Reserved / SCRouting
Bit 0⋅⋅4 = IRQ level
Bit 6 = IRQ_HIGH
Bit 7 = IRQ_ENABLED
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 Reserved
22 2 Reserved
24 1 Reserved
25 1 Reserved / State:
Bit 0 = AS_POWERDOWN
Bit 1 = AS_MAINTAIN
26 2 Reserved
28 4 Reserved
32 1 Adapter
33 1 GET_ADAPTER and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.5 GetAdapterCount
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 Reserved
22 2 Reserved
24 4 Reserved
28 4 Reserved / Signature
32 1 Reserved / TotalAdapters (if Status bit 0 reset then RETCODE=SUCCESS and Signature is
ÕSSÕ)
33 1 GET_ADP_CNT and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
Note: This service is used to determine if a Socket Services handler is installed in

the host system. The handler may share the Socket Services interrupt vector
with other, unrelated handlers. There is no guarantee these other, unrelated
handlers will properly reject a Socket Services GetAdapterCount request.
The client should confirm Signature contains 'SS' before using
TotalAdapters. It is suggested the client set Signature to a value other than
'SS' before invoking this service to insure the return value is from Socket
Services and not just left over in the register from prior client activity.

9.6.7.2.6 GetBridgeWindow
0 2 Reserved
2 2 Reserved
4 4 Reserved / Base (Bytes)
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved / Socket
21 1 Reserved / Window
22 2 Reserved
24 1 Reserved
Bit 0 WS_IO
Bit 1 WS_ENABLED
Bit 3 WS_PREFETCH
Bits 3&4 WS_CACHABLE
Bits 2, 5..7 Reserved (reset to zero)
26 2 Reserved
28 4 Reserved / Size
32 1 Adapter
33 1 GET_BWINDOW and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
Note: If a bridge window is cachable, it is by definition prefetchable. For that

reason, cachable bridge windows return both Bits 3 and 4 of the State field
set to one.

9.6.7.2.7 GetEDC
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved / Socket
21 1 EDC
22 2 Reserved
24 1 Reserved / Type:
Bit 0 = ET_CHECK8
Bit 1 = ET_SDLC16
Bit 2 = ET_SDLC32
Bit 0 = EC_UNI
Bit 1 = EC_WRITE
24 4 Reserved
28 4 Reserved
32 1 Adapter
33 1 GET_EDC and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.8 GetPage
0 2 Reserved
2 2 Reserved
4 4 Reserved / Offset
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Page
21 1 Window
22 2 Reserved
Bit 0 = PS_ATTRIBUTE
Bit 1 = PS_ENABLED
Bit 2 = PS_WP
25 1 Reserved
26 2 Reserved
28 4 Reserved
32 1 Adapter
33 1 GET_PAGE and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.9 GetSetPriorHandler
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Mode:
0 = Get
1 = Set
21 1 Reserved
22 2 Reserved
24 8 pHandler
32 1 Adapter
33 1 PRIOR_HANDLER and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
If this Socket Services handler is the first installed in the INT 1AH chain, the values returned by a
Get request should be the entry point of the Time of Day handler.
One reason a SetPriorHandler request would fail is the Socket Services it is addressing is in ROM
BIOS as the first extension to the Time of Day handler. In this case, the vector to the Time of Day
handler is probably hard-coded into the ROM BIOS and not in RAM prohibiting it from being
Services may be bypassed by registering the values returned from a GetPriorHandler request to
this Socket Services with a replacement Socket Services implementation.

9.6.7.2.10 GetSetSSAddr
0 2 Segment or Selector of pBuffer
2 2 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Subfunc
21 1 Mode:
00 = Real Mode
01 = 16:16 Protect
02 = 16:32 Protect
03 = 00:32 Protect
22 2 Reserved
24 4 Reserved
28 4 NumAddData
32 1 Adapter
33 1 SS_ADDR and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
The entry points returned by this service must receive control from a CALL instruction. The real,
16:16 and 16:32 entry points require a FAR CALL instruction to be used. The 00:32 entry point
requires a NEAR CALL. When using an entry point returned by this service for any mode other
than real, the client must establish a pointer to the main data area in offsets 2 and 8.
Note: Subfunc 02 is invalid, if the desired processor mode is 00 indicating real-
mode.
WA R N IN G :
Any Code Segment selector created should be readable in addition to being

executable to allow a Socket Services implementation to reference constant data
which may reside in a ROM-ed code segment. The client must also insure that
Socket Services has the appropriate privileges to allow I/O port access.
Mode specific comments have been added to the buffer entry descriptions in the tables below:

When Subfunc is zero (0):

08H Double Word Entry point offsetÑMust be less than 64K in real and 16:16 protect-mode
(flat) protect-mode
When Subfunc is one (1):

00H Double Word 32-bit linear base address of additional data segmentÑIgnored for 0:32 (flat) protect-
mode
When Subfunc is two (2):

00H Double Word 32-bit offsetÑIgnored for 16:16 protect-modes (which assumes zero)
04H Double Word SelectorÑIgnored for 0:32 (flat) protect-mode

9.6.7.2.11 GetSocket
0 2 Reserved
2 2 Reserved
4 2 Reserved / Low Byte = IREQRouting
High Byte = IFType
Bit 0áá4 IRQ level
Bit 5 RESERVED
Bit 6 IRQ_HIGH
Bit 7 IRQ_ENABLE
Bit 8áá9 Interface type
0 = IF_CARDBUS,
1 = IF_MEMORY
2 = IF_IO
3 = IF_CUSTOM
Bits 10áá11 DREQ
0 = No DMA
1 = SPKR#
2 = IOIS16#
3 = INPACK#
Bits 12áá15 DMA Channel (0áá15)
6 2 Reserved
8 4 Reserved
12 4 Reserved / IFIndex (Index of custom interface when IFType = IF_CUSTOM)
16 4 Reserved
20 1 Socket
21 1 Reserved / SCIntMask (Uses the same bit masks as InquireSocket)
22 2 Reserved
24 1 Reserved / CtlInd (Uses same bit masks as InquireSocket)
25 1 Reserved / State (Uses same bit masks as InquireSocket)
26 2 Reserved
28 1 Reserved / Vpp Levels:
Lower Nibble = VPP2
Upper Nibble = VPP1
29 1 Reserved / Lower Nibble = VccLevel

Upper Nibble = Vcontrol
Bit 4 = VCTL_CISREAD
Bit 5 = VCTL_OVERRIDE
Bit 6áá7 = Voltage Sense Signaling (read-only)
0 = VCTL_5V
1 = VCTL_33V
2 = VCTL_XXV
3 = Reserved (not used)
30 2 Reserved
32 1 Adapter
33 1 GET_SOCKET and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.12 GetSSInfo
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 2 Reserved / Compliance
22 2 Reserved
24 4 Reserved
28 1 Reserved / FirstAdapter
29 1 Reserved / NumAdapters
30 2 Reserved
32 1 Adapter / Zero (0) (will be zero on return for compatibility)
33 1 GET_SS_INFO and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.13 GetStatus
0 2 Reserved
2 2 Reserved
4 2 Reserved / Interface and IREQ Routing
High Byte = IFType
(same as GetSocket)
6 2 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Socket
21 1 Reserved / CardState (same bit mask as GetSocket SCIntMask)
22 2 Reserved
24 1 Reserved / CtlInd (Same as GetSocket)
25 1 Reserved / SocketState (same as GetSocket)
26 2 Reserved
28 4 Reserved
32 1 Adapter
33 1 GET_STATUS and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.14 GetVendorInfo
2 2 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Type
21 1 Reserved
22 2 Reserved
24 2 Reserved / Release
26 2 Reserved
28 4 Reserved
32 1 Adapter
33 1 GET_VENDOR_INFO and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.15 GetWindow
0 2 Reserved
2 2 Reserved
4 4 Reserved / Base: If bit 4 of the Socket field (offset 20) is reset, I/O windows are expressed in
bytes, memory windows are expressed in 4 Kbyte units and only the low 16-bits are used for
Base.
If bit 4 of the Socket field (offset 20) is set, both I/O and memory windows are expressed in
bytes and all 32-bits of Base is used.
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved / Socket and parameter width
Bit 0áá3 = Socket Number
Bit 4 = Size and Base width
0 = 16 bits
1 = 32 bits
21 1 Window
22 2 Reserved
24 1 Reserved / Speed
Bit 0 = WS_IO
Bit 1 = WS_ENABLED
Bit 2 = WS_16BIT
Bit 3 = WS_PAGED (Memory window) or WS_EISA (I/O window)
Bit 4 = WS_CENABLE (I/O window with WS_EISA set)
24 2 Reserved
28 4 Reserved / Size: If bit 4 of the Socket field (offset 20) is reset, I/O windows are expressed in
bytes, memory windows are expressed in 4 Kbyte units and only 16 bits is used for Size.
If bit 4 of the Socket field (offset 20) is set, both I/O and memory windows are expressed in
bytes and 32 bits are used for Size.
32 1 Adapter
33 1 GET_WINDOW and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.16 InquireAdapter
2 2 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved / NumSockets
21 1 Reserved / NumWindows
22 2 Reserved
24 4 Reserved / NumBridgeWindows
28 4 Reserved / NumEDCs
32 1 Adapter
33 1 INQ_ADAPTER and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.17 InquireBridgeWindow
2 2 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved / WndCaps:
Bit 0 = WC_MEMORY
Bit 1 = Reserved (reset to zero)
Bit 2 = WC_IO
Bit 3áá7 = Reserved (reset to zero)
21 1 Window
22 2 Reserved
24 4 Reserved
28 4 Reserved / Sockets:
Bit 0áá15 = Bit-mask
Bit 0 is Socket 0
Bit 1 is Socket 1
etc.
32 1 Adapter
33 1 INQ_BWINDOW and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
Note: All BASE and SIZE values in the BIOWINTBL and BMEMWINTBL
structures returned by this service are 32-bits wide. That is, the BASE32 and
WSIZE32 data types are used for BASE and SIZE values.

9.6.7.2.18 InquireEDC
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 EDC
22 2 Reserved
24 1 Reserved / Types:
Bit 0 = ET_CHECK8
Bit 1 = ET_SDLC16
Bit 2 = ET_SDLC32
25 1 Reserved / Caps:
Bit 0 = EC_UNI
Bit 1 = EC_BI
Bit 2 = EC_REGISTER
Bit 3 = EC_MEMORY
Bit 4 = EC_PAUSABLE
24 4 Reserved
28 4 Reserved / Sockets: Bit Mask
32 1 Adapter
33 1 INQ_EDC and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.19 InquireSocket
2 2 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Socket
21 1 Reserved / SCIntCaps:
Bit 0 = SBM_WP
Bit 1 = SBM_LOCKED
Bit 2 = SBM_EJECT
Bit 3 = SBM_INSERT
Bit 4 = SBM_BVD1
Bit 5 = SBM_BVD2
Bit 6 = SBM_RDYBSY
Bit 7 = SBM_CD
22 2 Reserved
24 1 Reserved / CtlIndCaps:
Bit 0 = SBM_WP
Bit 1 = SBM_LOCKED
Bit 2 = SBM_EJECT
Bit 3 = SBM_INSERT
Bit 4 = SBM_LOCK
Bit 5 = SBM_BATT
Bit 6 = SBM_BUSY
Bit 7 = SBM_XIP
25 1 Reserved / SCRptCaps (same as SCIntCaps)

24 2 Reserved
28 4 Reserved
32 1 Adapter
33 1 INQ_SOCKET and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.20 InquireWindow
2 2 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved / WndCaps:
Bit 0 = WC_COMMON
Bit 1 = WC_ATTRIBUTE
Bit 2 = WC_IO
Bit 7 = WC_WAIT
21 1 Window: if this field value is 0FFH then Window is passed in offset 25 and the window
characteristics returned in the Buffer use 32-bit wide values for BASE and SIZE
22 2 Reserved
24 1 Reserved
25 1 Window If offset 21 is 0FFH else Reserved
24 2 Reserved
28 4 Reserved / Sockets:
Bit 0áá15 = Bit-mask
Bit 0 is Socket 0
Bit 1 is Socket 1
etc.
32 1 Adapter
33 1 INQ_WINDOW and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
Note: The data types used for the BASE and SIZE values in the IOWINTBL and
MEMWINTBL structures returned by this service vary depending on the
value passed in the Window (offset 21) field.
If the Window (offset 21) field is not FFH, the BASE and SIZE values are 16-
bits wide using the BASE16 and WSIZE16 data types. When the Window
(offset 21) field is not FFH, BASE and SIZE values in the IOWINTBL
structure are expressed in bytes and BASE and SIZE values in the
MEMWINTBL structure are expressed in 4 KByte units.
If the Window (offset 21) field is FFH, the BASE and SIZE values are 32-bits
wide using the BASE32 and WSIZE32 data types. When the Window (offset
21) field is FFH, BASE and SIZE values in both the IOWINTBL and
MEMWINTBL structures are expressed in bytes.
This encoding allows backward compatibility with prior releases of the
Socket Services for this service that only used 16-bit values for BASE and
SIZE.

9.6.7.2.21 PauseEDC
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 EDC
22 2 Reserved
24 4 Reserved
28 4 Reserved
32 1 Adapter
33 1 PAUSE_EDC and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
9.6.7.2.22 ReadEDC
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 EDC
22 2 Reserved
24 4 Reserved / Value
28 4 Reserved
32 1 Adapter
33 1 READ_EDC and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.23 ResetSocket
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Socket
21 1 Reserved
22 2 Reserved
24 4 Reserved
28 4 Reserved
32 1 Adapter
33 1 RESET_SOCKET and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
9.6.7.2.24 ResumeEDC
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 EDC
22 2 Reserved
24 4 Value
28 4 Reserved
32 1 Adapter
33 1 RESUME_EDC and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.25 SetAdapter
0 2 Reserved
2 2 Reserved
4 4 SCRouting (same as GetAdapter)
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 Reserved
22 2 Reserved
24 1 State (same as in GetAdapter)
25 1 Reserved
26 2 Reserved
28 4 Reserved
32 1 Adapter
33 1 SET_ADAPTER and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.26 SetBridgeWindow
0 2 Reserved
2 2 Reserved
4 4 Base
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Socket
21 1 Window
22 2 Reserved
24 1 State (same as in GetBridgeWindow)
25 1 Reserved
26 2 Reserved
28 4 Size (bytes)
32 1 Adapter
33 1 SET_BWINDOW and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.27 SetEDC
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Socket
21 1 Reserved
22 2 Reserved
24 1 Type (same as in GetEDC)
25 1 State (same as in GetEDC)
26 2 Reserved
28 4 Reserved
32 1 Adapter
33 1 SET_EDC and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.28 SetPage
0 2 Reserved
2 2 Reserved
4 4 Offset
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Page
21 1 Window
22 2 Reserved
24 1 State: (same as in GetPage)
25 1 Reserved
26 2 Reserved
28 4 Reserved
32 1 Adapter
33 1 SET_PAGE and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.29 SetSocket
0 2 Reserved
2 2 Reserved
4 2 High Byte = IFType
(same as GetSocket), plus:
Bit 5 IRQ_INVALID
6 2 Reserved
8 4 Reserved
12 4 IFIndex (same as in GetSocket)
16 4 Reserved
20 1 Socket
21 1 SCIntMask (same as in GetSocket)
22 2 Reserved
24 1 CtlInd (same as in GetSocket)
25 1 State (same as in GetSocket)
26 2 Reserved
28 1 VppLevels: (same as in GetSocket)
29 1 VControl (same as in GetSocket)
30 2 Reserved
32 1 Adapter
33 1 SET_SOCKET and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.30 SetWindow
0 2 Reserved
2 2 Reserved
4 4 Base (same as in GetWindow)
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Socket (same as in GetWindow)
21 1 Window
22 2 Reserved
24 1 Speed
25 1 State (same as in GetWindow)
24 2 Reserved
28 4 Size (same as in GetWindow)
32 1 Adapter
33 1 SET_WINDOW and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.31 StartEDC
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 EDC
22 2 Reserved
24 4 Reserved
28 4 Reserved
32 1 Adapter
33 1 START_EDC and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved
9.6.7.2.32 StopEDC
0 2 Reserved
2 2 Reserved
4 4 Reserved
8 4 Reserved
12 4 Reserved
16 4 Reserved
20 1 Reserved
21 1 EDC
22 2 Reserved
24 4 Reserved
28 4 Reserved
32 1 Adapter
33 1 STOP_EDC and RETCODE
34 2 Reserved
36 2 Reserved
38 2 Reserved

9.6.7.2.33 VendorSpecific
0 2 Vendor Specific
2 2 Vendor Specific
4 4 Vendor Specific
8 4 Vendor Specific
12 4 Reserved
16 4 Reserved
20 1 Vendor Specific
32 1 Adapter
33 1 VEND_SPECIFIC and RETCODE
36 2 Reserved
38 2 Reserved
42 2 n = Additional Arguments Buffer Length (vendor specific)
44 n Additional Arguments Buffer - Vendor Specific

9.6.8 Assembly Language Definitions

This section contains suggested assembly language definitions for values required by clients of the
Socket Services interface.
; The following definitions are formatted for Microsoft MASM 6.0.
; ----- Service definitions
GET_ADP_CNT EQU 80H

; 81H and 82H reserved for historical purposes
GET_SS_INFO EQU 83H
INQ_ADAPTER EQU 84H
GET_ADAPTER EQU 85H
SET_ADAPTER EQU 86H
INQ_WINDOW EQU 87H
GET_WINDOW EQU 88H
SET_WINDOW EQU 89H
GET_PAGE EQU 8AH
SET_PAGE EQU 8BH
INQ_SOCKET EQU 8CH
GET_SOCKET EQU 8DH
SET_SOCKET EQU 8EH
GET_STATUS EQU 8FH
RESET_SOCKET EQU 90H
; 91H thru 94H reserved for historical purposes
INQ_EDC EQU 95H
GET_EDC EQU 96H
SET_EDC EQU 97H
START_EDC EQU 98H
PAUSE_EDC EQU 99H
RESUME_EDC EQU 9AH
STOP_EDC EQU 9BH
READ_EDC EQU 9CH
GET_VENDOR_INFO EQU 9DH
ACK_INTERRUPT EQU 9EH
PRIOR_HANDLER EQU 9FH
SS_ADDR EQU 0A0H
ACCESS_OFFSETS EQU 0A1H
ACCESS_CONFIG EQU 0A2H
INQ_BWINDOW EQU 0A3H
GET_BWINDOW EQU 0A4H
SET_BWINDOW EQU 0A5H
; A6H thru ADH are reserved for expansion
VEND_SPECIFIC EQU 0AEH
CARD_SERVICES EQU 0AFH
SS_INT EQU 1AH ; Socket Services Int vector

; ----- Return codes
SUCCESS EQU 00H

BAD_ADAPTER EQU 01H
BAD_ATTRIBUTE EQU 02H
BAD_BASE EQU 03H
BAD_EDC EQU 04H
; 05H reserved for historical purposes
BAD_IRQ EQU 06H
BAD_OFFSET EQU 07H
BAD_PAGE EQU 08H
READ_FAILURE EQU 09H
BAD_SIZE EQU 0AH
BAD_SOCKET EQU 0BH
; 0CH is reserved for historical purposes
BAD_TYPE EQU 0DH
BAD_VCC EQU 0EH
BAD_VPP EQU 0FH
; 10H is reserved for historical purposes
BAD_WINDOW EQU 11H
WRITE_FAILURE EQU 12H
; 13H is reserved for historical purposes
NO_CARD EQU 14H
BAD_SERVICE EQU 15H
BAD_MODE EQU 16H
BAD_SPEED EQU 17H
BUSY EQU 18H
; ----- Defined data types
ADAPTER TYPEDEF BYTE

BASE16 TYPEDEF WORD
BASE32 TYPEDEF DWORD
BCD TYPEDEF WORD
COUNT TYPEDEF BYTE
EDC TYPEDEF BYTE
FLAGS8 TYPEDEF BYTE
FLAGS16 TYPEDEF WORD
FLAGS32 TYPEDEF DWORD
IRQ TYPEDEF BYTE
COFFSET TYPEDEF WORD ; OFFSET is reserved by MASM 6.0
WPAGE TYPEDEF BYTE ; PAGE is reserved by MASM 6.0
PWRINDEX TYPEDEF BYTE
RETCODE TYPEDEF BYTE
SIGNATURE TYPEDEF WORD
WSIZE16 TYPEDEF WORD ; SIZE is reserved by MASM 6.0
WSIZE32 TYPEDEF DWORD
SOCKET TYPEDEF BYTE
SPEED TYPEDEF BYTE
WINDOW TYPEDEF BYTE
SKTBITS TYPEDEF WORD

; ----- Structures
PWRENTRY STRUCT ; Power level and valid signals

PowerLevel PWRINDEX ? ; as returned by InquireAdapter
ValidSignals FLAGS8 ?
PWRENTRY ENDS
ACHARTBL STRUCT ; Inquire Adapter

AdpCaps FLAGS16 ?
ActiveHi FLAGS32 ?
ActiveLo FLAGS32 ?
ACHARTBL ENDS
SCHARTBL STRUCT ; Inquire Socket

SktCaps FLAGS16 ?
ActiveHi FLAGS32 ?
ActiveLo FLAGS32 ?
DMAChannels FLAGS16 ?
wNumCustomIF WORD ?
dCustomIF DWORD ?
CHARTBL ENDS
MEMWINTBL STRUCT ; Inquire Window for Memory Windows

MemWndCaps FLAGS16 ? ; Window Capabilities Flags
FirstByte BASE ? ; System Address of First Byte
LastByte BASE ? ; System Address of Last Byte
MinSize WSIZE ? ; Minimum Window Size
MaxSize WSIZE ? ; Maximum Window Size
ReqGran WSIZE ? ; Size Granularity
ReqBase WSIZE ? ; Window Base Alignment requirement
ReqOffset WSIZE ? ; Alignment Requirement for offsets
Slowest SPEED ? ; Slowest Access Speed for Window
Fastest SPEED ? ; Fastest Access Speed for Window
MEMWINTBL ENDS
IOWINTBL STRUCT ; Inquire Window for IO Windows

IOWndCaps FLAGS16 ? ; Window Capabilities Flags
FirstByte BASE ? ; System Address of First Byte
LastByte BASE ? ; System Address of Last Byte
MinSize WSIZE ? ; Minimum Window Size
MaxSize WSIZE ? ; Maximum Window Size
ReqGran WSIZE ? ; Size Granularity
AddrLines COUNT ? ; Address Lines Decoded by Window
EISASlot FLAGS8 ? ; Upper 4 I/O Address lines for EISA
IOWINTBL ENDS
; ----- Valid power level bit-masks
VCC EQU 10000000B

VPP1 EQU 01000000B
VPP2 EQU 00100000B

; ----- Adapter capabilities bit-masks
AC_IND EQU 0000000000000001B

AC_PWR EQU 0000000000000010B
AC_DBW EQU 0000000000000100B
AC_CARDBUS EQU 0000000000001000B
; ----- Adapter state
AS_POWERDOWN EQU 00000001B

AS_MAINTAIN EQU 00000010B
; ----- Generic window capabilities bit-masks
WC_COMMON EQU 00000001B

WC_ATTRIBUTE EQU 00000010B
WC_IO EQU 00000100B
WC_WAIT EQU 10000000B
; ----- Generic bridge window capabilities bit-masks
WC_MEMORY EQU 00000001B
; ----- Bridge, Memory and I/O window capabilities bit-masks
WC_BASE EQU 0000000000000001B

WC_SIZE EQU 0000000000000010B
WC_WENABLE EQU 0000000000000100B
WC_8BIT EQU 0000000000001000B
WC_16BIT EQU 0000000000010000B
WC_BALIGN EQU 0000000000100000B
WC_POW2 EQU 0000000001000000B
WC_FETCHABLE EQU 0000000010000000B ; InquireBridgeWindow

WC_CACHABLE EQU 0000000100000000B ; InquireBridgeWindow
; ----- Memory window (page) capabilities only
WC_CALIGN EQU 0000000010000000B

WC_PAVAIL EQU 0000000100000000B
WC_PSHARED EQU 0000001000000000B
WC_PENABLE EQU 0000010000000000B
WC_WP EQU 0000100000000000B
; ----- I/O window capabilities only
WC_INPACK EQU 0000000010000000B

WC_EISA EQU 0000000100000000B
WC_CENABLE EQU 0000001000000000B

; ----- Generic window state
WS_IO EQU 00000001B

WS_ENABLED EQU 00000010B
WS_16BIT EQU 00000100B ; Memory and I/O only
; ----- Bridge window state
WS_PREFETCH EQU 00001000B

WS_CACAHBLE EQU 00011000B ; Includes WS_PREFETCH
; ----- Memory window state
WS_PAGED EQU 00001000B
; ----- I/O window state
WS_EISA EQU 00001000B

WS_CENABLE EQU 00010000B
; ----- Page state
PS_ATTRIBUTE EQU 00000001B

PS_ENABLED EQU 00000010B
PS_WP EQU 00000100B
; ----- IRQ level bit-masks (low word of 32-bit mask)
IRQ_0 EQU 0000000000000001B

IRQ_1 EQU 0000000000000010B
IRQ_2 EQU 0000000000000100B
IRQ_3 EQU 0000000000001000B
IRQ_4 EQU 0000000000010000B
IRQ_5 EQU 0000000000100000B
IRQ_6 EQU 0000000001000000B
IRQ_7 EQU 0000000010000000B
IRQ_8 EQU 0000000100000000B
IRQ_9 EQU 0000001000000000B
IRQ_10 EQU 0000010000000000B
IRQ_11 EQU 0000100000000000B
IRQ_12 EQU 0001000000000000B
IRQ_13 EQU 0010000000000000B
IRQ_14 EQU 0100000000000000B
IRQ_15 EQU 1000000000000000B
; ----- IRQ level bit-masks (high word of 32-bit mask)
IRQ_NMI EQU 0000000000000001B

IRQ_IO EQU 0000000000000010B
IRQ_BUSERR EQU 0000000000000100B

; ----- IRQ state bit-masks
IRQ_HIGH EQU 01000000B

IRQ_ENABLED EQU 10000000B
; ----- Socket bit-masks
SBM_WP EQU 00000001B

SBM_LOCKED EQU 00000010B
SBM_EJECT EQU 00000100B
SBM_INSERT EQU 00001000B
SBM_BVD1 EQU 00010000B
SBM_BVD2 EQU 00100000B
SBM_RDYBSY EQU 01000000B
SBM_CD EQU 10000000B
SBM_LOCK EQU 00010000B

SBM_BATT EQU 00100000B
SBM_BUSY EQU 01000000B
SBM_XIP EQU 10000000B
; ----- EDC definitions
EC_UNI EQU 00000001B

EC_BI EQU 00000010B
EC_REGISTER EQU 00000100B
EC_MEMORY EQU 00001000B
EC_PAUSABLE EQU 00010000B
EC_WRITE EQU 00000010B
ET_CHECK8 EQU 00000001B

ET_SDLC16 EQU 00000010B
ET_SDLC32 EQU 00000100B
; ----- Voltage Control values
VCTL_CISREAD EQU 00010000B

VCTL_OVERRIDE EQU 00100000B
VCTL_SENSE_MSK EQU 11000000b ; Used to isolate voltage sense

VCTL_50V EQU 00000000b
VCTL_33V EQU 01000000b
VCTL_XXV EQU 10000000b

; ----- Interface bit-masks
IF_TYPE_MASK EQU 00000011B ; Get/SetSocket

IF_CARDBUS EQU 00000000B ; GetSocket
IF_MEMORY EQU 00000001B ; Get/Inquire/SetSocket
IF_IO EQU 00000010B ; Get/Inquire/SetSocket
IF_CUSTOM EQU 00000011B ; Get/SetSocket
IF_CB EQU 00000100B ; InquireSocket

IF_DMA EQU 00001000B ; InquireSocket
IF_VSKEY EQU 00010000B ; InquireSocket
IF_33VCC EQU 00100000B ; InquireSocket
IF_XXVCC EQU 01000000B ; InquireSocket
DREQ_MASK EQU 00001100B ; Get/SetSocket

DREQ_NONE EQU 00000000B ; Get/SetSocket
DREQ_SPKR EQU 00000100B ; Get/SetSocket
DREQ_IOIS16 EQU 00001000B ; Get/SetSocket
DREQ_INPACK EQU 00001100B ; Get/SetSocket
DMA_CHAN_MASK EQU 11110000B ; Get/SetSocket

DMA_CHAN0 EQU 00000000B ; Get/SetSocket


Volume 7
Media Storage Formats Specification
PCMCIA
JEIDA
+1-408-433-9558 (Fax) IMPORTANT:
+81-3-3433-1923 PCMCIA
INFRINGEMENT,
YOU ÒAS IS.Ó

MEDIA STORAGE FORMATS SPECIFICATION
CONTENTS
1. Introduction ___________________________________________ 1
1.1 Purpose................................................................................................................................1
1.2 Scope....................................................................................................................................1
2. Overview ______________________________________________ 3
2.1 Storing Data.........................................................................................................................3
2.2 Partitions..............................................................................................................................3
2.3 Files and File Systems..........................................................................................................3
2.4 Storage Media......................................................................................................................3
2.5 In Summary.........................................................................................................................4
3. Partitions ______________________________________________ 5
3.1 Card Information Structure (CIS) Partitioning ..................................................................6
3.1.1 Overview ......................................................................................................................................................................................6
3.1.2 Partition Operations.................................................................................................................................................................6
3.1.2.1 Creation..........................................................................................................................................................................6
3.1.2.2 Deletion ..........................................................................................................................................................................6
3.1.2.3 Extension .......................................................................................................................................................................7
3.1.2.4 Evaluation Order .......................................................................................................................................................7
3.1.3 Initial Program Load...............................................................................................................................................................7
3.1.4 Data Structures...........................................................................................................................................................................7
3.2 Master Boot Record (MBR)..................................................................................................8

3.2.1 Overview ......................................................................................................................................................................................8
3.2.2.1 Creation..........................................................................................................................................................................8
3.2.2.2 Deletion ..........................................................................................................................................................................9
3.2.2.3 Extension .......................................................................................................................................................................9
3.2.3 Initial Program Load.............................................................................................................................................................1 0
3.2.4 Data Structures.........................................................................................................................................................................1 1
3.2.4.1 Master Boot Record.................................................................................................................................................1 1
3.2.4.2 Partition Entry...........................................................................................................................................................1 1
4. File Formats___________________________________________ 13
4.1 MS-DOS BPB/FAT Format ..............................................................................................13
4.1.1 Overview ....................................................................................................................................................................................1 3
4.1.2 Versions or Revisions ............................................................................................................................................................1 4

CONTENTS
4.1.2.1 12-Bit FATs.................................................................................................................................................................1 4

4.1.2.2 16-Bit FATs.................................................................................................................................................................1 4
4.1.2.3 Huge Partitions..........................................................................................................................................................1 4
4.1.3 Partition Recognition .............................................................................................................................................................1 4
4.1.4 Partition Formatting ..............................................................................................................................................................1 5
4.1.5 File Operations .........................................................................................................................................................................1 5
4.1.5.1 File Creation ...............................................................................................................................................................1 5
4.1.5.2 File Deletion................................................................................................................................................................1 5
4.1.5.3 Read and Write Operations..................................................................................................................................1 5
4.1.7 Data Structures.........................................................................................................................................................................1 6
4.1.7.1 Partition Boot Record (PBR).................................................................................................................................1 6
4.1.7.2 BIOS Parameter Block (BPB)................................................................................................................................1 7
4.1.7.3 Directory Entry .........................................................................................................................................................1 8
4.2 Linear File Store .................................................................................................................19

4.2.1 Overview ....................................................................................................................................................................................1 9
5. Translation Layers ____________________________________ 23

5.1 Virtual Block Device Flash Translation Layer - FTL ........................................................24
5.1.2 Overview ....................................................................................................................................................................................2 4
5.1.2.1 Emulating Traditional Block Devices - Virtual Block Device................................................................2 4
5.1.2.2 Flash Characteristics...............................................................................................................................................2 4
5.1.2.3 Erase Zones and Erase Units ...............................................................................................................................2 6
5.1.2.4 Erase Unit Header and Block Allocation Information ..............................................................................2 7
5.1.2.5 Block Allocation Information and the Block Allocation Map (BAM) .................................................2 8
5.1.2.6 Virtual Block Map - Mapping Virtual Blocks to Logical Addresses...................................................3 0
5.1.2.7 Virtual Page Map - Locating the Pages of the Virtual Block Map .........................................................3 2
5.1.2.8 Replacement Pages ...................................................................................................................................................3 3
5.1.2.9 Mapping Logical Addresses to Physical Addresses ..................................................................................3 4
5.1.3 Data Structures.........................................................................................................................................................................3 4
5.1.3.1 Erase Unit Header (EUH)......................................................................................................................................3 4
5.1.3.2 Flags ..............................................................................................................................................................................3 7
5.1.6 Logical Block Operations.....................................................................................................................................................3 9
5.1.6.1 Read...............................................................................................................................................................................3 9
5.1.6.2 Write..............................................................................................................................................................................3 9
5.1.6.3 Unit Recovery.............................................................................................................................................................4 0
6. Storage Devices _______________________________________ 43

6.1 Static RAM Cards..............................................................................................................43
6.2 Flash Memory Cards .........................................................................................................43
6.3 PC Card ATA Drives ........................................................................................................43
FIGURES
Figure 5-1: Erase Zones .................................................................................................................26
Figure 5-2: Read/Write Blocks......................................................................................................27
Figure 5-3: Erase Unit Layout.......................................................................................................28
Figure 5-4: Block Allocation Map .................................................................................................30
Figure 5-5: Virtual Block Map.......................................................................................................32
Figure 5-6: Page Mapping.............................................................................................................33

1.1 Purpose
This document describes how data is formatted on PC Cards used as storage devices to promote the
exchange of these cards among different host systems. These include memory cards using various
types of volatile and non-volatile devices and ATA disk drives, both silicon and rotating media.
Each of these storage technologies have unique characteristics which may benefit from different
storage techniques and handling. This has resulted in the development of different storage formats
and/or partitioning for PC Cards using these devices.
NOTE: The inclusion of a partition, file format, or media type information in this
document does not constitute an endorsement by PCMCIA or JEIDA.
PCMCIA and JEIDA are only acknowledging this information has been
used to record data on a PC Card and, in some cases, that PCMCIA/JEIDA
members have agreed that using the documented implementation may
reduce problems encountered when attempting to interchange data
between host systems.
1.2 Scope
This document is intended to provide enough information to allow software developers to use data
stored on PC Cards by other host systems using potentially different operating and file systems.
Unless required to understand the data structures used on the PC Card, algorithms for updating the
data on the PC Card are not specified, only the storage format.

Volume 11. PC Card Host System Specification
Microsoft Corporation, Microsoft MS-DOS Programmer's Reference, 2nd edition: version 6.0, 1993,
Microsoft Press.
2. O V E R V IE W
2.1 Storing Data

Most computer programs need to store and retrieve information. While running, a program may
use system memory for limited amounts of information, but often more information is required than
may fit in memory. In addition, when a program terminates, the system memory it was using is re-
used by other programs and information may be overwritten and lost.
To accommodate large and long-term storage needs, information is stored on disks and other types
of external media. Several types of PC Cards are used to store information including static RAM
(SRAM) and flash memory cards and silicon and rotating media PC Card ATA drives.
2.2 Partitions
Storage media may be divided into separately addressable areas known as partitions. Each partition
is addressed by a file system as if it were a separate storage device with its own directory and
allocation information.
To minimize the number of storage formats a file system needs to be able to recognize to avoid
erroneously assuming a partition or PC Card is unformatted, the Card Services Specification
provides two services which return partition information. They are GetFirstPartition and
GetNextPartition. A Card Services implementation determines partition information using the CIS
or by performing searches for file system specific data structures.
2.3 Files and File Systems

Information is usually stored in units called files. Files are managed by a file system, usually a part
of or an extension to an operating system. The file system records the structure used to store files in
a system file or area known as a directory. Each file typically has a record in the directory known as
a directory entry.
A file system also keeps track of where files are stored on the media and what areas are available.
A file system keeps track of storage space in units known as blocks or clusters. Block devices are
usually limited to reading or writing information in units known as sectors. A block or cluster may
be one sector or may be two or more contiguous sectors. By making blocks or clusters more than one
sector, a file system reduces the amount of storage required to track whether or not space on the
media is allocated.
2.4 Storage Media

PC Cards provide several technologies for storing information, each with its own unique
requirements. Static RAM (SRAM) devices are the most flexible allowing any byte to be separately
read or written.
Flash memory devices may allow byte or block accesses for reads, but require special write
algorithms and pre-erased bytes before most write operations. In addition, flash device require
erase operations to be performed on a block of contiguous bytes as a single unit.
OVERVIEW
PC Card ATA drives are accessed in the same manner as traditional block devices requiring an
entire sector be read or written at one time. The actual storage media may be silicon or magnetic
oxide on a rotating disk.
2.5 In Summary
To access data on storage media requires a complete understanding of how the media is partitioned,
the file format used and whether a translation layer is used. Client device drivers first check the
Card Information Structure (CIS) to determine if a PC Card is partitioned. If the card is partitioned,
the tuples used to describe the partition also describe the storage format used on the media.
3 . PAR T IT ION S
PCMCIA/JEIDA recognize two methods for partitioning PC Cards. First, linear memory PC Cards
such as flash and S-RAM cards use tuples in the Card Information Structure (CIS) to describe how a
PC Card is partitioned. Second, PC Card ATA drives are partitioned using a Master Boot Record
with a partition table.
Each recognized partitioning method is described separately in the following sections. The following
information is provided about each recognized method:
Overview An overview of the partitioning method and where it is
used.
Partition Operations How partition operations are performed.
Initial Program Load How a host system boots using the partitioning method.
Data Structures The data structures used by the partitioning method.
All PC Cards used for data storage must provide partition information as described in this section.
PC Cards used for data storage that do not contain partition information described in this section
may be assumed to be unformatted.
PARTITIONS
3.1 Card Information Structure (CIS) Partitioning
3.1.1 Overview
The PC Card's CIS describes partitions using the following tuples:
Tuple Name Tuple Constant Tuple Value

Format CISTPL_FORMAT 41H
Organization CISTPL_ORG 46H
Both tuples must be present. The Format Tuple describes where that partition is located on the
media and the Organization Tuple identifies the data storage format used within the partition. Data
storage within a partition is also affected by the following tuples, if they are present:

Geometry CISTPL_GEOMETRY 42H
Byte-Order CISTPL_BYTEORDER 43H
Software Interleave CISTPL_SWIL 23H
3.1.2 Partition Operations
3.1.2.1 Creation
A partition is created by adding the tuples described above to a PC Card's Card Information
Structure (CIS). The ability to write to a PC Card's CIS is dependent on the card and potentially
installed device drivers. A PC Card may require that the entire CIS be erased and then re-written to
modify the CIS.
Some PC Cards use multiple tuple chains to describe physical characteristics of the card separately
from how the card is used. For example, a primary tuple chain in a PC Card's attribute memory
space might describe the physical characteristics of the card, such as the type and size of the
memory device used on the card. A secondary tuple chain, in the PC Card's common memory
space, might be used to describe the logical characteristics of the card, such as the partitioning. In
this manner, the PC Card might be manufactured with the physical information hard-coded into
read-only memory in attribute memory space and logical partitioning information would be added
by using writable memory in common memory space. (See the Metaformat Specification for more
information about how tuple chains are linked together within the CIS.)
3.1.2.2 Deletion
To delete a partition, all of the tuples describing the partition must be deleted from the Card
Information Structure (CIS). Depending on the PC Card, the CIS may have to be erased and then re-
written without the tuples that describe the partition.
3.1.2.3 Extension
Some PC Cards allow the Card Information Structure to be extended without erasing existing tuples.
These cards permit additional partitions to be defined by adding tuples to the end of the last tuple
chain on the PC Card.
3.1.2.4 Evaluation Order

Host software evaluates partition information as it is encountered in the Card Information Structure
(CIS). If host software recognizes a partition type, the next available drive specifier is assigned to the
partition. If there are multiple partitions of different types on a PC Card, each partition type may be
recognized by a separate host device driver. For this reason, the order host drive specifiers are
assigned to partitions is host system specific.
3.1.3 Initial Program Load

The PC Card Standard does not currently define a method for booting from a PC Card using
partition definitions in the CIS.
3.1.4 Data Structures

See the Metaformat Specification for a complete definition of the tuples used to describe partitions.
PARTITIONS
3.2 Master Boot Record (MBR)
3.2.1 Overview
PC Card ATA drives are partitioned using a Master Boot Record (MBR) with a Partition Table in the
first physical sector of the media.. Partition Table Entries describe the size, location and type of data
within a partition. A Partition Table Entry may also describe an Extended Partition which is further
divided into one or more partitions.
The MBR contains a word of 55AAH at offset 1FEH. The sector contains operating system
independent code to perform Initial Program Load on x86 architecture host systems. For system and
PC Card interoperability, all systems, including those that do not use the IPL code for booting, must
include such information when formatting the MBR. The MBR also contains a Partition Table with
four (4) Partition Table Entries at offset 1BEH. When booting from a device with an MBR on an x86
architecture system, code within the MBR evaluates the Partition Table for a partition marked as the
default boot partition. Only one partition may be marked as the default boot partition.
If the x86 bootstrap code locates a default boot partition in the MBR's Partition Table, the Partition
Boot Record (PBR), the first sector of the partition, is loaded into memory. If the word at offset 1FEH
of the PBR is 55AAH, control is passed to the next stage bootstrap loader in the PBR image in
memory.
During operating system initialization, MBRs on all fixed disk devices are evaluated by the file
system for partition definitions in reverse order starting with the entry at offset 1EEH. The host
system assigns unit designations (drive letters under MS-DOS), to each partition matching a type
supported by the file system.
3.2.2.1 Creation
A partition is created by setting the fields of a partition entry in the partition table of the Master
Boot Record (MBR) to describe the desired partition. A partitioning utility first reads the MBR into
host system memory. If the word at offset 1FEH of the MBR is not 55AAH, the device is not
formatted and the utility must create an initial MBR with an empty partition table before preceding.
If the word at offset 1FEH of the MBR is 55AAH, the partitioning utility searches the partition table
for an empty entry. An entry is considered empty if the NumSectors field is zero (0). If there are no
empty entries in the partition table, a partition cannot be created.
If there is an empty partition entry, the partitioning utility creates a new partition using contiguous
unallocated space on the media. The utility determines if there is any available space on the media
by subtracting the space allocated to other partitions from the total size of the media. The total size
of the media is determined in a host system dependent manner. For example, on x86 systems with
a PC-compatible ROM BIOS the Get Drive Parameters function (Int 13H Function 8) is typically
used.
If there is unallocated space on the media, the partitioning utility must also determine where the
space is located by comparing the Start and End of each allocated partition. How a partitioning
utility decides which space to use when multiple unallocated spaces are available is implementation
specific.
After a partition entry is created the partitioning utility needs to notify the host system of the
change to the MBR.
A partition table entry uses Cylinder, Head and Sector (CHS) addressing to describe the starting
and ending boundaries of a partition. Some PC Card ATA drives translate their physical CHS
information to logical values that are compliant with limits imposed by some host systems that are
unable to address cylinder, head or sector values that exceed system-specific limits. Once a partition
table entry has been created, all subsequent accesses to the media must use the same logical CHS
addressing.
The PC Card Standard requires that all partitions described in the partition table within the MBR
end on a logical cylinder boundary based on the logical CHS addressing in use when the first
partition was created. This allows a host system to validate the logical CHS addressing in use is
correct by confirming the maximum head and sector values used for media access are the same as
those used to indicate the ending head or sector of all partitions on the media.
3.2.2.2 Deletion
A partition is deleted by resetting all of the fields of a partition entry in the partition table of the
Master Boot Record to zero (0). After a partition entry is deleted the partitioning utility needs to
notify the host system of the change to the MBR.
3.2.2.3 Extension
Some partition types extend the partition table in a system-specific manner. For example, MS-DOS
defines a special partition type called the Extended MS-DOS partition. The space allocated to an
Extended MS-DOS partition is sub-divided into logical drives. The first sector of an Extended MS-
DOS Partition contains a partition table formatted in the same manner as the partition table in a
Master Boot Record (MBR). The extended partition table typically contains two entries, an MS-DOS
partition and another Extended MS-DOS partition entry.
The MS-DOS partition entry in an extended MS-DOS partition describes a logical drive. If an
Extended MS-DOS partition entry is also present in the partition table, another potential logical
drive may exist within the area described by the Extended MS-DOS partition entry. Extended MS-
DOS partition entries create a forward-linked list of logical drives within the Extended MS-DOS
partition in the MBR.
The one difference between partition entries in an MBR and partition entries in the partition table in
an Extended MS-DOS partition is the StartSector field of the partition entries. In the MBR this field is
relative to the beginning of the media. In an Extended MS-DOS partition this field is relative to the
beginning of the Extended MS-DOS partition described in the MBR.

The order partition entries are evaluated in the partition table of the Master Boot Record (MBR) is
dependent on the operating system. For example, MS-DOS evaluates primary partition types on the
first two physical fixed drives on x86 systems addressed by the ROM BIOS Int 13H Disk I/O
handler as drives 80H and 81H. Primary partition types are 01H, 04H and 06H.
If the first physical fixed drive has a primary partition, MS-DOS assigns the next available logical
drive letter to the partition. If there is a second physical fixed drive and it has a primary partition,
MS-DOS assign the next available logical drive letter to this partition. After MS-DOS assigns the
primary partition types on the first two physical fixed drives as logical drives, Extended MS-DOS
partitions are evaluated.
If the first physical fixed drive has an Extended MS-DOS partition, each logical drive described in
the chain of Extended MS-DOS partitions is added as a logical drive letter. If there is a second
PARTITIONS
physical fixed drive and it has an Extended MS-DOS partition, each logical drive described in the
chain of Extended MS-DOS partitions is added as a logical drive letter.

The PC Card Standard does not describe a system independent method for booting from a device
with a Master Boot Record (MBR). However, x86 systems use the MBR as the first stage of a multi-
stage program loader. The host system reads the MBR of the first physical drive into host system
memory at 0000H:7C00H. If the word at offset 1FEH of the MBR is not 55AAH, the media is not
bootable and the system continues the boot process with another device or displays an error
message.
If the word at offset 1FEH of the MBR is 55AAH, the host system transfers control to the code at
0000H:7C00H. No arguments are provided to the code by the host system. No stack is established
and no indication of which device the MBR was read from is provided.
The boot code in the MBR evaluates the partition table from the last entry at offset 1EEH to the first
entry at 1BEH. If an entry is found with the default x86 boot partition field set to 80H, the first sector
of the partition described by the partition entry, known as the Partition Boot Record (PBR), is loaded
into host system memory. If the word at offset 1FEH of the PBR is 55AAH, control is transferred to
offset zero of the PBR and the boot process continues. If the word at offset 1FEH of the PBR is not
55AAH, the code in the MBR displays an error message and halts.
3.2.4.1 Master Boot Record

The Master Boot Record contains the following fields:
Offset Size (Bytes) Description

000H 446 Boot code
1BEH 16 Partition Entry (See below)
1CEH 16 Partition Entry (See below)
1DEH 16 Partition Entry (See below)
1EEH 16 Partition Entry (See below)
1FEH 2 Signature Word (0x55AA)
3.2.4.2 Partition Entry

Each of the four Partition Entries in the Master Boot Record have the following format:

00H 1 x86 default boot partition
00H = Not default boot partition
80H = Default boot partition
01H 1 StartHead - Zero-based (0) head number where partition starts on media.
02H 1 StartSector - Bits 0 .. 5 are one-based (1) sector number where partition
starts on media. Bits 6 and 7 are high bits of zero-based (0) cylinder
number where partition starts on media.
03H 1 StartCylinder - Least significant eight bits of zero-based (0) cylinder
number where partition starts on media. Upper two bits of starting cylinder
number are in StartSector field.
04H 1 Partition Type
00H: Unknown or deleted if NumSectors is zero
01H: MS-DOS 12-bit BPB/FAT < 16 MB
05H: Extended MS-DOS Partition
06H: MS-DOS 16-bit BPB/FAT >= 32 MB
05H 1 EndHead - Zero-based (0) head number where partition ends on media.
06H 1 EndSector - Bits 0 .. 5 are one-based (1) sector number where partition
ends on media. Bits 6 and 7 are high bits of zero-based (0) cylinder
number where partition ends on media.
07H 1 EndCylinder - Least significant eight bits of zero-based (0) cylinder
number where partition ends on media. Upper two bits of ending cylinder
08H 4 StartSector (relative to beginning of media or Extended MS-DOS Partition)
0CH 4 NumSectors
4 . F I L E F O R M AT S
To achieve backward compatibility and speed acceptance of PC Card technology, the formats used
by file systems for traditional storage devices are often used for PC Cards. This section describes the
data structures used by specific formats and how file operations using those structures are
performed. Each subsection provides the following information about a file format:
Overview An overview of the format and where it is used.
Versions or Revisions Variations of the file format in common use.
File Operations How common file operations are performed using the
defined data structures.
Initial Program Load How a host system boots using the file format.
Data Structures The data structures used by the file format.
4.1 MS-DOS BPB/FAT Format
4.1.1 Overview
In the MS-DOS environment, the native file system stores information in what is known as the
BPB/FAT format. Static RAM (SRAM) cards and PC Card ATA drives commonly use this format on
x86 architecture systems. Flash memory cards may also use this format if they are read-only or are
accessed using a Flash Translation Layer (FTL).
BPB/FAT media is accessed in blocks known as sectors. The number of bytes in a sector is described
in the BIOS Parameter Block (BPB) BytesPerSector field. The total number of sectors on the media is
described by the BPB 0 field if there are less than 65,536 sectors. If there are more than 65,535
sectors, the TotalSectors field is zero (0) and the number of sectors on the media is described by the
HugeSectors field.
BPB/FAT media may have hidden sectors. Hidden sectors are usually associated with partitioned
media. The BPB HiddenSectors field describes the number of hidden sectors on the media.
BPB/FAT media have one or more reserved sectors. The BPB ReservedSectors field describes the
number of reserved sectors on the media. The first reserved sector is known as the Boot Sector. This
sector contains the BIOS Parameter Block (BPB) describing the size and format of the media.
After any hidden and reserved sectors, BPB/FAT media have one or more File Allocation Tables
(FATs). If there is more than one FAT, the additional copies are maintained to allow data recovery
in case the first FAT is damaged. Most BPB/FAT media is formatted with two (2) FATs. The
number of FATs is described by the BPB NumFATs field.
The FAT tracks the allocation of the media's data space. Space on BPB/FAT media is allocated in
units of one or more contiguous sectors called clusters. If a cluster has more than one sector, the
number of sectors in the cluster must be a power of two (for example, two, four, eight, etceteras).
The BPB SectorsPerCluster field describes the number of sectors per cluster.
FAT entries may be 12 or 16-bits depending on the number of clusters on the media. Media with
more than 4085 clusters use 16-bit entries. Media with 4085 or less clusters use 12-bit entries. Each
entry in the FAT represents the allocation status of a cluster. The first two entries are reserved for
FAT ID information. The first data area tracked by the FAT is cluster number two (2).
FILE FORMATS
A FAT entry has the following meanings. The digit in parentheses represents the upper four bits
associated with 16-bit FAT entries.
Value Meaning
(0)000H Available or unallocated cluster
(0)001H Reserved, do not use this value
(0)002H - (F)FF6H Next cluster in file or directory
(F)FF7H Bad cluster, do not store data in this cluster
(F)FF8H - (F)FFFH Last cluster of file or directory
The number of sectors used to store each FAT is described in the BPB NumFATSectors field. The
next area on the media after the FAT(s) is the Root Directory. The Root Directory is an array of
Directory Entries. The number of directory entries in the Root Directory is described by the BPB
RootDirEntries field. The Directory Entry StartCluster field describes the first cluster used to store
data for the file or directory identified by the entry.
The space on the media immediately following the Root Directory is used for file and subdirectory
data storage. The Directory Entry Attributes field identify an entry as a subdirectory of a file.
Subdirectories are special file entries containing additional directory entries for files and further
subdirectories in the data area of the media.
4.1.2 Versions or Revisions
4.1.2.1 12-Bit FATs

BPB/FAT media formatted with less than 4086 clusters uses 12-bit File Allocation Table (FAT)
entries. Each FAT entry requires 1.5 bytes.
4.1.2.2 16-Bit FATs

BPB/FAT media formatted with more than 4085 clusters uses 16-bit File Allocation Table (FAT)
entries. Each FAT entry requires two (2) bytes.
4.1.2.3 Huge Partitions

BPB/FAT media with more than 65,535 sectors indicates the number of sectors in the BPB
HugeSectors field and sets the TotalSectors field to zero (0). All huge partitions use 16-bit FAT
entries requiring two (2) bytes for each entry.
4.1.3 Partition Recognition

All BPB/FAT partitions begin with a Partition Boot Record (PBR). All PBRs start with a byte of E9 H
or EBH. If the PBR begins with a byte of EBH, the byte at offset two (2) must also be 90H. If the
previous bytes are present, the byte at offset 26H of the PBR must be 29H indicating an Extended
BPB is present.
If the PBR does not contain the above bytes, the partition is not BPB/FAT format.
Further consistency checks may be performed on an implementation specific basis. The BIOS
Parameter Block (BPB) fields may be checked for valid values. For example, the BytesPerSector
field must be a power of two and at least 128 bytes. The SectorsPerCluster field must be one or any
other power of two. The ReservedSectors field must be at least one (1). The NumFATs field must be
one (1) or two (2).
4.1.4 Partition Formatting

The first step in formatting a BPB/FAT partition is to write a Partition Boot Record (PBR) with a
BIOS Parameter Block (BPB) to the first reserved sector of the partition. The next step is to initialize
the number of File Allocation Tables (FATs) indicated by the BPB NumFATs field. The first byte of
each FAT is the partition's FAT ID byte followed by two bytes of FFH. If the FAT uses 16-bit entries,
the next byte is also FFH. All of the remaining bytes of the FAT are zero (00H).
The sectors for the Root Directory are then initialized. All bytes of the Root Directory sectors are
written as zeroes (00H). Optionally, a scan of the media may be performed to determine if any of
the data clusters are defective. How or if this scan is performed is implementation specific. However,
if bad sectors are located, the clusters containing the bad sectors are marked as bad in all FATs.
4.1.5 File Operations
4.1.5.1 File Creation

A file is created by filling in the fields in a directory entry. The directory may be in the Root
Directory or a subdirectory. A directory entry may be created with the StartCluster field set to zero
(0) if the file or subdirectory does not contain any data. The first write to the file or subdirectory will
allocate a cluster if there is one available on the media.
4.1.5.2 File Deletion

A file or subdirectory is deleted by overwriting the first byte of the Name field with the value E5H.
In addition, any clusters allocated to the directory entry must be freed by writing a zero (0) to the
corresponding cluster entries in all the File Allocation Tables on the media.
A directory entry for a subdirectory may not be deleted until all entries in the subdirectory are
deleted as described above.
4.1.5.3 Read and Write Operations

The first step in performing a read or write is to determine where on the media the operation
should begin. Such operations typically specify an offset within the file or directory. The BIOS
Parameter Block (BPB) BytesPerSector and SectorsPerCluster fields are used to determine the
relative cluster where the operation is to begin.
The desired offset is divided first by the BytePerSector field. The result is further divided by the
SectorsPerCluster field. The result of the second divide is the relative cluster where the operation
begins. The remainder of the second divide is the relative sector within the cluster where the
operation begins. If the remainder of the first divide is non-zero, the operation begins in the middle
of a sector and must be buffered by host software.
For example, if the media is formatted for 512 bytes per sector and there are two sectors per cluster,
a read from offset 1024 of a file would begin at the start of the second cluster. A read from offset 1536
begins at the start of the second sector of the second cluster. A read from offset 1792 begins in the
middle of the second sector of the second cluster and requires host system buffering.
Once the appropriate relative cluster is determined, the File Allocation Table (FAT) is used to
convert the relative cluster to an absolute cluster on the media. The Directory Entry's StartCluster
FILE FORMATS
field determines the first cluster. The value in that entry of the FAT is the next cluster in the chain.
When a FAT entry is FF8H to FFFH, the end of the cluster chain has been reached. Attempts to read
past the end of the cluster chain are failed.
If an operation continues beyond the end of a cluster, the location of the next cluster is determined
from the contents of the current FAT entry. Write operations that continue past the end of the cluster
chain need to extend the chain.
A cluster chain is extended by overwriting the current FAT entry with the number of an
unallocated cluster. The unallocated cluster entry in the FAT is then marked as the end of the chain.
Attempts to extend cluster chains on full media are failed.
When a directory entry is extended, the FileSize field of the entry is increased. The FileSize field
represents the actual size of the file or directory, in bytes, and may be less than the space allocated.
This is due to the fact the file or directory may not fill the last cluster allocated.

The Partition Boot Record (PBR), in addition to containing the BIOS Parameter Block (BPB), also
contains code to continue Initial Program Load (IPL). Host system software loads the PBR into system
memory at 0000H:7C00H. If the word at offset 1FEH of the PBR is 55AAH, the host systems transfers
control to the PBR code at 0000H:7C00H. No arguments are provided to the code by the host system.
No stack is established and no indication of which device the PBR was read from is provided.
If the PBR contains an MS-DOS bootstrap loader, the information in the BPB within the PBR is used
to locate systems files in the Root Directory of the media. If these files are located, they are loaded
into host system memory and control is transferred to them to complete IPL.
4.1.7.1 Partition Boot Record (PBR)

The Partition Boot Record contains the following fields:

000H 3 JMP instruction to PBR boot code
003H 8 OEMName and version
00BH 25 BIOS Parameter Block (BPB)
024H 1 DriveNumber (00H = Floppy, 80H = Fixed)
025H 1 Reserved, do not use
026H 1 ExtBootSignature - 29H
027H 4 VolumeID or Serial Number
02BH 11 VolumeLabel - ASCII characters, padded with blanks if less than eleven
(11) characters
036H 8 FileSysType - ASCII characters identifying file system type. Padded
with blanks if less than eight (8) characters. One of the following values:
Value Meaning
FAT12 12-bit File Allocation Table (FAT)
FAT16 16-bit FAT
03EH 448 Boot code
1FEH 2 Signature word - 55AAH
4.1.7.2 BIOS Parameter Block (BPB)

The BIOS Parameter Block (BPB) contains the following fields:

000H 2 BytesPerSector - Number of bytes per sector
002H 1 SectorsPerCluster - Number of sectors in a cluster
003H 2 ReservedSectors - Number of reserved sectors at the beginning of the media.
Must be at least one (1) to accommodate the Partition Boot Record (PBR)
005H 1 NumFATs - Number of File Allocation Tables (FATs) on the media.
006H 2 RootDirEntries - Number of Root Directory entries
008H 2 TotalSectors - Number of sectors on media. If media has more than 65,535
sectors, this field is zero and the actual number of sectors is in the HugeSectors
field.
00AH 1 MediaIDByte - Used to quickly identify how the media is formatted
Value Meaning
F0H Various types of media
F8H Hard disk, any size
F9H 720K 3.5" or 1.2M 5.25"
FAH 320K 5.25"
FBH 640K 3.5"
FCH 180K 5.25"
FDH 360K 5.25"
FEH 160K 5.25"
FFH 320K 5.25"
00BH 2 NumFATSectors - Number of sectors in each FAT
00DH 2 SectorsPerTrack - Number of sectors on a track
00FH 2 NumHeads - Number of heads
011H 4 HiddenSectors - Number of hidden sectors in front of reserved sectors
015H 4 HugeSectors - Number of sectors on media if TotalSectors is zero (0).
FILE FORMATS
4.1.7.3 Directory Entry

Each directory entry contains the following fields:

000H 8 Name ¾ File or directory name. If less than eight (8) characters, padded with
blanks.
008H 3 Extension ¾ File or directory extension. If less than three (3) characters, padded
with blanks
00BH 1 Attributes ¾ Bit-mapped field using following values:
Value Meaning
xxxxxxx1B Read-only
xxxxxx1xB Hidden
xxxxx1xxB System
xxxx1xxxB Volume label (root directory only)
xxx1xxxxB Subdirectory
xx1xxxxxB Archive (new or modified entry)
00CH 10 Reserved, do not use
016H 2 Time ¾ Bit-mapped field describing time file or subdirectory created or modified:
Bits Meaning
0 .. 4 Two-second interval (0 .. 29)
5 .. 10 Minute (0 .. 59)
11 .. 15 Hour (0 .. 23)
4.2 Linear File Store
4.2.1 Overview
Define a partition type for storing files formatted in a PCMCIA/JEIDA-prescribed manner within
contiguous sections of PC Card memory. This Linear File Store (LFS) uses a well-defined header
record to allow directory functions and file access to be performed across a wide variety of operating
environments and host platforms.
Partitions on PC Cards are defined using the Data Recording Format Tuples in Layer 2 of
Metaformat Specification. A memory-like format tuple is used to describe the PC Card StandardÕs
LFS partition. (See the Metaformat Specification for more information about format tuples.)
Byte 7 6 5 4 3 2 1 0
0 TPL_CODE Format tuple code (CISTPL_FORMAT, 41H) or (CISTPL_FORMAT_A, 47H).

1 TPL_LINK Link to next tuple (0BH)
2 TPLFMT_TYPE Format type code (TPLFMTTYPE_ MEM, 01H)
3 TPLFMT_EDC Error Detection Method (TPLFMTEDC_NONE)
RFU 000B 0000B
4 .. 7 TPLFMT_OFFSET Byte address of the first data byte in this partition.
8 .. 11 TPLFMT_NBYTES Number of data bytes in this partition.
12 TPLFMT_FLAGS Various Flags (00H - Flags not used)
(Reserved) 0 0
The above tuple definition describes a partition which is formatted as a memory-like region with no
error detection and no requirement for direct mapping into a specific area of host system address
space. For the example an election has been made to shorten the tuple by omitting optional fields
which are not used.
The data organization of the PC Card StandardÕs LFS partition is defined by an Organization Tuple.
(See the Metaformat Specification for more information about data organization tuples.)
Byte 7 6 5 4 3 2 1 0
0 TPL_CODE Organization tuple code (CISTPL_ORG, 46H).

2 TPLORG_TYPE Data organization code (TPLORGTYPE_FS, 00H)
3 .. 12 TPLORG_DESC Linear File Store specified by the PC Card Standard ("LFS100")
(Note: Text description of this organization, terminated by 00H)
Within the partition, each file is preceded by a PC Card Standard-defined entry record. This
structure provides enough information for a simple bootstrap loader to select an appropriate file. If a
specific environment requires information beyond that defined by the PC Card Standard, the
organization responsible for that environment defines any additional fields required immediately
after the PC Card Standard-defined fields creating an extended header record.
For XIP files, a header record is also defined to provide information about the length of the root
segment of the file, whether the file uses paging and the entry point for execution within the file.
Because the header record is part of the file, the data in the record is available during file execution.
FILE FORMATS
The PC Card Standard-defined entry record is located at the base of the window that maps the root
section into host system address space.
Note:
XIP definition to be developed by XIP Working Group.
Files are stored consecutively within the partition using a forward-linked list managed by a field
which points to the next header record. If the file is the last in a partition, the pointer to the next
header record is set to all ones (-1 or FFFFFFFFH). This value allows files stored in partitions using
flash memory devices to be extended if sufficient space remains within the partition.
Each entry in the PC Card StandardÕs LFS Partition has the following structure:
typedef struct {
DWORD NextEntry;
DWORD EntrySize;
DWORD EntryType;
DWORD OffsetToHeader;
DWORD Flags;
DWORD OffsetToString;
DWORD UniqueID;
BYTE Reserved[4];
BYTE EntryInfo[];
} ENTRY;
Member Description
NextEntry This field points to the next entry within the partition, relative to the start of this entry on the
PC Card. The actual location of the next entry is determined by adding the value in this field
to the offset of this field on the PC Card. If all of the bits in this field match Bit D0 of the
Flags field, this is the last entry in the partition.
EntrySize This field contains the actual size of the entry, i.e. the number of bytes in this instance of the
ENTRY structure. EntrySize is less than the NextEntry when padding is added to align the
next entry on a boundary.
EntryType This field contains a PCMCIA assigned value that defines the interpretation of the data in
the EntryInfo byte array. EntryType values are assigned by PCMCIA. The definition of any
header structure within the EntryInfo area for a particular EntryType value must be
provided at the time the EntryType is assigned. If all of the bits in this field match Bit D0 of
the Flags field, this entry is not defined. For this reason, the EntryType values zero and
minus one are reserved.
OffsetToHeader This field contains the offset from the beginning of the ENTRY structure where additional
EntryType specific information is stored. The actual location of the specific information is
determined by adding the value in this field to the offset of the NextEntry field on the PC
Card. If this field is zero, there is no specific information and this field is ignored.
Flags This field is bit-mapped. The bytes of this field are stored in little-endian order. Bit D1
indicates the current state of the entry. If Bit D1 matches D0, this entry is active. If Bit D1
does not match Bit D0, this entry has been deleted. All of the remaining bits are reserved
and must be set to the value of Bit D0. Bit D0 is used in this manner to accommodate the
unique erase and write characteristics of some types of storage media such as flash
memory devices. Bit D0 is typically maintained in the natural erase state of the media.
OffsetToString The field contains the offset from the beginning of the ENTRY structure where an ASCIIZ
string describing the entry is stored. The actual location of the string is determined by
adding the value in this field to the offset of the NextEntry field on the PC Card. If this field is
zero, there is no ASCIIZ string and this field is ignored.
UniqueID This field contains a value that is unique for each file stored in the partition. It is intended to
be used to uniquely identify a file even if it is relocated within the partition. Formatting
software should attempt to prevent the reuse of UniqueID values previously assigned to
deleted entries. How this is accomplished is implementation specific.
Reserved These bytes are reserved for future use. They shall be set to match the value of bit D0 of
the Flags field.
EntryInfo The data for this entry.
5 . T R A N S L AT I O N L AY E R S
When sector remapping is performed by a translation layer, two storage formats are used. From the
host system perspective, the same block storage format used for other media is being recorded. With
the translation layer in place, the host system believes it is using traditionally formatted media.
However, the translation layer requires sector mapping information to be stored on the media and
what the host feels are contiguous sectors are actually placed on the media out of sequence. To allow
another system to recover the data stored on the media requires an understanding of how the
translation layer remaps sectors and the native storage format intended by the original file system.
Any file format used for block data storage may be used on top of a Flash Translation Layer (FTL).
To boot from a Flash Translation Layer (FTL) partition requires the FTL to translate host requests for
virtual blocks.
TRANSLATION LAYERS
5.1 Virtual Block Device Flash Translation Layer - FTL

Release FTL Version
PC Card Standard Release 7.0 (February 1999) 1.2
PC Card Standard April 1998 (Release 6.1) 1.1
PC Card Standard May 1996 (Release 5.2) 1.0
5.1.2 Overview
Traditional block storage devices read and write data in small blocks sized in power-of-two
multiples beginning at 256 (i.e. 256, 512, 1024, 2048, etc. byte blocks). File systems and the data
structures they use are optimized for read/write units of this size. While flash media storage devices
may be able to perform read and write operations on similar size blocks, they usually require a
data area be erased before it may be written.
Adding an erase operation immediately before a write would appear to solve the problem and for
some flash devices, this is all that is required. Unfortunately, for many flash devices, erase
operations must often be applied to a contiguous area of the media known as an Erase Zone that is
larger (in some cases, much larger) than traditional storage devices use for read and write access.
This can make flash devices difficult to use with traditional file systems unprepared to relocate
adjacent data areas to prepare for erase operations.
Two approaches have been taken to deal with the unique characteristics of flash storage devices: the
development of new file systems customized for flash device characteristics and the introduction of a
translation layer between the file system and the storage media to mask any differences between
flash storage devices and traditional block storage devices. This section describes the later method,
known as a Flash Translation Layer (FTL).
5.1.2.1 Emulating Traditional Block Devices - Virtual Block Device

An FTL masks the characteristics of flash devices from higher level software layers such as file
systems by emulating a traditional block device. From the perspective of such higher level layers, a
block storage device is a contiguous array of blocks numbered from zero (0) to one less than the
number of available blocks. These higher level software layers expect to be able to write these
blocks at will, without any regard for the need to first erase the media and certainly without any
need to erase an area that exceeds the size of the block being written.
The FTL delivers this capability to the higher level software layers by remapping requests to write
blocks to unallocated or free areas of the media and invalidating the area on the media previously
containing the block's data. The FTL also records where the remapped block is placed on the media
to allow subsequent read accesses to return the data written. In effect, the FTL presents a virtual
block storage device to the higher level software layers. The size of these virtual blocks is
determined when the storage media is formatted.
5.1.2.2 Flash Characteristics

A unique characteristic of flash media is its data content after erasure. If erased, flash media data
bytes are either set to all ones (FF H) or all zeroes (00H). In addition, once a flash data bit has been
set to a value other than its erase state, an entire Erase Zone must be erased to return the bit to its
erased state. However, single bits within a byte may be transitioned from the erased state to the
non-erased state without an erase operation. FTLs use this ability to modify updatable fields in
control structures. See the description of the ReversePolarityFlash bit of the Flags field in the Erase
Unit Header.
TRANSLATION LAYERS
5.1.2.3 Erase Zones and Erase Units

Depending on its technology, each flash IC on a PC Card may be divided into one or more Erase
Zones of equal size. Each Erase Zone is the minimum contiguous area that can be erased in a single
operation. If eight-bit devices are interleaved to provide sixteen-bit storage, the corresponding
physical zones on two adjacent devices are combined together as a single Erase Zone. One device
provides even addresses and the other device provides odd addresses.
An Erase Unit is a multiple of one or more contiguous Erase Zones. The size of an Erase Unit is set
when the media is formatted. See Figure 5-1: Erase Zones.
Flash Memory Card Interleaved Flash Devices
Even Odd
Addresses Addresses
Flash IC Flash IC
Flash IC Flash IC Erase Zone
Erase Zone
Flash IC Flash IC
Erase Zone
Flash IC Flash IC
When a flash IC does not require the entire device to be erased as a single unit, a single flash IC conta
multiple Erase Zones. When eight-bit flash devices are used, an Erase Zone spans two flash ICs.
Figure 5-1: Erase Zones
5.1.2.4 Erase Unit Header and Block Allocation Information

For allocation purposes, an Erase Unit is evenly divided into one or more Read/Write Blocks of
equal size. For example, a 128 KByte Erase Unit might be divided into 256 Read/Write Blocks, each
512 Bytes in size. Each of these Read/Write Blocks is the same size as the Virtual Blocks presented
to the higher level software layers by the FTL. See Figure 5-2: Read/Write Blocks.
Flash Memory Card Erase Unit

Subdivided into Erase Units Subdivided into Read/Write Blocks
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Erase Unit
An Erase Unit is evenly divided into read/write blocks for allocation purposes. Each of these
read/write blocks is the same size as the virtual blocks presented to the higher level software
layers by the FTL.
Figure 5-2: Read/Write Blocks
Within each Erase Unit is an Erase Unit Header (EUH). The EUH includes specific information
about the Erase Unit and global information about the format of the FTL partition. Each Erase Unit
also contains allocation information for all of the Read/Write Blocks within the unit.
Some flash devices have a small number of bytes of storage adjacent to each Read/Write Block
which are not addressed through the linear address space of the media. Erase Units with these
"hidden" areas may place block allocation information for a Read/Write Block in the hidden area
adjacent to the block. If the Erase Unit does not have hidden areas or an FTL partition is not
formatted to use the hidden areas, block allocation information is stored in an array known as the
Block Allocation Map or BAM in the Erase Unit's linear address space. The Flags field of the EUH
indicates whether block allocation information is stored in hidden areas or a BAM.
TRANSLATION LAYERS
For data integrity purposes, two copies of the block allocation information may be stored in the
Erase Unit. The Flags field of the EUH indicates the number of copies of the block allocation
information that are present on the media. When BAMs are used to store block allocation
information, the second copy is stored in a separate BAM immediately following the first BAM in
the Erase Unit.
Optional Checksums, CRCs or ECCs may also be present for each Read/Write Block. If present,
these codes are stored immediately following the block allocation information, in either the BAM or
the media's hidden areas as indicated by the Flags field of the EUH. The length of these codes
varies depending on the type of code being used. See Figure 5-3: Erase Unit Layout.
Flash Memory Card Erase Unit with Erase Unit without

Subdivided into Erase Units Hidden Areas Hidden Areas
Erase Unit Header Erase Unit Header
Erase Unit Block Allocation Map

(BAM)
Erase Unit Read/Write Blocks

used for
Read/Write Blocks
Virtual Map Pages,
Erase Unit used for
Replacement Pages
Virtual Map Pages,
and Virtual Blocks
Replacement Pages
Erase Unit and Virtual Blocks
Erase Unit
Block Allocation
In Hidden Areas
Information
Erase Unit
Erase Unit One or more Erase Zones
Erase Units with hidden areas may place Block Allocation Information in those areas rather than in the
linear address space of the media. Optional Checksums, CRCs or ECCs are not shown. If present, these
codes are stored immediately following the Block Allocation Information in either the Block Allocation Map
(BAM) or the media's hidden areas.
Figure 5-3: Erase Unit Layout
5.1.2.5 Block Allocation Information and the Block Allocation Map (BAM)
Each Erase Unit on the media contains allocation information for the Read/Write Blocks within the
unit. For each Read/Write Block, a four-byte value tracks the block's current state. At any point in
time, a Read/Write Block in an Erase Unit is free, deleted, bad, reserved for bad area management,
or allocated. For each Read/Write Block, a four (4) byte value tracks the block's current state. The
following table identifies the corresponding block allocation entry values for the state of a
Read/Write Block:
BAI Meaning Description

FFFFFFFFH Free Read/Write Block is available, erased and ready to be written.
FFFFFFFEH Deleted Data in block is not valid. Read/Write Block must be erased before it
can be re-used.
OR
The value FFFFFFFEH indicates write operations were started on the
00000000H
Read/Write Block, but were interrupted before they were completed.
The value 00000000H indicates the data in the Read/Write Block was
superseded by normal update operations.
00000070H Bad Block is unusable.
xxxxxx10H Bad Area Block allocated for storing information about bad areas in the flash
Management device.
Any Other Value Allocated Block is allocated. The actual BAI value describes the type of data
stored in the Read/Write Block. Other values could be valid and should
not cause operation errors. If a value is unrecognized, the block should
be marked by software as "deleted" at initialization.
When allocated, Read/Write Blocks are used to store four types of data: FTL control structures,
Virtual Block data for higher level software layers, Virtual Block Map Pages and Replacement
Pages. When a Read/Write Block is allocated to an FTL control structure, the block's allocation
information entry is set to the following:
00000030H Control Read/Write Block contains one or more FTL control structures: an
Erase Unit Header, a Block Allocation Map (BAM), or an array of
Checksums, CRCs or ECCs.
The block allocation entries for Virtual Block data, Virtual Block Map Pages and Replacement Pages
have two parts. The least significant eight (8) bits indicate whether the Read/Write Block contains
Virtual Block data, a Virtual Block Map Page or a Replacement Page as indicated by the following
table:
xxxxxx40H Data or Map Page Read/Write Block contains Virtual Block data or a Virtual Map Page.
xxxxxx60H Replacement Read/Write Block contains a Replacement Page for a Virtual Map Page.
Page
The most significant twenty-four (24) bits of the block allocation entry for a Read/Write Block
containing Virtual Block data, a Virtual Block Map Page or a Replacement Page are the most
significant bits of the virtual address of the data. The least significant eight (8) bits of the virtual
address for these entries are assumed to be zero (0). To determine if the block is Data, Map, or
Replacement page, compare the least significant 8 bits to 40H and/or 60H.
The FTL assigns a virtual address to each Virtual Block in the contiguous array of blocks presented
to higher level software layers. The virtual address is computed by multiplying a Virtual Block's
sequence number (zero to n - 1) by the size of a Virtual Block. The first Virtual Block is always at
virtual address zero (0) as indicated by a block allocation entry of 00000040H. If the Virtual Block
size is 512 bytes, the second block's virtual address is 00000200 H and its block allocation entry is
00000240H. The third block's virtual address is 00000400H and its block allocation entry is
00000440H. See Figure 5-4: Block Allocation Map.
The Virtual Block Map (VBM) is built from the virtual addresses of Read/Write Blocks used to store
Virtual Block data. Read/Write Blocks containing Virtual Block data use positive virtual addresses.
If the VBM is maintained on the media, the Read/Write Blocks containing VBM Pages or
Replacements Pages use negative virtual addresses. The use of negative addresses is discussed
further in the sections that follow.
TRANSLATION LAYERS
Allocation information is maintained in one of two ways. First, allocation information for all of the
Read/Write Blocks in the Erase Unit may be stored together in an array in the unit known as the
Block Allocation Map (BAM). Second, allocation information may be stored in hidden areas next to
or related to the Read/Write Block to which it refers. The Flags field in the Erase Unit Header
describes how allocation information is stored on the media.
NOTE: For reverse polarity flash the block allocation information stored on the
media is inverted (for example, BAI entry 00000070H is FFFFFF8FH, etc.
when a reverse polarity flash device is used). See the ReversePolarityFlash
bit of the Flags field in the Erase Unit Header.
Erase Unit Header Contents of Read/Write Block

0 00000030 FTL control structure
Block Allocation Map BAM Index
2 00000440 Virtual Block 2
3 00000000 Superseded Data
4 FFFFFE40 Page -1 of Virtual Block Map
5 0002A440 Virtual Block 338 (152h)
6 FFFFFFFF Free
7 FFFFFA60 Page -3 of Virtual Block Map
Erase A portion of the Block Allocation Map

Unit Free Blocks,
Superseded Blocks, Notes on the Block Allocation Map: Each entry in the Block
Virtual Blocks, Allocation map describes the contents of a corresponding
Virtual Block Map Pages, Read/Write Block in the Erase Unit. This example uses a
and Replacement Pages block size of 512 bytes and the FTL partition does not store
checksums, CRCs or ECCs for Virtual Block data. All blocks
are numberd starting from 0.
The first two Read/Write Blocks of this Erase Unit store FTL
control structures: the Erase Unit header and the Block
Allocation Map. The third Read/Write Block (bytes 1024-1535
of the Erase Unit) contains data for the third Virtual Block used
by higher level software layers. The next Read/Write Block
(bytes 1536-2047) contains superceded data, while the block
following it contains data for Virtual Block Map Page #338.
Figure 5-4: Block Allocation Map
5.1.2.6 Virtual Block Map - Mapping Virtual Blocks to Logical Addresses

The FTL uses a data structure known as the Virtual Block Map (VBM) to map requests for virtual
blocks from higher level software layers to logical addresses on the media. The VBM is an array of
32-bit entries, each of which represents a logical address on the media where a Virtual Block's data
is stored. The virtual block number requested by higher level software layers is used as an index
into this array. See Figure 5-5: Virtual Block Map.
The VBM is subdivided into Pages. Each Page of the VBM is the same size as the Virtual Blocks
presented to the host system by the FTL.
The size of the VBM (in bytes) is determined by dividing the FormattedSize of the media by the
BlockSize and multiplying the result by the size of a VBM entry (32-bits or four bytes). The number
of Pages required for the VBM (NumVMPages) is the previous result divided by BlockSize and
rounded up to the nearest Page.
For example, if FormattedSize is 12 megabytes and BlockSize is 512 bytes, the media contains 24K
blocks. Each block has a four (4) byte entry in the VBM requiring 96 KBytes of the storage media to
store the VBM. Dividing the size of the VBM by the block size indicates NumVMPages is 192. Each
page of the VBM, in the example, is capable of recording the logical addresses used for 128 virtual
blocks or 64 KBytes of data storage.
Space is always reserved on the media to store a VBM large enough to track the allocation of all the
Virtual Blocks presented to higher level software layers by the FTL. However, when the media is
formatted, the FTL may indicate only a portion of the VBM is maintained on the media. The
FirstVMAddress field of the Erase Unit Header identifies the first virtual address on the media that
has an entry in the VBM maintained by the FTL.
If the FirstVMAddress is reset to zero (0), the FTL must maintain all of the VBM entries on the
media. If the FirstVMAddress exceeds the FormattedSize, none of the VBM entries are maintained
on the media by the FTL. If the FirstVMAddress is greater than zero (0), but less than the
FormattedSize, the FTL maintains VBM entries on the media for all virtual addresses greater than
or equal to the FirstVMAddress. The system should determine if it has adequate resources to mount
the media prior to mounting. All VBM entries stored on the media are in little-endian order.
When all or a portion of the VBM is not maintained on the media, the FTL must map requests for
Virtual Blocks in some other way. An FTL might create and maintain a VBM in host system RAM.
An FTL could also scan the media's block allocation information when each virtual block is
requested. The choice to maintain the VBM on the media is typically based on the availability of
system RAM and desired performance. Maintaining virtual to logical mapping information in
system RAM relieves the FTL of the overhead of updating the VBM on the media for frequently
updated Virtual Blocks.
If a VBM entry is all ones (FFFFFFFFH), the Virtual Block does not exist on the media. When asked
to read data from this Virtual Block, the FTL may return any combination of bytes, such as binary
0's, as long as this combination is consistently returned until the Virtual Block is written.
There are two possibilities if a VBM entry is all zeroes (00000000H). First, the logical address of the
Virtual Block is described on a Replacement Page. In this case, the FTL uses the logical address from
the Replacement Page to locate the block. Second, if there is no Replacement Page, the block does
not exist on the media. In the later case, when asked to read data from this Virtual Block, the FTL
may return any combination of bytes, such as binary 0's, as long as this combination is consistently
returned until the Virtual Block is written.
NOTE: For reverse polarity flash, the VBM entries stored on the media are inverted
(for example, VBM entry FFFFFFFFH is 00000000H, etc. when a reverse
polarity flash device is used). See the ReversePolarityFlash bit of the Flags
field in the Erase Unit Header.
TRANSLATION LAYERS
Notes on Virtual Block Map Pages: Each entry in a Virtual

Erase Unit Header
Block Map (VBM) corresponds to a Virtual Block in the
emulated block device the FTL provides to higher level
Block Allocation Map software layers. This example shows the portion of the Page
of the VBM that maps Virtual Blocks 128 through 131.
The 128th entry of the VBM contains the value A0600h. This
indicates the data corresponding to the 128th Virtual Block is
stored at offset A0600h of the media when the Erase Units are
accessed in logical order. This example assumes each Erase
Unit is 64 Kbytes, so this logical address further breaks down
to offset 0600h of LogicalEUN 10.
Erase
Unit Free Blocks, The entry for Virtual Block 130 has been updated and is stored
Superseded Blocks, in a Replacement Page. To locate the data for this block, the
Virtual Blocks, FTL must refer to the corresponding entry (in this case, the
Virtual Block Map Pages, third entry) on the Replacement Page for this Virtual Block Map
and Replacement Pages Page. If the Replacement Page entry for this block is also 0,
then the data no longer exists.
Logical Address of Virtual Block
128 000A0600 Offset 0600h of Logical EUN 10
129 000C0800 Offset 0800h of Logical EUN 12
VBM Index
130 00000000 Use Replacement Page Entry
131 0000CC00 Offset CC00h of Logical EUN 0
A portion of a Virtual Block Map Page
Figure 5-5: Virtual Block Map
5.1.2.7 Virtual Page Map - Locating the Pages of the Virtual Block Map
When the Virtual Block Map (VBM) is maintained on the media, the FTL must track the storage of
the Pages of the VBM. In the same manner that VBM entries indicate the logical address of a Virtual
Block, the entries of the Virtual Page Map (VPM) indicate the logical address on the media where
the Pages of the VBM are stored. Unlike the VBM, the VPM is never stored on the media. Where
the FTL stores the VPM is implementation dependent. See Figure 5-6: Page Mapping.
The block allocation information entries describing Virtual Block Map Pages use negative values to
distinguish them from the Read/Write Blocks used to store Virtual Block data which use positive
values. In the example used in the previous section, the VBM requires 192 Pages. If the entire VBM
is maintained on the media (see the previous section), each page of the VBM requires a Read/Write
Block to store the VBM entries found on the page.
Virtual Block Map Pages are numbered using negative values, therefore their virtual addresses are
negative. As with Virtual Blocks, the virtual address stored as the block allocation information for
these pages is computed by multiplying the page number by the size of a Virtual Block (which is
the same size as the Read/Write Block used to store the page's data). Returning to the previous
example, the first page of the VBM (used to store the logical addresses of the first 128 Virtual Blocks)
is number -192. The second page of the VBM is number -191 and the last page of the VBM is -1.
With a block size of 512 bytes, the first VBM Page in the example is virtual address FFFE8000H. The
virtual address of the second VBM Page is FFFE8200H, and the last VBM Page would be virtual
address FFFFFE00H. To locate an address within a VBM Page, take the sector requested modulo
128. Multiply this result but the Virtual Block entry width and this yields the correct offset within
the VBM Page.
Virtual Page Map VBM Pages Data Sectors

(Virtual Blocks)
0
VBM 0 - Page Map Logical Address
VBM 0 1
VBM 1 - Page Map Logical Address ... ...
127
0
VBM 1
1
... ...
127
.
. VBM 2 0
.
1
.
... ... .
127 .
.
.
.
VBM n-1
0
VBM n-1 - Page Map Logical Address 1

... ...
127
Logical to Physical Logical to Physical

address translation address translation
Figure 5-6: Page Mapping
5.1.2.8 Replacement Pages

Each page of the Virtual Block Map (VBM) may have a Replacement Page. Replacement pages may
be used to improve performance of a system. Values in a Replacement Page override entries in the
original VBM page as follows:
If an entry in an original VBM page is zero (0), the logical address of the Virtual Block is retrieved
from the corresponding entry on the Replacement Page. If there is no Replacement Page, or the
corresponding entry on the Replacement Page is zero (0), the Virtual Block does not exist on the
media.
Replacement Pages are used to improve performance by minimizing the need to supersede Pages
in the VBM when logical addresses on a Page are updated. To ensure compatibility with other host
systems, when reading, the system must be able to handle usage of one Replacement Page and
when writing is allowed to use up to one (1) at any one time.
Replacement Pages are allocated from Free Read/Write Blocks in any Erase Unit. The FTL locates
allocated Replacement Pages by scanning the block allocation information on the media. This scan
TRANSLATION LAYERS
may be performed when the media is inserted in the host system or when a VBM entry of zero (0) is
encountered. Replacement Pages may NOT be replaced.
The block allocation information entry for a Replacement Page uses the same virtual address as the
original VBM Page. The FTL distinguishes between the two using the least significant eight (8) bits
of the block allocation information. VBM Pages have a value of 40H in the these bits while
Replacement Pages have a value of 60H.
5.1.2.9 Mapping Logical Addresses to Physical Addresses

The addresses stored in the Virtual Block Map and Virtual Page Map arrays are logical addresses. A
logical address represents a location in the media described when the Erase Units are ordered in
LogicalEUN sequence. The FTL determines the relationship between LogicalEUN and PhysicalEUN
by scanning the media. As each Physical Erase Unit is encountered, its LogicalEUN is noted. Later,
the FTL uses this information to map the logical address in the VBM or VPM to a physical address
on the media where the data for the Read/Write Block is stored.
Since Erase Units are always sized as a power of two (2), the logical address may be considered to
contain a LogicalEUN in the most significant bits and an offset into the Erase Unit in the least
significant bits. Which bits represent the offset address and which bits represent the LogicalEUN
depend on the size of an Erase Unit.
As an example, if Erase Units were 64 KBytes, the low word of the logical address would be the
offset within the Erase Unit and the upper word of the logical address would be the LogicalEUN. If
the FTL maintains an array of PhysicalEUNs in LogicalEUN order, translating the LogicalEUN to a
PhysicalEUN is a simple matter of indexing into the array using the LogicalEUN from the upper
word of the logical address. Continuing with the example, the offset of the Read/Write Block storing
the data being mapped is the double word created by placing the PhysicalEUN in the upper word
and the offset into the Erase Unit into the lower word.

This section describes the data structures used on media formatted for the Flash Translation Layer
(FTL). Unless otherwise noted, all values stored in FTL data structure fields are in little-endian
format.
The FTL stores persistent allocation information on the media for each Virtual Block. This allocation
information is stored in the same Erase Unit as the Virtual Block. A Virtual Block Map (VBM) is
maintained by the FTL based on this allocation information that reorganizes the information into an
array of four byte entries that describe the logical location of a Virtual Block on the media.
The VBM may reside on the media or in a non-persistent space available to the host system such as
system memory. The portions of the VBM that are not stored on the media are built during FTL
initialization when new media is inserted based on the block allocation information stored in each
Erase Unit.
5.1.3.1 Erase Unit Header (EUH)

Each Erase Unit on the media contains an Erase Unit Header (EUH). The EUH is located at offset
zero (0) of the Erase Unit or at the location specified by the AltEUHOffset field of an EUH at offset
zero (0) of another Erase Unit. The Erase Unit Header contains information specific to the Erase Unit
and global information about the entire FTL partition.
Offset Field Size Detail/Description

0 LinkTargetTuple 5 This field contains a Link Target Tuple (see the Metaformat
Specification). The contents of this field are the same for all
Erase Units.
TPL_CODE CISTPL_LINKTARGET (13H)
TPL_LINK 3
TPLTG_TAG 'C', 'I', 'S'
5 DataOrganizationTuple 10 This field contains a CISTPL_ORG tuple (see the Metaformat
Specification). The contents of this tuple are the same for all
Erase Units. The value used for the TPL_LINK field is the number
of remaining bytes in the Erase Unit Header. The next tuple (after
the Erase Unit Header) may be an End-Of-List Tuple to terminate
the chain, or the tuple chain may continue with additional tuples.
TPL_CODE CISTPL_ORG (46H)
TPL_LINK At least fifty-seven (57), including the size of
the remaining fields in the Erase Unit Header.
TPLORG_TYPE TPLORGTYPE_FS (0)
TPLORG_DESC "FTL100", 0
15 NumTransferUnits 1 Number of Transfer Units in the partition. All FTL partitions have
at least one (1) Transfer Unit.
16 Reserved 4 This field shall be ignored when read and shall be set to the
deviceÕs erased state when written.
20 LogicalEUN 2 The Logical Erase Unit Number currently assigned to this unit.
The LogicalEUN of a formatted Transfer Unit is the media's
erased state (for most flash devices this is all ones or FFFFH).
22 BlockSize 1 The size of all Virtual and Read/Write Blocks. This field is
expressed as a log2 value. For example, for a block size of 512
bytes this field is set to nine (9). This field must be at least eight
(8) to represent the minimum block size of 256 bytes.
23 EraseUnitSize 1 The size of an Erase Unit. This field is expressed as a log2 value.
For example, for a unit size of 128 KBytes this field is seventeen
(17). Erase Units are always a multiple of the flash device's erase
zone size.
24 FirstPhysicalEUN 2 The Physical Erase Unit Number where the FTL partition begins.
If the partition starts at physical address zero (0), this value is zero
(0).
26 NumEraseUnits 2 Total number of Erase Units in the FTL partition. This field
includes Erase Units used to store data, block allocation
information, checksums (if present), transfer units, replacement
pages, spare blocks and the Virtual Block Map. The total number
of Erase Units also includes bad units.
28 FormattedSize 4 The formatted size of the partition. This is the total space available
to the host system for data storage. This field does not include
space marked as format blocks or used to for transfer units,
replacement pages and the Virtual Map. Formatting utilities should
also exclude a few additional blocks to use as spares. Without
spare blocks, a Unit Recovery Procedure is required anytime a
Virtual Block is updated after all the Virtual Blocks have been
written once. This field is expressed in bytes. This field must be a
multiple of BlockSize.
32 FirstVMAddress 4 The first virtual address for which Virtual Block Map (VBM)
entries are maintained by the FTL on the media. If this field is zero
(0), the entire VBM is maintained on the storage media. If this field
exceeds the FormattedSize field, none of the VBM is maintained
on the media. However, space for the entire VBM must be
available on the media at all times.
36 NumVMPages 2 Number of Pages in the Virtual Block Map (VBM). If the
FirstVMAddress field is greater than the FormattedSize field, the
FTL does not maintain the VBM on the media, even though space
is reserved on the media. If the FirstVMAddress field is less than
the FormattedSize field, some or all of the VBM stored on the
media is maintained by the FTL.
TRANSLATION LAYERS
38 Flags 1 Bit-mapped field describing how checksum and block allocation

information are stored on the media and the polarity of the media.
See 5.1.3.2 Flags below.
39 Code 1 Binary value describing the type of Checksum, CRC or ECC
information maintained for Virtual Block data. If this value is the
erase state of the media, no such information is present. If this
value is the non-erase state of the media, such information was
present at one time, but is no longer being maintained. Any other
value indicates the type of information being maintained.
If this value is set to one (1), a two (2) byte checksum is computed
and maintained for each Virtual Block. These two (2) byte
checksums are computed by adding each byte of the Virtual Block
to a 16-bit value initially set to zero (0) and ignoring overflow. The
checksum is stored in little-endian format. Where the checksum is
stored depends on the setting of the HiddenAreaFlag of the Flags
field.
Any other value than those described above is reserved for future
expansion.
40 SerialNumber 4 Partition serial number. May be used to distinguish between
partitions and/or PC Cards.
44 AltEUHOffset 4 Offset of an alternate Erase Unit Header. Used when it is not
possible to write an Erase Unit Header at offset zero (0) of the
Erase Unit. If used, the value in this field is the same for all Erase
Units in the partition. However, the FTL always attempts to place
the EUH at offset zero (0). For each Erase Unit the FTL is able to
place the EUH at offset zero (0), the alternate location is not used.
When all Erase Unit Headers are at offset zero (0) and there is no
Alternate Erase Unit Header in use, this field shall be in the erase
state of the media. This allows an Alternate EUH to be assigned at
run-time, if the beginning of an Erase Unit should go bad during
use.
Should an Alternate EUH be assigned at run-time, all EUHs must
be updated to reflect the AltEUHOffset.
The FTL first searches for the EUH at offset zero (0) of the Erase
Unit. Only if the EUH is not found there does the FTL search at the
location specified by this field. This presumes the FTL has
successfully read an EUH at offset zero (0) of another Erase Unit
to determine the location used for Alternate EUHs. If an EUH
cannot be found at either location, the FTL assumes the Erase Unit
is unformatted.
The AltEUHOffset should be an integer multiple of 4 Kbytes.
48 BAMOffset 4 The offset from the start of the Erase Unit Header to the Block
Allocation Map (BAM) contained in the Erase Unit. This field is
expressed in bytes. This field is only valid if the Flags -
HiddenAreaFlag is reset to zero (0). The Block Allocation Map is
not required to be aligned on a virtual block boundary. It may
immediately follow the tuple chain encapsulating the Erase Unit
Header.
If the Flags - DoubleBAI is set to one (1), two copies of the BAM
are present on the media. The second copy follows the first copy
and precedes any Checksum, CRC or ECC information.
If an Erase Unit is using Checksums, CRCs or ECCs as indicated
by the Code field, these codes shall follow the block allocation
information. If the allocation information is stored in the BAM, an
array of codes follow the array of allocation information in the
BAM.
52 Reserved 12 Reserved for future use. This field shall be left in the media's
erased state. For most flash devices this is all ones (FFH).
64 FTLRevisionTuple 114 This optional field contains an FTL Revision Tuple. The contents of
this field are the same for all Erase Units.
TPL_CODE vendor unique (80H)
TPL_LINK 10
FTL-VER 'FTL VER x.x' where x.x is the ASCII
equivalent version number of the FTL specification that the
software is compliant to. For example, FTL version 1.1 would
have entries 46H, 54H, 4CH, 20H, 56H, 45H, 52H, 31H, 2EH, 31H.
5.1.3.2 Flags
The bit-mapped Flags field of the Erase Unit Header describes how checksum and block allocation
information is stored on the media and identifies the media's erase state.
Bit Description
0 HiddenAreaFlag - This flag indicates whether checksum and allocation information are stored in the Block
Allocation Map (BAM) or the media has hidden, alternate storage areas for such information that do not appear in
the media's normal address space.
If this bit is set to one (1), checksum and/or allocation information are stored in hidden areas outside of the media's
normal address space.
If this bit is reset to zero (0), any checksum and/or allocation information are stored in the media's normal address
space. The Block Allocation Map (BAM), an array of all of the block allocation information, precedes an array of
the checksum information.
1 ReversePolarityFlash - This flag indicates whether the media's flash memory devices erase to all ones or to all
zeroes.
If this bit is set to one (1), the flash memory devices erase to all zeroes (0) and may be written to one. When this
bit is set, all block allocation information, Virtual Map entries and LogicalEUNs must be inverted before they are
written to the media and after they are read from the media.
If this bit is reset to zero (0), the flash memory devices erase to all ones (1) and may be written to zero. When this
bit is reset, all block allocation information, Virtual Map entries and LogicalEUNs are read and written without
inversion.
2 DoubleBAI - This flag indicates whether there are one or two copies of the block allocation information stored on
the media.
If this bit is set to one (1), two copies of the block allocation information are present on the media. If this
information is stored in BAMs, there are two complete BAMs on the media. In this case, the first BAM begins at
the location specified by the BAMOffset field and the second BAM begins immediately after the first. If the block
allocation information in stored in hidden areas, as indicated by the HiddenAreaFlag, the second entry for a
Read/Write Block follows the first. Both copies of the block allocation information precede any Checksum, CRC
or ECC codes.
If this bit is reset to zero (0), only one copy of the block allocation information is stored on the media.
3 .. 7 Reserved for future use. All of these bits must be reset to zero (0).

Flash Translation Layers (FTLs) may be identified in two ways. They may be explicitly identified in
a PC Card's Card Information Structure (CIS) or they may be recognized by searching the storage
media for FTL data structures.
If the CIS contains partition information, an FTL partition is identified by the Data Organization
Tuple (CISTPL_ORG, 46H). (See the Metaformat Specification for details on describing partitions in
the CIS.) An FTL Data Organization Tuple is formatted as follows:
Byte D7 D6 D5 D4 D3 D2 D1 D0
0 Tuple Code CISTPL_ORG, 46H
1 Tuple Link Link to next tuple (at least 07H)
2 TPLORG_TYPE TPLORGTYPE_FS, 00H
3 .. 9 TPLORG_DESC "FTL100\0" Null terminated string identifying FTL partition
TRANSLATION LAYERS
If the entire storage media is used by an FTL, the CIS is not required to contain partition
information. In this case, an FTL partition is recognized if an FTL Erase Unit Header (see 5.1.3 Data
Structures, above) is found in the first megabyte of the storage media and the information in the
Unit Header is valid. The procedure for recognizing and validating an FTL Erase Unit Header is
described in the following paragraphs.
The first step in recognizing an FTL partition is confirming the presence of the FTL Data
Organization Tuple described above at offset five (5) of the Erase Unit Header. Since Erase Unit
Headers always begin at offset zero (0) of an Erase Unit and an Erase Unit is always a multiple of a
flash device's erase zone size, the search is limited to the first fifteen bytes of each flash erase zone
in the first megabyte of the storage media. If the flash erase zone size is not known, the search for
an Erase Unit Header is made in four (4) KByte increments.
If the FTL Data Organization Tuple is not found within the first megabyte of the partition area, the
media is not an FTL data store. If the tuple is found, the rest of the Erase Unit Header must be
validated. All Erase Units should have identical EUHs with the exception of the Logical EUN and
reserved fields. One level of validation would be to check to see that all EUHs are the same. Further
validation could include verifying that the FormattedSize is a multiple of the BlockSize, that the
BlockSize is smaller than the EraseUnitSize, and that there is at least a 30H ID at the address that the
BAMOffset points to. The validation process may also be used to build a dynamic map of the logical
to physical translation performed by the FTL.
The FTL then reads every Erase Unit Header on the media, starting with the unit described by the
FirstPhysicalEUN field. If not found at offset zero, the FTL looks for the Erase Unit Header at the
location specified by the AltEUHOffset field of other Erase Units. If an Erase Unit Header is not
found at either location, the Erase Unit is considered an unformatted Transfer Unit. If two units are
found with the same value in the LogicalEUN field, either of the units may be assumed to be a
Transfer Unit. After all Erase Unit Headers have been read, the number of units with non-negative
and distinct LogicalEUN fields must equal the NumEraseUnits field less the NumTransferUnits
field.
The number of Virtual Blocks used to store the Virtual Block Map (VBM) on the media is indicated
by the NumVMPages field in the Erase Unit Header. During the block allocation scan, the FTL
locates VBM Pages and Replacement Pages. The number of VBM Pages located must match the
value in the NumVMPages field. If a VBM Page is missing and a Replacement Page exists, the
Replacement Page is used in place of the original VBM Page. If a VBM Page is missing and a
Replacement Page does not exist, implementation dependent recovery operations are required. If
duplicate VBM Pages are found, all but one is ignored.
The assignment of Replacement Pages is implementation specific. A Replacement Page is indicated
by allocation information having the same virtual address as an original VBM Page with the least
significant eight (8) bits set to 60H.

A Flash Translation Layer (FTL) partition is prepared for use as follows:
Determine the appropriate values for global fields in the Erase Unit Header:
DataOrganizationTuple
BlockSize
EraseUnitSize
FirstPhysicalEUN
NumEraseUnits
NumTransferUnits
FormattedSize
FirstVMAddress
NumVMPages
Flags
SerialNumber
AltEUHOffset
BAMOffset
For each Erase Unit on the media: Erase the unit and write out an Erase Unit Header with unit
specific data. Unit specific data includes the following field:
LogicalEUN
LogicalEUNs range from zero (0) to one less than the NumEraseUnits field less the
NumTransferUnits field. The order LogicalEUNs are assigned is not significant as long as each is
unique in the above range. The LogicalEUN of Transfer Units is left in the media's erased state (for
most flash devices this is all ones or FFFFH). See the ReversePolarityFlash bit of the Flags field.
For each Read/Write Block used to store Erase Unit Headers and the Block Allocation Map (if used)
set the allocation information to 30H to indicate the blocks contain formatting data.
Once the FTL has prepared the media, any block-oriented file system may store its data formats on
the media using the FTL to translate Virtual Block requests to the appropriate locations on the
media.
5.1.6 Logical Block Operations

This section describes how the FTL performs accesses to Virtual Blocks on the media.
5.1.6.1 Read
Higher level software layers request a Virtual Block from the FTL. The FTL uses the number of the
Virtual Block as an index into the Virtual Block Map (VBM). The entry in the VBM is the logical
address where the Virtual Block data is stored. The FTL converts the logical address to a physical
address. The conversion from logical to physical is based on the relationship of the LogicalEUN
containing the logical address to the physical Erase Unit used for the logical Erase Unit. The FTL
transfers the data block at this location into the buffer provided by the host file system.
If an entry in the VBM is all ones (FFFFFFFFH), the block does not exist on the media. The FTL
the Replacement Page to locate the block. Second, if there is no Replacement Page or the entry on
the Replacement Page is all zeroes or Fs (00000000 H or FFFFFFFFH), the block does not exist on the
media. In the later case, when asked to read data from this Virtual Block, the FTL may return any
combination of bytes, such as binary 0's, as long as this combination is consistently returned until
the Virtual Block is written.
Some mechanism should be employed to ensure proper handling if a power cycle is received while
accessing the flash device.
5.1.6.2 Write
When writing Virtual Block data to the media, the FTL must first locate a free Read/Write Block. If
a free block is not available, one is created using the Unit Recovery Procedure described below.
TRANSLATION LAYERS
Once a free block is located, block allocation information for the area is marked to indicate a write
operation is beginning by resetting the least significant bit (FFFFFFFEH). Once the write has been
successfully completed, the block allocation information in the Erase Unit is updated to reflect the
Virtual Block's virtual address.
Next, the Virtual Block Map is updated to reflect the new area assigned to the Virtual Block. Finally,
if the new block replaces an existing block, the Read/Write Block used to store the superseded data
is marked as deleted by resetting its block allocation information to zero (00000000H).
If the write process is interrupted at any point, the FTL is able to recover with minimal effort. If the
interruption occurs before the data write completes, the block allocation information (FFFFFFFEH)
indicates the block shall be treated as deleted and normal activity will recover the space when
required.
If an interruption occurs after the block allocation information is updated, but before the VBM is
updated, both Read/Write Blocks have the same block allocation information. This can also occur if
the update of the VBM entry completes, but the superseded Read/Write Block's allocation
information is not marked as deleted. In either case, the FTL selects the block pointed to by the
VBM and treats the other block as superseded. The system is allowed to use up to one (1)
Replacement Page during writes.
5.1.6.3 Unit Recovery

Deleted and/or superseded Read/Write Blocks may only be re-used after they are erased. All of
the Read/Write Blocks in an Erase Unit must be erased at the same time. Rarely are all of the
Read/Write Blocks within an Erase Unit deleted and/or superseded. The Unit Recovery Procedure
performs the necessary processing to safely preserve data in allocated Read/Write Blocks and
recover deleted and/or superseded blocks.
The first step is to locate a properly prepared Transfer Unit. To be properly prepared, the area used
to store Virtual Block data, Virtual Block Map Pages, Replacement Pages and block allocation
information must be erased and the global fields of the Transfer Unit's Erase Unit Header must be
initialized. A formatted Transfer Unit contains the EUH and BAM. The BAM contains only Control
(30H) entries for the FTL structures for that Transfer Unit.
Before Read/Write Block data from the Erase Unit being recovered is copied to the Transfer Unit,
the LogicalEUN of the Transfer Unit is set to 7FFFH. After allocated Read/Write Blocks have been
successfully transferred, the Transfer Unit's LogicalEUN is set to the LogicalEUN of the Erase Unit
being recovered. If the Unit Recovery Procedure is interrupted, the Transfer Unit's LogicalEUN
remains 7FFFH, and the FTL can determine the Transfer Unit is not properly prepared.
After all allocated Read/Write Blocks have been successfully moved to the Transfer Unit and the
LogicalEUN updated, the original Erase Unit is erased and formatted as a Transfer Unit. If the Unit
Recovery procedure is interrupted before the original Erase Unit is erased, the FTL will find two
Erase Units with the same data. The FTL may use either Erase Unit as the specified Logical Erase
Unit and the other Erase Unit becomes a Transfer Unit.

virtual blocks.
6 . ST OR AGE DE V IC E S
PC Cards use a number of storage technologies with various read, write, erase and access
characteristics. The relative performance of a technology is often affected by the data storage format
used to record information on a PC Card. The characteristics of some technologies may dictate a
particular access method or may prohibit or severely limit the ability to use a particular file format.
6.1 Static RAM Cards

S-RAM device allow byte-oriented read and write access and do not require the media to be erased
before it may be written. This allows S-RAM PC Cards to store data without requiring a translation
layer. S-RAM memory devices on a PC Card may be mapped into host system memory and
directly accessed.
6.2 Flash Memory Cards

Flash memory devices may allow byte-oriented read and write access or may require block-oriented
access. Flash memory devices typically require the media to be erased before it may be written and
usually require an erase operations to be performed in blocks of contiguous bytes. The size of an
erase block varies among flash devices, ranging from small blocks of 256 or 512 bytes to blocks of 64
KBytes or more. Most linear flash memory PC Card may be mapped into host system memory and
directly accessed.
Unless access will be read-only, using traditional file systems with flash media is problematic due to
the unique characteristics of flash devices. Two methods are used to deal with flash media.
First, custom file systems designed especially for data storage on flash devices may be developed.
These file systems use a byte-oriented access to the media as opposed to the traditional block access.
In addition, file allocation is typically handled using linked lists which allow file updates to be
routed to erased areas of the media and the previously allocated areas marked as available for
recovery. When all erased space has been used, a recovery routine creates, clears and erases a
contiguous block of marked areas to allow them to be reused.
The second method for using flash media adds an additional translation layer between the
traditional file system and the flash media. The file system continues to read and write sector-sized
blocks, but instead of mapping directly to physical sectors, the translation layer tracks media use,
remaps sector write requests to erased areas and marks the previously used sector(s) as available for
recovery. Subsequent read requests are translated to access the appropriate remapped sectors.
6.3 PC Card ATA Drives

PC Card ATA drives use block-oriented read and write access and do not require the media to be
erased before it is written. PC Card ATA drives are typically used with traditional block-oriented
file systems and do not require a translation layer. The data storage area of a PC Card ATA drive is
usually accessed indirectly. Information is transferred between a PC Card ATA drive and the host
system by placing request parameters into task file registers located on the card.
Volume 7
Media Storage Formats Specification
PCMCIA
JEIDA
+1-408-433-9558 (Fax) IMPORTANT:
+81-3-3433-1923 PCMCIA
INFRINGEMENT,
YOU ÒAS IS.Ó

CONTENTS
1. Introduction ___________________________________________ 1
1.1 Purpose................................................................................................................................1
1.2 Scope....................................................................................................................................1
2. Overview ______________________________________________ 3
2.1 Storing Data.........................................................................................................................3
2.2 Partitions..............................................................................................................................3
2.3 Files and File Systems..........................................................................................................3
2.4 Storage Media......................................................................................................................3
2.5 In Summary.........................................................................................................................4
3. Partitions ______________________________________________ 5
3.1 Card Information Structure (CIS) Partitioning ..................................................................6
3.1.1 Overview ......................................................................................................................................................................................6
3.1.2.1 Creation..........................................................................................................................................................................6
3.1.2.2 Deletion ..........................................................................................................................................................................6
3.1.2.3 Extension .......................................................................................................................................................................7
3.1.3 Initial Program Load...............................................................................................................................................................7
3.1.4 Data Structures...........................................................................................................................................................................7
3.2 Master Boot Record (MBR)..................................................................................................8

3.2.1 Overview ......................................................................................................................................................................................8
3.2.2.1 Creation..........................................................................................................................................................................8
3.2.2.2 Deletion ..........................................................................................................................................................................9
3.2.2.3 Extension .......................................................................................................................................................................9
3.2.4 Data Structures.........................................................................................................................................................................1 1
3.2.4.1 Master Boot Record.................................................................................................................................................1 1
3.2.4.2 Partition Entry...........................................................................................................................................................1 1
4. File Formats___________________________________________ 13
4.1 MS-DOS BPB/FAT Format ..............................................................................................13
4.1.1 Overview ....................................................................................................................................................................................1 3

CONTENTS
4.1.2.1 12-Bit FATs.................................................................................................................................................................1 4

4.1.2.2 16-Bit FATs.................................................................................................................................................................1 4
4.1.2.3 Huge Partitions..........................................................................................................................................................1 4
4.1.5 File Operations .........................................................................................................................................................................1 5
4.1.5.1 File Creation ...............................................................................................................................................................1 5
4.1.5.2 File Deletion................................................................................................................................................................1 5
4.1.5.3 Read and Write Operations..................................................................................................................................1 5
4.1.7 Data Structures.........................................................................................................................................................................1 6
4.1.7.1 Partition Boot Record (PBR).................................................................................................................................1 6
4.1.7.2 BIOS Parameter Block (BPB)................................................................................................................................1 7
4.1.7.3 Directory Entry .........................................................................................................................................................1 8
4.2 Linear File Store .................................................................................................................19

4.2.1 Overview ....................................................................................................................................................................................1 9
5. Translation Layers ____________________________________ 23

5.1 Virtual Block Device Flash Translation Layer - FTL ........................................................24
5.1.2 Overview ....................................................................................................................................................................................2 4
5.1.2.1 Emulating Traditional Block Devices - Virtual Block Device................................................................2 4
5.1.2.2 Flash Characteristics...............................................................................................................................................2 4
5.1.2.3 Erase Zones and Erase Units ...............................................................................................................................2 6
5.1.2.4 Erase Unit Header and Block Allocation Information ..............................................................................2 7
5.1.2.5 Block Allocation Information and the Block Allocation Map (BAM) .................................................2 8
5.1.2.6 Virtual Block Map - Mapping Virtual Blocks to Logical Addresses...................................................3 0
5.1.2.7 Virtual Page Map - Locating the Pages of the Virtual Block Map .........................................................3 2
5.1.2.8 Replacement Pages ...................................................................................................................................................3 3
5.1.2.9 Mapping Logical Addresses to Physical Addresses ..................................................................................3 4
5.1.3 Data Structures.........................................................................................................................................................................3 4
5.1.3.1 Erase Unit Header (EUH)......................................................................................................................................3 4
5.1.3.2 Flags ..............................................................................................................................................................................3 7
5.1.6 Logical Block Operations.....................................................................................................................................................3 9
5.1.6.1 Read...............................................................................................................................................................................3 9
5.1.6.2 Write..............................................................................................................................................................................3 9
5.1.6.3 Unit Recovery.............................................................................................................................................................4 0
6. Storage Devices _______________________________________ 43

6.1 Static RAM Cards..............................................................................................................43
6.2 Flash Memory Cards .........................................................................................................43
6.3 PC Card ATA Drives ........................................................................................................43
FIGURES
Figure 5-1: Erase Zones .................................................................................................................26
Figure 5-2: Read/Write Blocks......................................................................................................27
Figure 5-3: Erase Unit Layout.......................................................................................................28
Figure 5-4: Block Allocation Map .................................................................................................30
Figure 5-5: Virtual Block Map.......................................................................................................32
Figure 5-6: Page Mapping.............................................................................................................33

1.1 Purpose
This document describes how data is formatted on PC Cards used as storage devices to promote the
exchange of these cards among different host systems. These include memory cards using various
types of volatile and non-volatile devices and ATA disk drives, both silicon and rotating media.
Each of these storage technologies have unique characteristics which may benefit from different
storage techniques and handling. This has resulted in the development of different storage formats
and/or partitioning for PC Cards using these devices.
NOTE: The inclusion of a partition, file format, or media type information in this
document does not constitute an endorsement by PCMCIA or JEIDA.
PCMCIA and JEIDA are only acknowledging this information has been
used to record data on a PC Card and, in some cases, that PCMCIA/JEIDA
members have agreed that using the documented implementation may
reduce problems encountered when attempting to interchange data
between host systems.
1.2 Scope
This document is intended to provide enough information to allow software developers to use data
stored on PC Cards by other host systems using potentially different operating and file systems.
Unless required to understand the data structures used on the PC Card, algorithms for updating the
data on the PC Card are not specified, only the storage format.

Volume 11. PC Card Host System Specification
Microsoft Corporation, Microsoft MS-DOS Programmer's Reference, 2nd edition: version 6.0, 1993,
Microsoft Press.
2. O V E R V IE W
2.1 Storing Data

Most computer programs need to store and retrieve information. While running, a program may
use system memory for limited amounts of information, but often more information is required than
may fit in memory. In addition, when a program terminates, the system memory it was using is re-
used by other programs and information may be overwritten and lost.
To accommodate large and long-term storage needs, information is stored on disks and other types
of external media. Several types of PC Cards are used to store information including static RAM
(SRAM) and flash memory cards and silicon and rotating media PC Card ATA drives.
2.2 Partitions
Storage media may be divided into separately addressable areas known as partitions. Each partition
is addressed by a file system as if it were a separate storage device with its own directory and
allocation information.
To minimize the number of storage formats a file system needs to be able to recognize to avoid
erroneously assuming a partition or PC Card is unformatted, the Card Services Specification
provides two services which return partition information. They are GetFirstPartition and
GetNextPartition. A Card Services implementation determines partition information using the CIS
or by performing searches for file system specific data structures.
2.3 Files and File Systems

Information is usually stored in units called files. Files are managed by a file system, usually a part
of or an extension to an operating system. The file system records the structure used to store files in
a system file or area known as a directory. Each file typically has a record in the directory known as
a directory entry.
A file system also keeps track of where files are stored on the media and what areas are available.
A file system keeps track of storage space in units known as blocks or clusters. Block devices are
usually limited to reading or writing information in units known as sectors. A block or cluster may
be one sector or may be two or more contiguous sectors. By making blocks or clusters more than one
sector, a file system reduces the amount of storage required to track whether or not space on the
media is allocated.
2.4 Storage Media

PC Cards provide several technologies for storing information, each with its own unique
requirements. Static RAM (SRAM) devices are the most flexible allowing any byte to be separately
read or written.
Flash memory devices may allow byte or block accesses for reads, but require special write
algorithms and pre-erased bytes before most write operations. In addition, flash device require
erase operations to be performed on a block of contiguous bytes as a single unit.
OVERVIEW
PC Card ATA drives are accessed in the same manner as traditional block devices requiring an
entire sector be read or written at one time. The actual storage media may be silicon or magnetic
oxide on a rotating disk.
2.5 In Summary
To access data on storage media requires a complete understanding of how the media is partitioned,
the file format used and whether a translation layer is used. Client device drivers first check the
Card Information Structure (CIS) to determine if a PC Card is partitioned. If the card is partitioned,
the tuples used to describe the partition also describe the storage format used on the media.
3 . PAR T IT ION S
PCMCIA/JEIDA recognize two methods for partitioning PC Cards. First, linear memory PC Cards
such as flash and S-RAM cards use tuples in the Card Information Structure (CIS) to describe how a
PC Card is partitioned. Second, PC Card ATA drives are partitioned using a Master Boot Record
with a partition table.
Each recognized partitioning method is described separately in the following sections. The following
information is provided about each recognized method:
Overview An overview of the partitioning method and where it is
used.
Partition Operations How partition operations are performed.
Initial Program Load How a host system boots using the partitioning method.
Data Structures The data structures used by the partitioning method.
All PC Cards used for data storage must provide partition information as described in this section.
PC Cards used for data storage that do not contain partition information described in this section
may be assumed to be unformatted.
PARTITIONS
3.1 Card Information Structure (CIS) Partitioning
3.1.1 Overview
The PC Card's CIS describes partitions using the following tuples:

Format CISTPL_FORMAT 41H
Organization CISTPL_ORG 46H
Both tuples must be present. The Format Tuple describes where that partition is located on the
media and the Organization Tuple identifies the data storage format used within the partition. Data
storage within a partition is also affected by the following tuples, if they are present:

Geometry CISTPL_GEOMETRY 42H
Byte-Order CISTPL_BYTEORDER 43H
Software Interleave CISTPL_SWIL 23H
3.1.2.1 Creation
A partition is created by adding the tuples described above to a PC Card's Card Information
Structure (CIS). The ability to write to a PC Card's CIS is dependent on the card and potentially
installed device drivers. A PC Card may require that the entire CIS be erased and then re-written to
modify the CIS.
Some PC Cards use multiple tuple chains to describe physical characteristics of the card separately
from how the card is used. For example, a primary tuple chain in a PC Card's attribute memory
space might describe the physical characteristics of the card, such as the type and size of the
memory device used on the card. A secondary tuple chain, in the PC Card's common memory
space, might be used to describe the logical characteristics of the card, such as the partitioning. In
this manner, the PC Card might be manufactured with the physical information hard-coded into
read-only memory in attribute memory space and logical partitioning information would be added
by using writable memory in common memory space. (See the Metaformat Specification for more
information about how tuple chains are linked together within the CIS.)
3.1.2.2 Deletion
To delete a partition, all of the tuples describing the partition must be deleted from the Card
Information Structure (CIS). Depending on the PC Card, the CIS may have to be erased and then re-
written without the tuples that describe the partition.
3.1.2.3 Extension
Some PC Cards allow the Card Information Structure to be extended without erasing existing tuples.
These cards permit additional partitions to be defined by adding tuples to the end of the last tuple
chain on the PC Card.

Host software evaluates partition information as it is encountered in the Card Information Structure
(CIS). If host software recognizes a partition type, the next available drive specifier is assigned to the
partition. If there are multiple partitions of different types on a PC Card, each partition type may be
recognized by a separate host device driver. For this reason, the order host drive specifiers are
assigned to partitions is host system specific.

The PC Card Standard does not currently define a method for booting from a PC Card using
partition definitions in the CIS.

See the Metaformat Specification for a complete definition of the tuples used to describe partitions.
PARTITIONS
3.2 Master Boot Record (MBR)
3.2.1 Overview
PC Card ATA drives are partitioned using a Master Boot Record (MBR) with a Partition Table in the
first physical sector of the media.. Partition Table Entries describe the size, location and type of data
within a partition. A Partition Table Entry may also describe an Extended Partition which is further
divided into one or more partitions.
The MBR contains a word of 55AAH at offset 1FEH. The sector contains operating system
independent code to perform Initial Program Load on x86 architecture host systems. For system and
PC Card interoperability, all systems, including those that do not use the IPL code for booting, must
include such information when formatting the MBR. The MBR also contains a Partition Table with
four (4) Partition Table Entries at offset 1BEH. When booting from a device with an MBR on an x86
architecture system, code within the MBR evaluates the Partition Table for a partition marked as the
default boot partition. Only one partition may be marked as the default boot partition.
If the x86 bootstrap code locates a default boot partition in the MBR's Partition Table, the Partition
Boot Record (PBR), the first sector of the partition, is loaded into memory. If the word at offset 1FEH
of the PBR is 55AAH, control is passed to the next stage bootstrap loader in the PBR image in
memory.
During operating system initialization, MBRs on all fixed disk devices are evaluated by the file
system for partition definitions in reverse order starting with the entry at offset 1EEH. The host
system assigns unit designations (drive letters under MS-DOS), to each partition matching a type
supported by the file system.
3.2.2.1 Creation
A partition is created by setting the fields of a partition entry in the partition table of the Master
Boot Record (MBR) to describe the desired partition. A partitioning utility first reads the MBR into
host system memory. If the word at offset 1FEH of the MBR is not 55AAH, the device is not
formatted and the utility must create an initial MBR with an empty partition table before preceding.
If the word at offset 1FEH of the MBR is 55AAH, the partitioning utility searches the partition table
for an empty entry. An entry is considered empty if the NumSectors field is zero (0). If there are no
empty entries in the partition table, a partition cannot be created.
If there is an empty partition entry, the partitioning utility creates a new partition using contiguous
unallocated space on the media. The utility determines if there is any available space on the media
by subtracting the space allocated to other partitions from the total size of the media. The total size
of the media is determined in a host system dependent manner. For example, on x86 systems with
a PC-compatible ROM BIOS the Get Drive Parameters function (Int 13H Function 8) is typically
used.
If there is unallocated space on the media, the partitioning utility must also determine where the
space is located by comparing the Start and End of each allocated partition. How a partitioning
utility decides which space to use when multiple unallocated spaces are available is implementation
specific.
After a partition entry is created the partitioning utility needs to notify the host system of the
change to the MBR.
A partition table entry uses Cylinder, Head and Sector (CHS) addressing to describe the starting
and ending boundaries of a partition. Some PC Card ATA drives translate their physical CHS
information to logical values that are compliant with limits imposed by some host systems that are
unable to address cylinder, head or sector values that exceed system-specific limits. Once a partition
table entry has been created, all subsequent accesses to the media must use the same logical CHS
addressing.
The PC Card Standard requires that all partitions described in the partition table within the MBR
end on a logical cylinder boundary based on the logical CHS addressing in use when the first
partition was created. This allows a host system to validate the logical CHS addressing in use is
correct by confirming the maximum head and sector values used for media access are the same as
those used to indicate the ending head or sector of all partitions on the media.
3.2.2.2 Deletion
A partition is deleted by resetting all of the fields of a partition entry in the partition table of the
Master Boot Record to zero (0). After a partition entry is deleted the partitioning utility needs to
notify the host system of the change to the MBR.
3.2.2.3 Extension
Some partition types extend the partition table in a system-specific manner. For example, MS-DOS
defines a special partition type called the Extended MS-DOS partition. The space allocated to an
Extended MS-DOS partition is sub-divided into logical drives. The first sector of an Extended MS-
DOS Partition contains a partition table formatted in the same manner as the partition table in a
Master Boot Record (MBR). The extended partition table typically contains two entries, an MS-DOS
partition and another Extended MS-DOS partition entry.
The MS-DOS partition entry in an extended MS-DOS partition describes a logical drive. If an
Extended MS-DOS partition entry is also present in the partition table, another potential logical
drive may exist within the area described by the Extended MS-DOS partition entry. Extended MS-
DOS partition entries create a forward-linked list of logical drives within the Extended MS-DOS
partition in the MBR.
The one difference between partition entries in an MBR and partition entries in the partition table in
an Extended MS-DOS partition is the StartSector field of the partition entries. In the MBR this field is
relative to the beginning of the media. In an Extended MS-DOS partition this field is relative to the
beginning of the Extended MS-DOS partition described in the MBR.

The order partition entries are evaluated in the partition table of the Master Boot Record (MBR) is
dependent on the operating system. For example, MS-DOS evaluates primary partition types on the
first two physical fixed drives on x86 systems addressed by the ROM BIOS Int 13H Disk I/O
handler as drives 80H and 81H. Primary partition types are 01H, 04H and 06H.
If the first physical fixed drive has a primary partition, MS-DOS assigns the next available logical
drive letter to the partition. If there is a second physical fixed drive and it has a primary partition,
MS-DOS assign the next available logical drive letter to this partition. After MS-DOS assigns the
primary partition types on the first two physical fixed drives as logical drives, Extended MS-DOS
partitions are evaluated.
If the first physical fixed drive has an Extended MS-DOS partition, each logical drive described in
the chain of Extended MS-DOS partitions is added as a logical drive letter. If there is a second
PARTITIONS
physical fixed drive and it has an Extended MS-DOS partition, each logical drive described in the
chain of Extended MS-DOS partitions is added as a logical drive letter.

The PC Card Standard does not describe a system independent method for booting from a device
with a Master Boot Record (MBR). However, x86 systems use the MBR as the first stage of a multi-
stage program loader. The host system reads the MBR of the first physical drive into host system
memory at 0000H:7C00H. If the word at offset 1FEH of the MBR is not 55AAH, the media is not
bootable and the system continues the boot process with another device or displays an error
message.
If the word at offset 1FEH of the MBR is 55AAH, the host system transfers control to the code at
0000H:7C00H. No arguments are provided to the code by the host system. No stack is established
and no indication of which device the MBR was read from is provided.
The boot code in the MBR evaluates the partition table from the last entry at offset 1EEH to the first
entry at 1BEH. If an entry is found with the default x86 boot partition field set to 80H, the first sector
of the partition described by the partition entry, known as the Partition Boot Record (PBR), is loaded
into host system memory. If the word at offset 1FEH of the PBR is 55AAH, control is transferred to
offset zero of the PBR and the boot process continues. If the word at offset 1FEH of the PBR is not
55AAH, the code in the MBR displays an error message and halts.
3.2.4.1 Master Boot Record

The Master Boot Record contains the following fields:

000H 446 Boot code
1BEH 16 Partition Entry (See below)
1CEH 16 Partition Entry (See below)
1DEH 16 Partition Entry (See below)
1EEH 16 Partition Entry (See below)
1FEH 2 Signature Word (0x55AA)
3.2.4.2 Partition Entry

Each of the four Partition Entries in the Master Boot Record have the following format:

00H 1 x86 default boot partition
00H = Not default boot partition
80H = Default boot partition
01H 1 StartHead - Zero-based (0) head number where partition starts on media.
02H 1 StartSector - Bits 0 .. 5 are one-based (1) sector number where partition
starts on media. Bits 6 and 7 are high bits of zero-based (0) cylinder
number where partition starts on media.
03H 1 StartCylinder - Least significant eight bits of zero-based (0) cylinder
number where partition starts on media. Upper two bits of starting cylinder
04H 1 Partition Type
00H: Unknown or deleted if NumSectors is zero
05H: Extended MS-DOS Partition
06H: MS-DOS 16-bit BPB/FAT >= 32 MB
05H 1 EndHead - Zero-based (0) head number where partition ends on media.
06H 1 EndSector - Bits 0 .. 5 are one-based (1) sector number where partition
ends on media. Bits 6 and 7 are high bits of zero-based (0) cylinder
number where partition ends on media.
07H 1 EndCylinder - Least significant eight bits of zero-based (0) cylinder
number where partition ends on media. Upper two bits of ending cylinder
08H 4 StartSector (relative to beginning of media or Extended MS-DOS Partition)
0CH 4 NumSectors
4 . F I L E F O R M AT S
To achieve backward compatibility and speed acceptance of PC Card technology, the formats used
by file systems for traditional storage devices are often used for PC Cards. This section describes the
data structures used by specific formats and how file operations using those structures are
performed. Each subsection provides the following information about a file format:
Overview An overview of the format and where it is used.
Versions or Revisions Variations of the file format in common use.
File Operations How common file operations are performed using the
defined data structures.
Initial Program Load How a host system boots using the file format.
Data Structures The data structures used by the file format.
4.1 MS-DOS BPB/FAT Format
4.1.1 Overview
In the MS-DOS environment, the native file system stores information in what is known as the
BPB/FAT format. Static RAM (SRAM) cards and PC Card ATA drives commonly use this format on
x86 architecture systems. Flash memory cards may also use this format if they are read-only or are
accessed using a Flash Translation Layer (FTL).
BPB/FAT media is accessed in blocks known as sectors. The number of bytes in a sector is described
in the BIOS Parameter Block (BPB) BytesPerSector field. The total number of sectors on the media is
described by the BPB 0 field if there are less than 65,536 sectors. If there are more than 65,535
sectors, the TotalSectors field is zero (0) and the number of sectors on the media is described by the
HugeSectors field.
BPB/FAT media may have hidden sectors. Hidden sectors are usually associated with partitioned
media. The BPB HiddenSectors field describes the number of hidden sectors on the media.
BPB/FAT media have one or more reserved sectors. The BPB ReservedSectors field describes the
number of reserved sectors on the media. The first reserved sector is known as the Boot Sector. This
sector contains the BIOS Parameter Block (BPB) describing the size and format of the media.
After any hidden and reserved sectors, BPB/FAT media have one or more File Allocation Tables
(FATs). If there is more than one FAT, the additional copies are maintained to allow data recovery
in case the first FAT is damaged. Most BPB/FAT media is formatted with two (2) FATs. The
number of FATs is described by the BPB NumFATs field.
The FAT tracks the allocation of the media's data space. Space on BPB/FAT media is allocated in
units of one or more contiguous sectors called clusters. If a cluster has more than one sector, the
number of sectors in the cluster must be a power of two (for example, two, four, eight, etceteras).
The BPB SectorsPerCluster field describes the number of sectors per cluster.
FAT entries may be 12 or 16-bits depending on the number of clusters on the media. Media with
more than 4085 clusters use 16-bit entries. Media with 4085 or less clusters use 12-bit entries. Each
entry in the FAT represents the allocation status of a cluster. The first two entries are reserved for
FAT ID information. The first data area tracked by the FAT is cluster number two (2).
FILE FORMATS
A FAT entry has the following meanings. The digit in parentheses represents the upper four bits
associated with 16-bit FAT entries.
Value Meaning
(0)000H Available or unallocated cluster
(0)001H Reserved, do not use this value
(0)002H - (F)FF6H Next cluster in file or directory
(F)FF7H Bad cluster, do not store data in this cluster
(F)FF8H - (F)FFFH Last cluster of file or directory
The number of sectors used to store each FAT is described in the BPB NumFATSectors field. The
next area on the media after the FAT(s) is the Root Directory. The Root Directory is an array of
Directory Entries. The number of directory entries in the Root Directory is described by the BPB
RootDirEntries field. The Directory Entry StartCluster field describes the first cluster used to store
data for the file or directory identified by the entry.
The space on the media immediately following the Root Directory is used for file and subdirectory
data storage. The Directory Entry Attributes field identify an entry as a subdirectory of a file.
Subdirectories are special file entries containing additional directory entries for files and further
subdirectories in the data area of the media.
4.1.2.1 12-Bit FATs

BPB/FAT media formatted with less than 4086 clusters uses 12-bit File Allocation Table (FAT)
entries. Each FAT entry requires 1.5 bytes.
4.1.2.2 16-Bit FATs

BPB/FAT media formatted with more than 4085 clusters uses 16-bit File Allocation Table (FAT)
entries. Each FAT entry requires two (2) bytes.
4.1.2.3 Huge Partitions

BPB/FAT media with more than 65,535 sectors indicates the number of sectors in the BPB
HugeSectors field and sets the TotalSectors field to zero (0). All huge partitions use 16-bit FAT
entries requiring two (2) bytes for each entry.

All BPB/FAT partitions begin with a Partition Boot Record (PBR). All PBRs start with a byte of E9 H
or EBH. If the PBR begins with a byte of EBH, the byte at offset two (2) must also be 90H. If the
previous bytes are present, the byte at offset 26H of the PBR must be 29H indicating an Extended
BPB is present.
If the PBR does not contain the above bytes, the partition is not BPB/FAT format.
Further consistency checks may be performed on an implementation specific basis. The BIOS
Parameter Block (BPB) fields may be checked for valid values. For example, the BytesPerSector
field must be a power of two and at least 128 bytes. The SectorsPerCluster field must be one or any
other power of two. The ReservedSectors field must be at least one (1). The NumFATs field must be
one (1) or two (2).

The first step in formatting a BPB/FAT partition is to write a Partition Boot Record (PBR) with a
BIOS Parameter Block (BPB) to the first reserved sector of the partition. The next step is to initialize
the number of File Allocation Tables (FATs) indicated by the BPB NumFATs field. The first byte of
each FAT is the partition's FAT ID byte followed by two bytes of FFH. If the FAT uses 16-bit entries,
the next byte is also FFH. All of the remaining bytes of the FAT are zero (00H).
The sectors for the Root Directory are then initialized. All bytes of the Root Directory sectors are
written as zeroes (00H). Optionally, a scan of the media may be performed to determine if any of
the data clusters are defective. How or if this scan is performed is implementation specific. However,
if bad sectors are located, the clusters containing the bad sectors are marked as bad in all FATs.
4.1.5 File Operations
4.1.5.1 File Creation

A file is created by filling in the fields in a directory entry. The directory may be in the Root
Directory or a subdirectory. A directory entry may be created with the StartCluster field set to zero
(0) if the file or subdirectory does not contain any data. The first write to the file or subdirectory will
allocate a cluster if there is one available on the media.
4.1.5.2 File Deletion

A file or subdirectory is deleted by overwriting the first byte of the Name field with the value E5H.
In addition, any clusters allocated to the directory entry must be freed by writing a zero (0) to the
corresponding cluster entries in all the File Allocation Tables on the media.
A directory entry for a subdirectory may not be deleted until all entries in the subdirectory are
deleted as described above.
4.1.5.3 Read and Write Operations

The first step in performing a read or write is to determine where on the media the operation
should begin. Such operations typically specify an offset within the file or directory. The BIOS
Parameter Block (BPB) BytesPerSector and SectorsPerCluster fields are used to determine the
relative cluster where the operation is to begin.
The desired offset is divided first by the BytePerSector field. The result is further divided by the
SectorsPerCluster field. The result of the second divide is the relative cluster where the operation
begins. The remainder of the second divide is the relative sector within the cluster where the
operation begins. If the remainder of the first divide is non-zero, the operation begins in the middle
of a sector and must be buffered by host software.
For example, if the media is formatted for 512 bytes per sector and there are two sectors per cluster,
a read from offset 1024 of a file would begin at the start of the second cluster. A read from offset 1536
begins at the start of the second sector of the second cluster. A read from offset 1792 begins in the
middle of the second sector of the second cluster and requires host system buffering.
Once the appropriate relative cluster is determined, the File Allocation Table (FAT) is used to
convert the relative cluster to an absolute cluster on the media. The Directory Entry's StartCluster
FILE FORMATS
field determines the first cluster. The value in that entry of the FAT is the next cluster in the chain.
When a FAT entry is FF8H to FFFH, the end of the cluster chain has been reached. Attempts to read
past the end of the cluster chain are failed.
If an operation continues beyond the end of a cluster, the location of the next cluster is determined
from the contents of the current FAT entry. Write operations that continue past the end of the cluster
chain need to extend the chain.
A cluster chain is extended by overwriting the current FAT entry with the number of an
unallocated cluster. The unallocated cluster entry in the FAT is then marked as the end of the chain.
Attempts to extend cluster chains on full media are failed.
When a directory entry is extended, the FileSize field of the entry is increased. The FileSize field
represents the actual size of the file or directory, in bytes, and may be less than the space allocated.
This is due to the fact the file or directory may not fill the last cluster allocated.

The Partition Boot Record (PBR), in addition to containing the BIOS Parameter Block (BPB), also
contains code to continue Initial Program Load (IPL). Host system software loads the PBR into system
memory at 0000H:7C00H. If the word at offset 1FEH of the PBR is 55AAH, the host systems transfers
control to the PBR code at 0000H:7C00H. No arguments are provided to the code by the host system.
No stack is established and no indication of which device the PBR was read from is provided.
If the PBR contains an MS-DOS bootstrap loader, the information in the BPB within the PBR is used
to locate systems files in the Root Directory of the media. If these files are located, they are loaded
into host system memory and control is transferred to them to complete IPL.
4.1.7.1 Partition Boot Record (PBR)

The Partition Boot Record contains the following fields:

000H 3 JMP instruction to PBR boot code
003H 8 OEMName and version
00BH 25 BIOS Parameter Block (BPB)
024H 1 DriveNumber (00H = Floppy, 80H = Fixed)
025H 1 Reserved, do not use
026H 1 ExtBootSignature - 29H
027H 4 VolumeID or Serial Number
02BH 11 VolumeLabel - ASCII characters, padded with blanks if less than eleven
(11) characters
036H 8 FileSysType - ASCII characters identifying file system type. Padded
with blanks if less than eight (8) characters. One of the following values:
Value Meaning
FAT12 12-bit File Allocation Table (FAT)
FAT16 16-bit FAT
03EH 448 Boot code
1FEH 2 Signature word - 55AAH
4.1.7.2 BIOS Parameter Block (BPB)

The BIOS Parameter Block (BPB) contains the following fields:

000H 2 BytesPerSector - Number of bytes per sector
002H 1 SectorsPerCluster - Number of sectors in a cluster
003H 2 ReservedSectors - Number of reserved sectors at the beginning of the media.
Must be at least one (1) to accommodate the Partition Boot Record (PBR)
005H 1 NumFATs - Number of File Allocation Tables (FATs) on the media.
006H 2 RootDirEntries - Number of Root Directory entries
008H 2 TotalSectors - Number of sectors on media. If media has more than 65,535
sectors, this field is zero and the actual number of sectors is in the HugeSectors
field.
00AH 1 MediaIDByte - Used to quickly identify how the media is formatted
Value Meaning
F0H Various types of media
F8H Hard disk, any size
F9H 720K 3.5" or 1.2M 5.25"
FAH 320K 5.25"
FBH 640K 3.5"
FCH 180K 5.25"
FDH 360K 5.25"
FEH 160K 5.25"
FFH 320K 5.25"
00BH 2 NumFATSectors - Number of sectors in each FAT
00DH 2 SectorsPerTrack - Number of sectors on a track
00FH 2 NumHeads - Number of heads
011H 4 HiddenSectors - Number of hidden sectors in front of reserved sectors
015H 4 HugeSectors - Number of sectors on media if TotalSectors is zero (0).
FILE FORMATS
4.1.7.3 Directory Entry

Each directory entry contains the following fields:

000H 8 Name ¾ File or directory name. If less than eight (8) characters, padded with
blanks.
008H 3 Extension ¾ File or directory extension. If less than three (3) characters, padded
with blanks
00BH 1 Attributes ¾ Bit-mapped field using following values:
Value Meaning
xxxxxxx1B Read-only
xxxxxx1xB Hidden
xxxxx1xxB System
xxxx1xxxB Volume label (root directory only)
xxx1xxxxB Subdirectory
xx1xxxxxB Archive (new or modified entry)
00CH 10 Reserved, do not use
016H 2 Time ¾ Bit-mapped field describing time file or subdirectory created or modified:
Bits Meaning
0 .. 4 Two-second interval (0 .. 29)
5 .. 10 Minute (0 .. 59)
11 .. 15 Hour (0 .. 23)
4.2 Linear File Store
4.2.1 Overview
Define a partition type for storing files formatted in a PCMCIA/JEIDA-prescribed manner within
contiguous sections of PC Card memory. This Linear File Store (LFS) uses a well-defined header
record to allow directory functions and file access to be performed across a wide variety of operating
environments and host platforms.
Partitions on PC Cards are defined using the Data Recording Format Tuples in Layer 2 of
Metaformat Specification. A memory-like format tuple is used to describe the PC Card StandardÕs
LFS partition. (See the Metaformat Specification for more information about format tuples.)
Byte 7 6 5 4 3 2 1 0
0 TPL_CODE Format tuple code (CISTPL_FORMAT, 41H) or (CISTPL_FORMAT_A, 47H).

2 TPLFMT_TYPE Format type code (TPLFMTTYPE_ MEM, 01H)
3 TPLFMT_EDC Error Detection Method (TPLFMTEDC_NONE)
RFU 000B 0000B
4 .. 7 TPLFMT_OFFSET Byte address of the first data byte in this partition.
8 .. 11 TPLFMT_NBYTES Number of data bytes in this partition.
12 TPLFMT_FLAGS Various Flags (00H - Flags not used)
(Reserved) 0 0
The above tuple definition describes a partition which is formatted as a memory-like region with no
error detection and no requirement for direct mapping into a specific area of host system address
space. For the example an election has been made to shorten the tuple by omitting optional fields
which are not used.
The data organization of the PC Card StandardÕs LFS partition is defined by an Organization Tuple.
(See the Metaformat Specification for more information about data organization tuples.)
Byte 7 6 5 4 3 2 1 0
0 TPL_CODE Organization tuple code (CISTPL_ORG, 46H).

2 TPLORG_TYPE Data organization code (TPLORGTYPE_FS, 00H)
3 .. 12 TPLORG_DESC Linear File Store specified by the PC Card Standard ("LFS100")
(Note: Text description of this organization, terminated by 00H)
Within the partition, each file is preceded by a PC Card Standard-defined entry record. This
structure provides enough information for a simple bootstrap loader to select an appropriate file. If a
specific environment requires information beyond that defined by the PC Card Standard, the
organization responsible for that environment defines any additional fields required immediately
after the PC Card Standard-defined fields creating an extended header record.
For XIP files, a header record is also defined to provide information about the length of the root
segment of the file, whether the file uses paging and the entry point for execution within the file.
Because the header record is part of the file, the data in the record is available during file execution.
FILE FORMATS
The PC Card Standard-defined entry record is located at the base of the window that maps the root
section into host system address space.
Note:
XIP definition to be developed by XIP Working Group.
Files are stored consecutively within the partition using a forward-linked list managed by a field
which points to the next header record. If the file is the last in a partition, the pointer to the next
header record is set to all ones (-1 or FFFFFFFFH). This value allows files stored in partitions using
flash memory devices to be extended if sufficient space remains within the partition.
Each entry in the PC Card StandardÕs LFS Partition has the following structure:
typedef struct {
DWORD NextEntry;
DWORD EntrySize;
DWORD EntryType;
DWORD OffsetToHeader;
DWORD Flags;
DWORD OffsetToString;
DWORD UniqueID;
BYTE Reserved[4];
BYTE EntryInfo[];
} ENTRY;
Member Description
NextEntry This field points to the next entry within the partition, relative to the start of this entry on the
PC Card. The actual location of the next entry is determined by adding the value in this field
to the offset of this field on the PC Card. If all of the bits in this field match Bit D0 of the
Flags field, this is the last entry in the partition.
EntrySize This field contains the actual size of the entry, i.e. the number of bytes in this instance of the
ENTRY structure. EntrySize is less than the NextEntry when padding is added to align the
next entry on a boundary.
EntryType This field contains a PCMCIA assigned value that defines the interpretation of the data in
the EntryInfo byte array. EntryType values are assigned by PCMCIA. The definition of any
header structure within the EntryInfo area for a particular EntryType value must be
provided at the time the EntryType is assigned. If all of the bits in this field match Bit D0 of
the Flags field, this entry is not defined. For this reason, the EntryType values zero and
minus one are reserved.
OffsetToHeader This field contains the offset from the beginning of the ENTRY structure where additional
EntryType specific information is stored. The actual location of the specific information is
determined by adding the value in this field to the offset of the NextEntry field on the PC
Card. If this field is zero, there is no specific information and this field is ignored.
Flags This field is bit-mapped. The bytes of this field are stored in little-endian order. Bit D1
indicates the current state of the entry. If Bit D1 matches D0, this entry is active. If Bit D1
does not match Bit D0, this entry has been deleted. All of the remaining bits are reserved
and must be set to the value of Bit D0. Bit D0 is used in this manner to accommodate the
unique erase and write characteristics of some types of storage media such as flash
memory devices. Bit D0 is typically maintained in the natural erase state of the media.
OffsetToString The field contains the offset from the beginning of the ENTRY structure where an ASCIIZ
string describing the entry is stored. The actual location of the string is determined by
adding the value in this field to the offset of the NextEntry field on the PC Card. If this field is
zero, there is no ASCIIZ string and this field is ignored.
UniqueID This field contains a value that is unique for each file stored in the partition. It is intended to
be used to uniquely identify a file even if it is relocated within the partition. Formatting
software should attempt to prevent the reuse of UniqueID values previously assigned to
deleted entries. How this is accomplished is implementation specific.
Reserved These bytes are reserved for future use. They shall be set to match the value of bit D0 of
the Flags field.
EntryInfo The data for this entry.
5 . T R A N S L AT I O N L AY E R S
When sector remapping is performed by a translation layer, two storage formats are used. From the
host system perspective, the same block storage format used for other media is being recorded. With
the translation layer in place, the host system believes it is using traditionally formatted media.
However, the translation layer requires sector mapping information to be stored on the media and
what the host feels are contiguous sectors are actually placed on the media out of sequence. To allow
another system to recover the data stored on the media requires an understanding of how the
translation layer remaps sectors and the native storage format intended by the original file system.
virtual blocks.
TRANSLATION LAYERS
5.1 Virtual Block Device Flash Translation Layer - FTL

Release FTL Version
PC Card Standard Release 7.0 (February 1999) 1.2
PC Card Standard April 1998 (Release 6.1) 1.1
PC Card Standard May 1996 (Release 5.2) 1.0
5.1.2 Overview
Traditional block storage devices read and write data in small blocks sized in power-of-two
multiples beginning at 256 (i.e. 256, 512, 1024, 2048, etc. byte blocks). File systems and the data
structures they use are optimized for read/write units of this size. While flash media storage devices
may be able to perform read and write operations on similar size blocks, they usually require a
data area be erased before it may be written.
Adding an erase operation immediately before a write would appear to solve the problem and for
some flash devices, this is all that is required. Unfortunately, for many flash devices, erase
operations must often be applied to a contiguous area of the media known as an Erase Zone that is
larger (in some cases, much larger) than traditional storage devices use for read and write access.
This can make flash devices difficult to use with traditional file systems unprepared to relocate
adjacent data areas to prepare for erase operations.
Two approaches have been taken to deal with the unique characteristics of flash storage devices: the
development of new file systems customized for flash device characteristics and the introduction of a
translation layer between the file system and the storage media to mask any differences between
flash storage devices and traditional block storage devices. This section describes the later method,
known as a Flash Translation Layer (FTL).
5.1.2.1 Emulating Traditional Block Devices - Virtual Block Device

An FTL masks the characteristics of flash devices from higher level software layers such as file
systems by emulating a traditional block device. From the perspective of such higher level layers, a
block storage device is a contiguous array of blocks numbered from zero (0) to one less than the
number of available blocks. These higher level software layers expect to be able to write these
blocks at will, without any regard for the need to first erase the media and certainly without any
need to erase an area that exceeds the size of the block being written.
The FTL delivers this capability to the higher level software layers by remapping requests to write
blocks to unallocated or free areas of the media and invalidating the area on the media previously
containing the block's data. The FTL also records where the remapped block is placed on the media
to allow subsequent read accesses to return the data written. In effect, the FTL presents a virtual
block storage device to the higher level software layers. The size of these virtual blocks is
determined when the storage media is formatted.
5.1.2.2 Flash Characteristics

A unique characteristic of flash media is its data content after erasure. If erased, flash media data
bytes are either set to all ones (FF H) or all zeroes (00H). In addition, once a flash data bit has been
set to a value other than its erase state, an entire Erase Zone must be erased to return the bit to its
erased state. However, single bits within a byte may be transitioned from the erased state to the
non-erased state without an erase operation. FTLs use this ability to modify updatable fields in
control structures. See the description of the ReversePolarityFlash bit of the Flags field in the Erase
Unit Header.
TRANSLATION LAYERS
5.1.2.3 Erase Zones and Erase Units

Depending on its technology, each flash IC on a PC Card may be divided into one or more Erase
Zones of equal size. Each Erase Zone is the minimum contiguous area that can be erased in a single
operation. If eight-bit devices are interleaved to provide sixteen-bit storage, the corresponding
physical zones on two adjacent devices are combined together as a single Erase Zone. One device
provides even addresses and the other device provides odd addresses.
An Erase Unit is a multiple of one or more contiguous Erase Zones. The size of an Erase Unit is set
when the media is formatted. See Figure 5-1: Erase Zones.
Flash Memory Card Interleaved Flash Devices
Even Odd
Addresses Addresses
Flash IC Flash IC
Erase Zone
Flash IC Flash IC
Erase Zone
Flash IC Flash IC
When a flash IC does not require the entire device to be erased as a single unit, a single flash IC conta
multiple Erase Zones. When eight-bit flash devices are used, an Erase Zone spans two flash ICs.
Figure 5-1: Erase Zones
5.1.2.4 Erase Unit Header and Block Allocation Information

For allocation purposes, an Erase Unit is evenly divided into one or more Read/Write Blocks of
equal size. For example, a 128 KByte Erase Unit might be divided into 256 Read/Write Blocks, each
512 Bytes in size. Each of these Read/Write Blocks is the same size as the Virtual Blocks presented
to the higher level software layers by the FTL. See Figure 5-2: Read/Write Blocks.
Flash Memory Card Erase Unit

Subdivided into Erase Units Subdivided into Read/Write Blocks
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Read/Write Block
Read/Write Block
Erase Unit
Erase Unit
An Erase Unit is evenly divided into read/write blocks for allocation purposes. Each of these
read/write blocks is the same size as the virtual blocks presented to the higher level software
layers by the FTL.
Figure 5-2: Read/Write Blocks
Within each Erase Unit is an Erase Unit Header (EUH). The EUH includes specific information
about the Erase Unit and global information about the format of the FTL partition. Each Erase Unit
also contains allocation information for all of the Read/Write Blocks within the unit.
Some flash devices have a small number of bytes of storage adjacent to each Read/Write Block
which are not addressed through the linear address space of the media. Erase Units with these
"hidden" areas may place block allocation information for a Read/Write Block in the hidden area
adjacent to the block. If the Erase Unit does not have hidden areas or an FTL partition is not
formatted to use the hidden areas, block allocation information is stored in an array known as the
Block Allocation Map or BAM in the Erase Unit's linear address space. The Flags field of the EUH
indicates whether block allocation information is stored in hidden areas or a BAM.
TRANSLATION LAYERS
For data integrity purposes, two copies of the block allocation information may be stored in the
Erase Unit. The Flags field of the EUH indicates the number of copies of the block allocation
information that are present on the media. When BAMs are used to store block allocation
information, the second copy is stored in a separate BAM immediately following the first BAM in
the Erase Unit.
Optional Checksums, CRCs or ECCs may also be present for each Read/Write Block. If present,
these codes are stored immediately following the block allocation information, in either the BAM or
the media's hidden areas as indicated by the Flags field of the EUH. The length of these codes
varies depending on the type of code being used. See Figure 5-3: Erase Unit Layout.
Flash Memory Card Erase Unit with Erase Unit without

Subdivided into Erase Units Hidden Areas Hidden Areas
Erase Unit Header Erase Unit Header
Erase Unit Block Allocation Map

(BAM)
Erase Unit Read/Write Blocks

used for
Read/Write Blocks
Virtual Map Pages,
Erase Unit used for
Replacement Pages
Virtual Map Pages,
and Virtual Blocks
Replacement Pages
Erase Unit and Virtual Blocks
Erase Unit
Block Allocation
In Hidden Areas
Information
Erase Unit
Erase Unit One or more Erase Zones
Erase Units with hidden areas may place Block Allocation Information in those areas rather than in the
linear address space of the media. Optional Checksums, CRCs or ECCs are not shown. If present, these
codes are stored immediately following the Block Allocation Information in either the Block Allocation Map
(BAM) or the media's hidden areas.
Figure 5-3: Erase Unit Layout
5.1.2.5 Block Allocation Information and the Block Allocation Map (BAM)
Each Erase Unit on the media contains allocation information for the Read/Write Blocks within the
unit. For each Read/Write Block, a four-byte value tracks the block's current state. At any point in
time, a Read/Write Block in an Erase Unit is free, deleted, bad, reserved for bad area management,
or allocated. For each Read/Write Block, a four (4) byte value tracks the block's current state. The
following table identifies the corresponding block allocation entry values for the state of a
Read/Write Block:
BAI Meaning Description

FFFFFFFFH Free Read/Write Block is available, erased and ready to be written.
FFFFFFFEH Deleted Data in block is not valid. Read/Write Block must be erased before it
can be re-used.
OR
The value FFFFFFFEH indicates write operations were started on the
00000000H
Read/Write Block, but were interrupted before they were completed.
The value 00000000H indicates the data in the Read/Write Block was
superseded by normal update operations.
00000070H Bad Block is unusable.
xxxxxx10H Bad Area Block allocated for storing information about bad areas in the flash
Management device.
Any Other Value Allocated Block is allocated. The actual BAI value describes the type of data
stored in the Read/Write Block. Other values could be valid and should
not cause operation errors. If a value is unrecognized, the block should
be marked by software as "deleted" at initialization.
When allocated, Read/Write Blocks are used to store four types of data: FTL control structures,
Virtual Block data for higher level software layers, Virtual Block Map Pages and Replacement
Pages. When a Read/Write Block is allocated to an FTL control structure, the block's allocation
information entry is set to the following:
00000030H Control Read/Write Block contains one or more FTL control structures: an
Erase Unit Header, a Block Allocation Map (BAM), or an array of
Checksums, CRCs or ECCs.
The block allocation entries for Virtual Block data, Virtual Block Map Pages and Replacement Pages
have two parts. The least significant eight (8) bits indicate whether the Read/Write Block contains
Virtual Block data, a Virtual Block Map Page or a Replacement Page as indicated by the following
table:
xxxxxx40H Data or Map Page Read/Write Block contains Virtual Block data or a Virtual Map Page.
xxxxxx60H Replacement Read/Write Block contains a Replacement Page for a Virtual Map Page.
Page
The most significant twenty-four (24) bits of the block allocation entry for a Read/Write Block
containing Virtual Block data, a Virtual Block Map Page or a Replacement Page are the most
significant bits of the virtual address of the data. The least significant eight (8) bits of the virtual
address for these entries are assumed to be zero (0). To determine if the block is Data, Map, or
Replacement page, compare the least significant 8 bits to 40H and/or 60H.
The FTL assigns a virtual address to each Virtual Block in the contiguous array of blocks presented
to higher level software layers. The virtual address is computed by multiplying a Virtual Block's
sequence number (zero to n - 1) by the size of a Virtual Block. The first Virtual Block is always at
virtual address zero (0) as indicated by a block allocation entry of 00000040H. If the Virtual Block
size is 512 bytes, the second block's virtual address is 00000200 H and its block allocation entry is
00000240H. The third block's virtual address is 00000400H and its block allocation entry is
00000440H. See Figure 5-4: Block Allocation Map.
The Virtual Block Map (VBM) is built from the virtual addresses of Read/Write Blocks used to store
Virtual Block data. Read/Write Blocks containing Virtual Block data use positive virtual addresses.
If the VBM is maintained on the media, the Read/Write Blocks containing VBM Pages or
Replacements Pages use negative virtual addresses. The use of negative addresses is discussed
further in the sections that follow.
TRANSLATION LAYERS
Allocation information is maintained in one of two ways. First, allocation information for all of the
Read/Write Blocks in the Erase Unit may be stored together in an array in the unit known as the
Block Allocation Map (BAM). Second, allocation information may be stored in hidden areas next to
or related to the Read/Write Block to which it refers. The Flags field in the Erase Unit Header
describes how allocation information is stored on the media.
NOTE: For reverse polarity flash the block allocation information stored on the
media is inverted (for example, BAI entry 00000070H is FFFFFF8FH, etc.
when a reverse polarity flash device is used). See the ReversePolarityFlash
bit of the Flags field in the Erase Unit Header.
Erase Unit Header Contents of Read/Write Block

Block Allocation Map BAM Index
2 00000440 Virtual Block 2
3 00000000 Superseded Data
4 FFFFFE40 Page -1 of Virtual Block Map
5 0002A440 Virtual Block 338 (152h)
6 FFFFFFFF Free
7 FFFFFA60 Page -3 of Virtual Block Map
Erase A portion of the Block Allocation Map

Unit Free Blocks,
Superseded Blocks, Notes on the Block Allocation Map: Each entry in the Block
Virtual Blocks, Allocation map describes the contents of a corresponding
Virtual Block Map Pages, Read/Write Block in the Erase Unit. This example uses a
and Replacement Pages block size of 512 bytes and the FTL partition does not store
checksums, CRCs or ECCs for Virtual Block data. All blocks
are numberd starting from 0.
The first two Read/Write Blocks of this Erase Unit store FTL
control structures: the Erase Unit header and the Block
Allocation Map. The third Read/Write Block (bytes 1024-1535
of the Erase Unit) contains data for the third Virtual Block used
by higher level software layers. The next Read/Write Block
(bytes 1536-2047) contains superceded data, while the block
following it contains data for Virtual Block Map Page #338.
Figure 5-4: Block Allocation Map
5.1.2.6 Virtual Block Map - Mapping Virtual Blocks to Logical Addresses

The FTL uses a data structure known as the Virtual Block Map (VBM) to map requests for virtual
blocks from higher level software layers to logical addresses on the media. The VBM is an array of
32-bit entries, each of which represents a logical address on the media where a Virtual Block's data
is stored. The virtual block number requested by higher level software layers is used as an index
into this array. See Figure 5-5: Virtual Block Map.
The VBM is subdivided into Pages. Each Page of the VBM is the same size as the Virtual Blocks
presented to the host system by the FTL.
The size of the VBM (in bytes) is determined by dividing the FormattedSize of the media by the
BlockSize and multiplying the result by the size of a VBM entry (32-bits or four bytes). The number
of Pages required for the VBM (NumVMPages) is the previous result divided by BlockSize and
rounded up to the nearest Page.
For example, if FormattedSize is 12 megabytes and BlockSize is 512 bytes, the media contains 24K
blocks. Each block has a four (4) byte entry in the VBM requiring 96 KBytes of the storage media to
store the VBM. Dividing the size of the VBM by the block size indicates NumVMPages is 192. Each
page of the VBM, in the example, is capable of recording the logical addresses used for 128 virtual
blocks or 64 KBytes of data storage.
Space is always reserved on the media to store a VBM large enough to track the allocation of all the
Virtual Blocks presented to higher level software layers by the FTL. However, when the media is
formatted, the FTL may indicate only a portion of the VBM is maintained on the media. The
FirstVMAddress field of the Erase Unit Header identifies the first virtual address on the media that
has an entry in the VBM maintained by the FTL.
If the FirstVMAddress is reset to zero (0), the FTL must maintain all of the VBM entries on the
media. If the FirstVMAddress exceeds the FormattedSize, none of the VBM entries are maintained
on the media by the FTL. If the FirstVMAddress is greater than zero (0), but less than the
FormattedSize, the FTL maintains VBM entries on the media for all virtual addresses greater than
or equal to the FirstVMAddress. The system should determine if it has adequate resources to mount
the media prior to mounting. All VBM entries stored on the media are in little-endian order.
When all or a portion of the VBM is not maintained on the media, the FTL must map requests for
Virtual Blocks in some other way. An FTL might create and maintain a VBM in host system RAM.
An FTL could also scan the media's block allocation information when each virtual block is
requested. The choice to maintain the VBM on the media is typically based on the availability of
system RAM and desired performance. Maintaining virtual to logical mapping information in
system RAM relieves the FTL of the overhead of updating the VBM on the media for frequently
updated Virtual Blocks.
If a VBM entry is all ones (FFFFFFFFH), the Virtual Block does not exist on the media. When asked
to read data from this Virtual Block, the FTL may return any combination of bytes, such as binary
0's, as long as this combination is consistently returned until the Virtual Block is written.
the Replacement Page to locate the block. Second, if there is no Replacement Page, the block does
not exist on the media. In the later case, when asked to read data from this Virtual Block, the FTL
NOTE: For reverse polarity flash, the VBM entries stored on the media are inverted
(for example, VBM entry FFFFFFFFH is 00000000H, etc. when a reverse
polarity flash device is used). See the ReversePolarityFlash bit of the Flags
field in the Erase Unit Header.
TRANSLATION LAYERS
Notes on Virtual Block Map Pages: Each entry in a Virtual

Erase Unit Header
Block Map (VBM) corresponds to a Virtual Block in the
emulated block device the FTL provides to higher level
Block Allocation Map software layers. This example shows the portion of the Page
of the VBM that maps Virtual Blocks 128 through 131.
The 128th entry of the VBM contains the value A0600h. This
indicates the data corresponding to the 128th Virtual Block is
stored at offset A0600h of the media when the Erase Units are
accessed in logical order. This example assumes each Erase
Unit is 64 Kbytes, so this logical address further breaks down
to offset 0600h of LogicalEUN 10.
Erase
Unit Free Blocks, The entry for Virtual Block 130 has been updated and is stored
Superseded Blocks, in a Replacement Page. To locate the data for this block, the
Virtual Blocks, FTL must refer to the corresponding entry (in this case, the
Virtual Block Map Pages, third entry) on the Replacement Page for this Virtual Block Map
and Replacement Pages Page. If the Replacement Page entry for this block is also 0,
then the data no longer exists.
Logical Address of Virtual Block
128 000A0600 Offset 0600h of Logical EUN 10
129 000C0800 Offset 0800h of Logical EUN 12
VBM Index
130 00000000 Use Replacement Page Entry
131 0000CC00 Offset CC00h of Logical EUN 0
A portion of a Virtual Block Map Page
Figure 5-5: Virtual Block Map
5.1.2.7 Virtual Page Map - Locating the Pages of the Virtual Block Map
When the Virtual Block Map (VBM) is maintained on the media, the FTL must track the storage of
the Pages of the VBM. In the same manner that VBM entries indicate the logical address of a Virtual
Block, the entries of the Virtual Page Map (VPM) indicate the logical address on the media where
the Pages of the VBM are stored. Unlike the VBM, the VPM is never stored on the media. Where
the FTL stores the VPM is implementation dependent. See Figure 5-6: Page Mapping.
The block allocation information entries describing Virtual Block Map Pages use negative values to
distinguish them from the Read/Write Blocks used to store Virtual Block data which use positive
values. In the example used in the previous section, the VBM requires 192 Pages. If the entire VBM
is maintained on the media (see the previous section), each page of the VBM requires a Read/Write
Block to store the VBM entries found on the page.
Virtual Block Map Pages are numbered using negative values, therefore their virtual addresses are
negative. As with Virtual Blocks, the virtual address stored as the block allocation information for
these pages is computed by multiplying the page number by the size of a Virtual Block (which is
the same size as the Read/Write Block used to store the page's data). Returning to the previous
example, the first page of the VBM (used to store the logical addresses of the first 128 Virtual Blocks)
is number -192. The second page of the VBM is number -191 and the last page of the VBM is -1.
With a block size of 512 bytes, the first VBM Page in the example is virtual address FFFE8000H. The
virtual address of the second VBM Page is FFFE8200H, and the last VBM Page would be virtual
address FFFFFE00H. To locate an address within a VBM Page, take the sector requested modulo
128. Multiply this result but the Virtual Block entry width and this yields the correct offset within
the VBM Page.
Virtual Page Map VBM Pages Data Sectors

(Virtual Blocks)
0
VBM 0 1
VBM 1 - Page Map Logical Address ... ...
127
0
VBM 1
1
... ...
127
.
. VBM 2 0
.
1
.
... ... .
127 .
.
.
.
VBM n-1
0
VBM n-1 - Page Map Logical Address 1

... ...
127
Logical to Physical Logical to Physical

address translation address translation
Figure 5-6: Page Mapping
5.1.2.8 Replacement Pages

Each page of the Virtual Block Map (VBM) may have a Replacement Page. Replacement pages may
be used to improve performance of a system. Values in a Replacement Page override entries in the
original VBM page as follows:
If an entry in an original VBM page is zero (0), the logical address of the Virtual Block is retrieved
from the corresponding entry on the Replacement Page. If there is no Replacement Page, or the
corresponding entry on the Replacement Page is zero (0), the Virtual Block does not exist on the
media.
Replacement Pages are used to improve performance by minimizing the need to supersede Pages
in the VBM when logical addresses on a Page are updated. To ensure compatibility with other host
systems, when reading, the system must be able to handle usage of one Replacement Page and
when writing is allowed to use up to one (1) at any one time.
Replacement Pages are allocated from Free Read/Write Blocks in any Erase Unit. The FTL locates
allocated Replacement Pages by scanning the block allocation information on the media. This scan
TRANSLATION LAYERS
may be performed when the media is inserted in the host system or when a VBM entry of zero (0) is
encountered. Replacement Pages may NOT be replaced.
The block allocation information entry for a Replacement Page uses the same virtual address as the
original VBM Page. The FTL distinguishes between the two using the least significant eight (8) bits
of the block allocation information. VBM Pages have a value of 40H in the these bits while
Replacement Pages have a value of 60H.
5.1.2.9 Mapping Logical Addresses to Physical Addresses

The addresses stored in the Virtual Block Map and Virtual Page Map arrays are logical addresses. A
logical address represents a location in the media described when the Erase Units are ordered in
LogicalEUN sequence. The FTL determines the relationship between LogicalEUN and PhysicalEUN
by scanning the media. As each Physical Erase Unit is encountered, its LogicalEUN is noted. Later,
the FTL uses this information to map the logical address in the VBM or VPM to a physical address
on the media where the data for the Read/Write Block is stored.
Since Erase Units are always sized as a power of two (2), the logical address may be considered to
contain a LogicalEUN in the most significant bits and an offset into the Erase Unit in the least
significant bits. Which bits represent the offset address and which bits represent the LogicalEUN
depend on the size of an Erase Unit.
As an example, if Erase Units were 64 KBytes, the low word of the logical address would be the
offset within the Erase Unit and the upper word of the logical address would be the LogicalEUN. If
the FTL maintains an array of PhysicalEUNs in LogicalEUN order, translating the LogicalEUN to a
PhysicalEUN is a simple matter of indexing into the array using the LogicalEUN from the upper
word of the logical address. Continuing with the example, the offset of the Read/Write Block storing
the data being mapped is the double word created by placing the PhysicalEUN in the upper word
and the offset into the Erase Unit into the lower word.

This section describes the data structures used on media formatted for the Flash Translation Layer
(FTL). Unless otherwise noted, all values stored in FTL data structure fields are in little-endian
format.
The FTL stores persistent allocation information on the media for each Virtual Block. This allocation
information is stored in the same Erase Unit as the Virtual Block. A Virtual Block Map (VBM) is
maintained by the FTL based on this allocation information that reorganizes the information into an
array of four byte entries that describe the logical location of a Virtual Block on the media.
The VBM may reside on the media or in a non-persistent space available to the host system such as
system memory. The portions of the VBM that are not stored on the media are built during FTL
initialization when new media is inserted based on the block allocation information stored in each
Erase Unit.
5.1.3.1 Erase Unit Header (EUH)

Each Erase Unit on the media contains an Erase Unit Header (EUH). The EUH is located at offset
zero (0) of the Erase Unit or at the location specified by the AltEUHOffset field of an EUH at offset
zero (0) of another Erase Unit. The Erase Unit Header contains information specific to the Erase Unit
and global information about the entire FTL partition.
Offset Field Size Detail/Description

0 LinkTargetTuple 5 This field contains a Link Target Tuple (see the Metaformat
Specification). The contents of this field are the same for all
Erase Units.
TPL_CODE CISTPL_LINKTARGET (13H)
TPL_LINK 3
TPLTG_TAG 'C', 'I', 'S'
5 DataOrganizationTuple 10 This field contains a CISTPL_ORG tuple (see the Metaformat
Specification). The contents of this tuple are the same for all
Erase Units. The value used for the TPL_LINK field is the number
of remaining bytes in the Erase Unit Header. The next tuple (after
the Erase Unit Header) may be an End-Of-List Tuple to terminate
the chain, or the tuple chain may continue with additional tuples.
TPL_CODE CISTPL_ORG (46H)
TPL_LINK At least fifty-seven (57), including the size of
the remaining fields in the Erase Unit Header.
TPLORG_TYPE TPLORGTYPE_FS (0)
TPLORG_DESC "FTL100", 0
15 NumTransferUnits 1 Number of Transfer Units in the partition. All FTL partitions have
at least one (1) Transfer Unit.
16 Reserved 4 This field shall be ignored when read and shall be set to the
deviceÕs erased state when written.
20 LogicalEUN 2 The Logical Erase Unit Number currently assigned to this unit.
The LogicalEUN of a formatted Transfer Unit is the media's
erased state (for most flash devices this is all ones or FFFFH).
22 BlockSize 1 The size of all Virtual and Read/Write Blocks. This field is
expressed as a log2 value. For example, for a block size of 512
bytes this field is set to nine (9). This field must be at least eight
(8) to represent the minimum block size of 256 bytes.
23 EraseUnitSize 1 The size of an Erase Unit. This field is expressed as a log2 value.
For example, for a unit size of 128 KBytes this field is seventeen
(17). Erase Units are always a multiple of the flash device's erase
zone size.
24 FirstPhysicalEUN 2 The Physical Erase Unit Number where the FTL partition begins.
If the partition starts at physical address zero (0), this value is zero
(0).
26 NumEraseUnits 2 Total number of Erase Units in the FTL partition. This field
includes Erase Units used to store data, block allocation
information, checksums (if present), transfer units, replacement
pages, spare blocks and the Virtual Block Map. The total number
of Erase Units also includes bad units.
28 FormattedSize 4 The formatted size of the partition. This is the total space available
to the host system for data storage. This field does not include
space marked as format blocks or used to for transfer units,
replacement pages and the Virtual Map. Formatting utilities should
also exclude a few additional blocks to use as spares. Without
spare blocks, a Unit Recovery Procedure is required anytime a
Virtual Block is updated after all the Virtual Blocks have been
written once. This field is expressed in bytes. This field must be a
multiple of BlockSize.
32 FirstVMAddress 4 The first virtual address for which Virtual Block Map (VBM)
entries are maintained by the FTL on the media. If this field is zero
(0), the entire VBM is maintained on the storage media. If this field
exceeds the FormattedSize field, none of the VBM is maintained
on the media. However, space for the entire VBM must be
available on the media at all times.
36 NumVMPages 2 Number of Pages in the Virtual Block Map (VBM). If the
FirstVMAddress field is greater than the FormattedSize field, the
FTL does not maintain the VBM on the media, even though space
is reserved on the media. If the FirstVMAddress field is less than
the FormattedSize field, some or all of the VBM stored on the
media is maintained by the FTL.
TRANSLATION LAYERS
38 Flags 1 Bit-mapped field describing how checksum and block allocation

information are stored on the media and the polarity of the media.
See 5.1.3.2 Flags below.
39 Code 1 Binary value describing the type of Checksum, CRC or ECC
information maintained for Virtual Block data. If this value is the
erase state of the media, no such information is present. If this
value is the non-erase state of the media, such information was
present at one time, but is no longer being maintained. Any other
value indicates the type of information being maintained.
If this value is set to one (1), a two (2) byte checksum is computed
and maintained for each Virtual Block. These two (2) byte
checksums are computed by adding each byte of the Virtual Block
to a 16-bit value initially set to zero (0) and ignoring overflow. The
checksum is stored in little-endian format. Where the checksum is
stored depends on the setting of the HiddenAreaFlag of the Flags
field.
Any other value than those described above is reserved for future
expansion.
40 SerialNumber 4 Partition serial number. May be used to distinguish between
partitions and/or PC Cards.
44 AltEUHOffset 4 Offset of an alternate Erase Unit Header. Used when it is not
possible to write an Erase Unit Header at offset zero (0) of the
Erase Unit. If used, the value in this field is the same for all Erase
Units in the partition. However, the FTL always attempts to place
the EUH at offset zero (0). For each Erase Unit the FTL is able to
place the EUH at offset zero (0), the alternate location is not used.
When all Erase Unit Headers are at offset zero (0) and there is no
Alternate Erase Unit Header in use, this field shall be in the erase
state of the media. This allows an Alternate EUH to be assigned at
run-time, if the beginning of an Erase Unit should go bad during
use.
Should an Alternate EUH be assigned at run-time, all EUHs must
be updated to reflect the AltEUHOffset.
The FTL first searches for the EUH at offset zero (0) of the Erase
Unit. Only if the EUH is not found there does the FTL search at the
location specified by this field. This presumes the FTL has
successfully read an EUH at offset zero (0) of another Erase Unit
to determine the location used for Alternate EUHs. If an EUH
cannot be found at either location, the FTL assumes the Erase Unit
is unformatted.
The AltEUHOffset should be an integer multiple of 4 Kbytes.
48 BAMOffset 4 The offset from the start of the Erase Unit Header to the Block
Allocation Map (BAM) contained in the Erase Unit. This field is
expressed in bytes. This field is only valid if the Flags -
HiddenAreaFlag is reset to zero (0). The Block Allocation Map is
not required to be aligned on a virtual block boundary. It may
immediately follow the tuple chain encapsulating the Erase Unit
Header.
If the Flags - DoubleBAI is set to one (1), two copies of the BAM
are present on the media. The second copy follows the first copy
and precedes any Checksum, CRC or ECC information.
If an Erase Unit is using Checksums, CRCs or ECCs as indicated
by the Code field, these codes shall follow the block allocation
information. If the allocation information is stored in the BAM, an
array of codes follow the array of allocation information in the
BAM.
52 Reserved 12 Reserved for future use. This field shall be left in the media's
erased state. For most flash devices this is all ones (FFH).
64 FTLRevisionTuple 114 This optional field contains an FTL Revision Tuple. The contents of
this field are the same for all Erase Units.
TPL_CODE vendor unique (80H)
TPL_LINK 10
FTL-VER 'FTL VER x.x' where x.x is the ASCII
equivalent version number of the FTL specification that the
software is compliant to. For example, FTL version 1.1 would
have entries 46H, 54H, 4CH, 20H, 56H, 45H, 52H, 31H, 2EH, 31H.
5.1.3.2 Flags
The bit-mapped Flags field of the Erase Unit Header describes how checksum and block allocation
information is stored on the media and identifies the media's erase state.
Bit Description
0 HiddenAreaFlag - This flag indicates whether checksum and allocation information are stored in the Block
Allocation Map (BAM) or the media has hidden, alternate storage areas for such information that do not appear in
the media's normal address space.
If this bit is set to one (1), checksum and/or allocation information are stored in hidden areas outside of the media's
normal address space.
If this bit is reset to zero (0), any checksum and/or allocation information are stored in the media's normal address
space. The Block Allocation Map (BAM), an array of all of the block allocation information, precedes an array of
the checksum information.
1 ReversePolarityFlash - This flag indicates whether the media's flash memory devices erase to all ones or to all
zeroes.
If this bit is set to one (1), the flash memory devices erase to all zeroes (0) and may be written to one. When this
bit is set, all block allocation information, Virtual Map entries and LogicalEUNs must be inverted before they are
written to the media and after they are read from the media.
If this bit is reset to zero (0), the flash memory devices erase to all ones (1) and may be written to zero. When this
bit is reset, all block allocation information, Virtual Map entries and LogicalEUNs are read and written without
inversion.
2 DoubleBAI - This flag indicates whether there are one or two copies of the block allocation information stored on
the media.
If this bit is set to one (1), two copies of the block allocation information are present on the media. If this
information is stored in BAMs, there are two complete BAMs on the media. In this case, the first BAM begins at
the location specified by the BAMOffset field and the second BAM begins immediately after the first. If the block
allocation information in stored in hidden areas, as indicated by the HiddenAreaFlag, the second entry for a
Read/Write Block follows the first. Both copies of the block allocation information precede any Checksum, CRC
or ECC codes.
If this bit is reset to zero (0), only one copy of the block allocation information is stored on the media.
3 .. 7 Reserved for future use. All of these bits must be reset to zero (0).

Flash Translation Layers (FTLs) may be identified in two ways. They may be explicitly identified in
a PC Card's Card Information Structure (CIS) or they may be recognized by searching the storage
media for FTL data structures.
If the CIS contains partition information, an FTL partition is identified by the Data Organization
Tuple (CISTPL_ORG, 46H). (See the Metaformat Specification for details on describing partitions in
the CIS.) An FTL Data Organization Tuple is formatted as follows:
Byte D7 D6 D5 D4 D3 D2 D1 D0
0 Tuple Code CISTPL_ORG, 46H
1 Tuple Link Link to next tuple (at least 07H)
2 TPLORG_TYPE TPLORGTYPE_FS, 00H
3 .. 9 TPLORG_DESC "FTL100\0" Null terminated string identifying FTL partition
TRANSLATION LAYERS
If the entire storage media is used by an FTL, the CIS is not required to contain partition
information. In this case, an FTL partition is recognized if an FTL Erase Unit Header (see 5.1.3 Data
Structures, above) is found in the first megabyte of the storage media and the information in the
Unit Header is valid. The procedure for recognizing and validating an FTL Erase Unit Header is
described in the following paragraphs.
The first step in recognizing an FTL partition is confirming the presence of the FTL Data
Organization Tuple described above at offset five (5) of the Erase Unit Header. Since Erase Unit
Headers always begin at offset zero (0) of an Erase Unit and an Erase Unit is always a multiple of a
flash device's erase zone size, the search is limited to the first fifteen bytes of each flash erase zone
in the first megabyte of the storage media. If the flash erase zone size is not known, the search for
an Erase Unit Header is made in four (4) KByte increments.
If the FTL Data Organization Tuple is not found within the first megabyte of the partition area, the
media is not an FTL data store. If the tuple is found, the rest of the Erase Unit Header must be
validated. All Erase Units should have identical EUHs with the exception of the Logical EUN and
reserved fields. One level of validation would be to check to see that all EUHs are the same. Further
validation could include verifying that the FormattedSize is a multiple of the BlockSize, that the
BlockSize is smaller than the EraseUnitSize, and that there is at least a 30H ID at the address that the
BAMOffset points to. The validation process may also be used to build a dynamic map of the logical
to physical translation performed by the FTL.
The FTL then reads every Erase Unit Header on the media, starting with the unit described by the
FirstPhysicalEUN field. If not found at offset zero, the FTL looks for the Erase Unit Header at the
location specified by the AltEUHOffset field of other Erase Units. If an Erase Unit Header is not
found at either location, the Erase Unit is considered an unformatted Transfer Unit. If two units are
found with the same value in the LogicalEUN field, either of the units may be assumed to be a
Transfer Unit. After all Erase Unit Headers have been read, the number of units with non-negative
and distinct LogicalEUN fields must equal the NumEraseUnits field less the NumTransferUnits
field.
The number of Virtual Blocks used to store the Virtual Block Map (VBM) on the media is indicated
by the NumVMPages field in the Erase Unit Header. During the block allocation scan, the FTL
locates VBM Pages and Replacement Pages. The number of VBM Pages located must match the
value in the NumVMPages field. If a VBM Page is missing and a Replacement Page exists, the
Replacement Page is used in place of the original VBM Page. If a VBM Page is missing and a
Replacement Page does not exist, implementation dependent recovery operations are required. If
duplicate VBM Pages are found, all but one is ignored.
The assignment of Replacement Pages is implementation specific. A Replacement Page is indicated
by allocation information having the same virtual address as an original VBM Page with the least
significant eight (8) bits set to 60H.

A Flash Translation Layer (FTL) partition is prepared for use as follows:
Determine the appropriate values for global fields in the Erase Unit Header:
DataOrganizationTuple
BlockSize
EraseUnitSize
FirstPhysicalEUN
NumEraseUnits
NumTransferUnits
FormattedSize
FirstVMAddress
NumVMPages
Flags
SerialNumber
AltEUHOffset
BAMOffset
For each Erase Unit on the media: Erase the unit and write out an Erase Unit Header with unit
specific data. Unit specific data includes the following field:
LogicalEUN
LogicalEUNs range from zero (0) to one less than the NumEraseUnits field less the
NumTransferUnits field. The order LogicalEUNs are assigned is not significant as long as each is
unique in the above range. The LogicalEUN of Transfer Units is left in the media's erased state (for
most flash devices this is all ones or FFFFH). See the ReversePolarityFlash bit of the Flags field.
For each Read/Write Block used to store Erase Unit Headers and the Block Allocation Map (if used)
set the allocation information to 30H to indicate the blocks contain formatting data.
Once the FTL has prepared the media, any block-oriented file system may store its data formats on
the media using the FTL to translate Virtual Block requests to the appropriate locations on the
media.
5.1.6 Logical Block Operations

This section describes how the FTL performs accesses to Virtual Blocks on the media.
5.1.6.1 Read
Higher level software layers request a Virtual Block from the FTL. The FTL uses the number of the
Virtual Block as an index into the Virtual Block Map (VBM). The entry in the VBM is the logical
address where the Virtual Block data is stored. The FTL converts the logical address to a physical
address. The conversion from logical to physical is based on the relationship of the LogicalEUN
containing the logical address to the physical Erase Unit used for the logical Erase Unit. The FTL
transfers the data block at this location into the buffer provided by the host file system.
If an entry in the VBM is all ones (FFFFFFFFH), the block does not exist on the media. The FTL
the Replacement Page to locate the block. Second, if there is no Replacement Page or the entry on
the Replacement Page is all zeroes or Fs (00000000 H or FFFFFFFFH), the block does not exist on the
media. In the later case, when asked to read data from this Virtual Block, the FTL may return any
combination of bytes, such as binary 0's, as long as this combination is consistently returned until
the Virtual Block is written.
5.1.6.2 Write
When writing Virtual Block data to the media, the FTL must first locate a free Read/Write Block. If
a free block is not available, one is created using the Unit Recovery Procedure described below.
TRANSLATION LAYERS
Once a free block is located, block allocation information for the area is marked to indicate a write
operation is beginning by resetting the least significant bit (FFFFFFFEH). Once the write has been
successfully completed, the block allocation information in the Erase Unit is updated to reflect the
Virtual Block's virtual address.
Next, the Virtual Block Map is updated to reflect the new area assigned to the Virtual Block. Finally,
if the new block replaces an existing block, the Read/Write Block used to store the superseded data
is marked as deleted by resetting its block allocation information to zero (00000000H).
If the write process is interrupted at any point, the FTL is able to recover with minimal effort. If the
interruption occurs before the data write completes, the block allocation information (FFFFFFFEH)
indicates the block shall be treated as deleted and normal activity will recover the space when
required.
If an interruption occurs after the block allocation information is updated, but before the VBM is
updated, both Read/Write Blocks have the same block allocation information. This can also occur if
the update of the VBM entry completes, but the superseded Read/Write Block's allocation
information is not marked as deleted. In either case, the FTL selects the block pointed to by the
VBM and treats the other block as superseded. The system is allowed to use up to one (1)
Replacement Page during writes.
5.1.6.3 Unit Recovery

Deleted and/or superseded Read/Write Blocks may only be re-used after they are erased. All of
the Read/Write Blocks in an Erase Unit must be erased at the same time. Rarely are all of the
Read/Write Blocks within an Erase Unit deleted and/or superseded. The Unit Recovery Procedure
performs the necessary processing to safely preserve data in allocated Read/Write Blocks and
recover deleted and/or superseded blocks.
The first step is to locate a properly prepared Transfer Unit. To be properly prepared, the area used
to store Virtual Block data, Virtual Block Map Pages, Replacement Pages and block allocation
information must be erased and the global fields of the Transfer Unit's Erase Unit Header must be
initialized. A formatted Transfer Unit contains the EUH and BAM. The BAM contains only Control
(30H) entries for the FTL structures for that Transfer Unit.
Before Read/Write Block data from the Erase Unit being recovered is copied to the Transfer Unit,
the LogicalEUN of the Transfer Unit is set to 7FFFH. After allocated Read/Write Blocks have been
successfully transferred, the Transfer Unit's LogicalEUN is set to the LogicalEUN of the Erase Unit
being recovered. If the Unit Recovery Procedure is interrupted, the Transfer Unit's LogicalEUN
remains 7FFFH, and the FTL can determine the Transfer Unit is not properly prepared.
After all allocated Read/Write Blocks have been successfully moved to the Transfer Unit and the
LogicalEUN updated, the original Erase Unit is erased and formatted as a Transfer Unit. If the Unit
Recovery procedure is interrupted before the original Erase Unit is erased, the FTL will find two
Erase Units with the same data. The FTL may use either Erase Unit as the specified Logical Erase
Unit and the other Erase Unit becomes a Transfer Unit.

virtual blocks.
6 . ST OR AGE DE V IC E S
PC Cards use a number of storage technologies with various read, write, erase and access
characteristics. The relative performance of a technology is often affected by the data storage format
used to record information on a PC Card. The characteristics of some technologies may dictate a
particular access method or may prohibit or severely limit the ability to use a particular file format.
6.1 Static RAM Cards

S-RAM device allow byte-oriented read and write access and do not require the media to be erased
before it may be written. This allows S-RAM PC Cards to store data without requiring a translation
layer. S-RAM memory devices on a PC Card may be mapped into host system memory and
directly accessed.
6.2 Flash Memory Cards

Flash memory devices may allow byte-oriented read and write access or may require block-oriented
access. Flash memory devices typically require the media to be erased before it may be written and
usually require an erase operations to be performed in blocks of contiguous bytes. The size of an
erase block varies among flash devices, ranging from small blocks of 256 or 512 bytes to blocks of 64
KBytes or more. Most linear flash memory PC Card may be mapped into host system memory and
directly accessed.
Unless access will be read-only, using traditional file systems with flash media is problematic due to
the unique characteristics of flash devices. Two methods are used to deal with flash media.
First, custom file systems designed especially for data storage on flash devices may be developed.
These file systems use a byte-oriented access to the media as opposed to the traditional block access.
In addition, file allocation is typically handled using linked lists which allow file updates to be
routed to erased areas of the media and the previously allocated areas marked as available for
recovery. When all erased space has been used, a recovery routine creates, clears and erases a
contiguous block of marked areas to allow them to be reused.
The second method for using flash media adds an additional translation layer between the
traditional file system and the flash media. The file system continues to read and write sector-sized
blocks, but instead of mapping directly to physical sectors, the translation layer tracks media use,
remaps sector write requests to erased areas and marks the previously used sector(s) as available for
recovery. Subsequent read requests are translated to access the appropriate remapped sectors.
6.3 PC Card ATA Drives

PC Card ATA drives use block-oriented read and write access and do not require the media to be
erased before it is written. PC Card ATA drives are typically used with traditional block-oriented
file systems and do not require a translation layer. The data storage area of a PC Card ATA drive is
usually accessed indirectly. Information is transferred between a PC Card ATA drive and the host
system by placing request parameters into task file registers located on the card.
Volume 8
PC Card ATA Specification
PCMCIA
JEIDA
+1-408-433-9558 (Fax) IMPORTANT:
+81-3-3433-1923 PCMCIA
and PC Card are trademarks of EXPRESS OR IMPLIED, WITH
JEIDA, registered in Japan. RESPECT TO THE STANDARD,
INFRINGEMENT,
YOU ÒAS IS.Ó

PC CARD ATA SPECIFICATION
CONTENTS
1. Introduction ___________________________________________ 1
1.1 Purpose................................................................................................................................1
1.2 Scope....................................................................................................................................1
1.4 Conventions .........................................................................................................................2
1.4.1 Signal Naming............................................................................................................................................................................2
1.4.2 Numeric Representation..........................................................................................................................................................2
1.4.3 Bit Action Representation.......................................................................................................................................................2
2. Overview ______________________________________________ 3
2.1 Feature Summary................................................................................................................3
2.2 Differences Between PC Card ATA and ATA ...................................................................3
3. Electrical Interface ______________________________________ 5

3.1 Pin Assignment Table..........................................................................................................5
3.2 Reset Conditions..................................................................................................................8
3.3 READY Signal and RREADY Bit.........................................................................................8
3.4 Interrupt Request: IREQ# ...................................................................................................9
4. ATA Specific Register Definitions _______________________ 11

4.1 PC Card ATA Drive Register and Protocol Definitions ...................................................11
4.2 ATA Registers....................................................................................................................12
4.2.1 Data Register.............................................................................................................................................................................1 2
4.2.2 Error Register ...........................................................................................................................................................................1 2
4.2.3 Feature Register........................................................................................................................................................................1 2
4.2.4 Sector Count Register .............................................................................................................................................................1 3
4.2.5 Sector Number Register.........................................................................................................................................................1 3
4.2.6 Cylinder Low Register ..........................................................................................................................................................1 3
4.2.7 Cylinder High Register..........................................................................................................................................................1 4
4.2.8 Drive/Head Register..............................................................................................................................................................1 4
4.2.9 Status and Alternate Status Registers..............................................................................................................................1 5
4.2.10 Command Register...............................................................................................................................................................1 5
4.2.11 Device Control Register......................................................................................................................................................1 5
4.2.12 Drive Address Register ......................................................................................................................................................1 6
4.2.13 Duplicate Data, Error and Feature Registers .............................................................................................................1 6
4.3 ATA Specific Register Mapping........................................................................................18

4.3.1 I/O Mapped Addressing......................................................................................................................................................1 8
4.3.2 Memory Mapped Addressing............................................................................................................................................1 9

CONTENTS
5. Software Interface_____________________________________ 21
5.1 ATA Command Block.......................................................................................................21
5.1.1 ATA Command Block for Cylinder-Head-Sector Addressing..............................................................................2 1
5.1.2 ATA Command Block for Logical Block Addressing ..............................................................................................2 2
5.2 Command Descriptions ....................................................................................................22
6. Interface Protocol _____________________________________ 23

6.1 ATA Soft Reset..................................................................................................................23
6.1.1 ATA Soft Reset Timing Definitions..................................................................................................................................2 3
6.1.2 Software Reset One Drive.....................................................................................................................................................2 4
6.1.3 Software Reset Two Drives .................................................................................................................................................2 4
7. PC Card Specific Considerations _______________________ 27

7.1 Card Configuration Registers............................................................................................27
7.2 Card Removal, Insertion and Change Detection ..............................................................27
8. Appendix A: Implementation Notes _____________________ 29

8.1 Special Handling of I/O Ports 3F7H and 377H ................................................................29
9. Appendix B: Card Information Structure ________________ 31

9.1 Card Information Structure ..............................................................................................31
9.2 Function ID Tuple for Disk Function................................................................................31
9.3 Disk Device Interface Function Extension Tuple..............................................................32
9.4 PC Card ATA Features Function Extension Tuple..........................................................32
9.5 PC Card ATA JEDEC ID's................................................................................................33
TABLES
Table 3-1: PC Card ATA Signal Names and Pin Assignment.......................................................5
Table 4-1: Standard Configurations ............................................................................................11
Table 4-2: Data Register...............................................................................................................12
Table 4-3: Error Register...............................................................................................................12
Table 4-4: Feature Register...........................................................................................................13
Table 4-5: Sector Count Register..................................................................................................13
Table 4-6: Sector Number Register...............................................................................................13
Table 4-7: Cylinder Low Register .................................................................................................14
Table 4-8: Cylinder High Register ................................................................................................14
Table 4-9: Drive/Head Register...................................................................................................14
Table 4-10: Status and Alternate Status Registers......................................................................15
Table 4-11: Device Control Register.............................................................................................16
Table 4-12: Drive Address Register .............................................................................................16
Table 4-13: Duplicate Data Register............................................................................................17
Table 4-14: Access to Data, Error and Feature Registers Including Duplicate Registers..........17
Table 4-15: I/O Mapped Addressing..........................................................................................18
Table 4-16: Memory Mapped Address Map...............................................................................19
Table 5-1: Commands with Cylinder-Head-Sector Encoding.....................................................21
Table 5-2: Commands with Logical Block Address Encoding ...................................................22
Table 6-1: Soft Reset Timing Diagram.........................................................................................25
1.1 Purpose
This specification defines the standard method for incorporating an ATA mass storage protocol
peripheral on a 16-bit PC Card. This specification supplements the definitions of an ATA mass
storage peripheral found in the ANSI ATA Standard and the definition of a PC Card found in the
PC Card Standard.
The PC Card ATA protocol described in this document is compatible with existing PC Card defined
socket hardware without any changes or additional pins. PC Card ATA mass storage cards shall be
implemented to operate as I/O devices in conformance with PCMCIA 2.0/JEIDA 4.1 or later. The
cards are also permitted to provide a memory mapped configuration compatible with socket
hardware defined in PCMCIA 1.0/JEIDA 4.0.
This document describes the electrical and software interfaces for a PC Card ATA mass storage card.
The standard address mappings for a PC Card ATA mass storage card are also described.
1.2 Scope
This document is intended to be used together with the PC Card Standard and the ANSI ATA
Standard. It is intended to highlight those areas of implementation in which the PC Card
Standard and the ANSI ATA Standard conflict. In addition, an indication is made of areas within
the ANSI ATA Standard which are modified for operation in a PC Card environment. Both
mandatory and optional specifications are presented.
In the event of a conflict between one of the base documents (PC Card Standard or ANSI ATA
Standard) and this document, the interpretation of this document shall prevail if and only if this
document specifies that a conflict exists between the documents.

There are related documents upon which this document is based and which are required for
understanding and implementing a PC Card ATA mass storage peripheral.
PC Card Standard Release 7.0 (February 1999), PCMCIA/JEIDA
The following is referred to as the ÒANSI ATA StandardÓ:
AT Attachment For Disk Drives , Document Number X3.221-1994, ANSI
INTRODUCTION
1.4 Conventions
This section is intended to give general descriptions of notational conventions used in this
document.
See the Overview and Glossary volume for an extensive set of definitions of terms found in the PC
Card ATA Specification. In many cases, more detailed information about these terms may be found
in the PC Card Standard or the ANSI ATA Standard. These two documents should be consulted
for more detailed and precise definitions of terms.
1.4.1 Signal Naming

All signals are named with respect to their asserted state as follows:
a) Each signal which is not a logic signal, such as Vcc, has a name which does not end with a "#"
character.
b) Each logic signal whose name does not end with a "#" character has logic high as the asserted
state and logic low as the negated state.
c) Each logic signal whose name ends with a "#" character has logic low as the asserted state and
logic high as the negated state.
1.4.2 Numeric Representation

Numbers are expressed as follows:
a) Individual bits are expressed as "0" for zero, "1" for one, or "X" for don't care.
b) Groups of bits (fields) are expressed in hexadecimal number which begin with a decimal digit
and are followed by an "H". Each digit represents 4 bits and ranges from 0H to 9H and AH to FH
for 0 to 15 (decimal) with an "X" being used for don't care. The number of bits in the field
determines how many bits in the hexadecimal number are significant.
1.4.3 Bit Action Representation

Bits of a register are said to be set when they are made equal to "1" and to be cleared when they are
made equal to "0.Ó
2. O V E R V IE W
This document details the requirements and considerations in implementing an ATA protocol mass
storage peripheral within the PC Card environment.
The ATA protocol is followed except where the PC Card interface imposes conflicting constraints to
traditional ATA host bus adapters. This document describes how the ATA protocol maps onto the
PC Card interface. It resolves and clarifies the enhancements and restrictions which result from the
use of the PC Card interface with the ATA protocol.
Mandatory support is provided for the AT BIOS ATA Control Block and Command Block registers
at 1F0H-1F7H, 3F6H-3F7H or 170H-177H, 376H-377H typically using IRQ14. These I/O register
assignments are usable with pre-existing AT BIOS Device Drivers. Mandatory support is also
provided for locating the I/O ports in a contiguous I/O window of at least 16 bytes which is
decoded for the PC Card by the socket. PC Cards can also be built that may be placed by the
system in a 2 KB host memory space by a dedicated driver.
The use of a well known, dominant, standard interface in mobile computers guarantees system
vendors an interface which remains stable over the coming generations of silicon and rotating mass
storage devices.
2.1 Feature Summary

a) The PC Card ATA protocol is based on the widely accepted and established ATA protocol which
is an accepted standard for disk drives in mobile computers. It is also based on the PC Card
interface standard which is the peripheral interface for mobile computing.
b) The ATA protocol is very familiar to both system designers and software developers.
c) This protocol allows PC Card ATA mass storage cards to be "plug and play" in many existing
systems and applications.
d) The protocol is compatible with existing ATA software.
e) The protocol fits easily into the architecture of desktop PCs as well as mobile computers.
2.2 Differences Between PC Card ATA and ATA

a) The Diagnostic command runs only on the card which is addressed by the Drive/Head register
when the Diagnostic Command is issued. This is because the PC Card interface does not
provide for direct inter-drive communication (i.e., the ATA PDIAG- and DASP- signals).
Therefore, unlike ATA, it is not possible when using the PC Card interface for Drive 0 to report
status for both drives.
b) The PC Card ATA Specification provides for two cards at a single address through the Twin
Card option in CIS (See the Metaformat Specification) and card enumeration using the Socket
and Copy register (See the Electrical Specification). The ANSI ATA Standard provides card
enumeration using a jumper or cable strap. The ATA signals PDIAG- and DASP- are not
implemented in the PC Card ATA Specification.
c) The PC Card ATA Specification provides a READY signal which can be used to prevent the
host from accessing the card's registers before the card is available following card detected
power-on, hardware reset, or PC Card soft reset. With an appropriate socket, this signal is also
OVERVIEW
used while a card is configured in the memory mapped mode to provide a socket generated
host interrupt on the transition to ready.
d) The PC Card ATA Specification provides an ATA Soft Reset protocol described in Section 6.1,
ATA Soft Reset.
e) The implementation of the Index bit, IDX, in the Status register and the Alternate Status register
is optional. If implemented, it shall be implemented as defined in the ANSI ATA Standard.
f) I/O ports 3F7H and 377H in the Primary and Secondary I/O mapped modes have a potential
conflict with a floppy disk controller installed in the host. There is a potential problem with the
protocol described in the ANSI ATA Standard for sharing the Drive Address register with a
floppy disk controller when either the ATA peripheral or the floppy disk controller are accessed
through the PC Card interface.
Refer to Appendix B for possible methods to avoid this problem.
g) The PC Card interface permits the host to access the ATA registers in more alternative ways
than the traditional ATA host bus adapter allows. These alternatives arise from the presence of
two card enable signals, CE[2::1]#, in addition to address line A0.
The PC Card interface allows access to registers at odd addresses with two different methods.
a) When address line A0 is 1 (logic high), if CE1# is asserted and CE2# is negated during the
read or write cycle, then the byte of data at the odd address is transferred on signals D[7::0] of
the Data Bus.
b) Regardless of the state of address line A0 and of the state of CE1#, if CE2# is asserted the
byte of data at the odd address is transferred on signals D[15::8] of the Data Bus. If CE1# is also
asserted, then a 16-bit word is accessed. If CE1# is negated, then only the byte at the odd
address is accessed.
A sixteen bit word of data is accessed when both CE[2::1]# are active, regardless of the state of
A0.
h) I/O accesses are constrained at the PC Card interface as follows:
a) The host shall perform all word (16-bit) I/O accesses with A0 = 0.
b) During a host's word access attempt, if a card asserts IOIS16# in response to the address on
the bus then the host system is permitted to transfer 16 bits of data to the card in a single cycle,
otherwise, the host system shall perform two 8-bit cycles: even byte then odd byte.
i) The ANSI ATA Standard specifies that the Data register is two bytes wide and is located at
offset, or relative address zero while the Error and Feature registers are one byte wide and are
located at offset one within the ATA registers. This results in an overlap of the address spaces
between the Data register and Error-Feature register combination.
Some host architectures do not permit word and byte registers to overlap. To permit those hosts
to access all the registers of the PC Card ATA mass storage card, the PC Card ATA Specification
provides a non-overlapping duplicate copy of each of these registers in the Memory Mapped
and Contiguous I/O mapped configurations. Within the 16 byte space occupied by the ATA
registers in these configurations, the duplicate data register is located at offset 8H while the
duplicate Error and Feature registers are located at offset 0DH.
Refer to Section 4.2.13, Duplicate Data, Error and Feature Registers, for more information about
the duplicate copies of these registers.
j) Implementation of the Identify Drive Command is mandatory in the PC Card Standard, but
optional in the ANSI ATA Standard.
3 . EL E C T R IC AL I N T E R F AC E
A PC Card ATA mass storage card uses the PC Card electrical interface. A subset of the entire PC
Card interface is sufficient for PC Card ATA implementation. Both mandatory and optional signals
are given in this section. Special consideration is given to some signals whose definition is expanded
when used in the PC Card ATA mass storage card.
3.1 Pin Assignment Table

The following is the recommended pin assignment table for implementing PC Card ATA protocol.
The mandatory Interface signals are required for using the card in the mandatory card decoded and
host decoded I/O spaces.
Table 3-1: PC Card ATA Signal Names and Pin Assignment

Pin # PC Card PC Card I/O PC Card ATA PC Card ATA Notes 7
Memory Interface Signal Mandatory Optional Signal
Interface Signal Signal
1 GND GND GND
2 D3 D3 D3
3 D4 D4 D4
4 D5 D5 D5
5 D6 D6 D6
6 D7 D7 D7
7 CE1# CE1# CE1#
8 A10 A10 A10 1
9 OE# OE# OE#
10 A11 A11 A11 2
11 A9 A9 A9
12 A8 A8 A8
13 A13 A13 A13 2
14 A14 A14 A14 2
15 WE# WE# WE#
16 READY IREQ# READY: 6
IREQ#
17 Vcc Vcc Vcc
18 Vpp1 Vpp1 Vpp1 or 3
No Connect
19 A16 A16 A16 2
20 A15 A15 A15 2
21 A12 A12 A12 2
22 A7 A7 A7
23 A6 A6 A6
24 A5 A5 A5
ELECTRICAL INTERFACE

(Continued)
25 A4 A4 A4
26 A3 A3 A3
27 A2 A2 A2
28 A1 A1 A1
29 A0 A0 A0
30 D0 D0 D0
31 D1 D1 D1
32 D2 D2 D2
33 WP IOIS16# WP:
IOIS16#
34 GND GND GND
35 GND GND GND
36 CD1# CD1# CD1#
37 D11 D11 D11
38 D12 D12 D12
39 D13 D13 D13
40 D14 D14 D14
41 D15 D15 D15
42 CE2# CE2# CE2#
43 VS1# VS1# VS1#
44 IORD# IORD#
45 IOWR# IOWR#
46 A17 A17 A17 2
47 A18 A18 A18 2
48 A19 A19 A19 2
49 A20 A20 A20 2
50 A21 A21 A21 2
51 Vcc Vcc Vcc
52 Vpp2 Vpp2 Vpp2 or No 3
Connect
53 A22 A22 A22 2
54 A23 A23 A23 2
55 A24 A24 A24 2
56 A25 A25 A25 2
57 VS2# VS2# VS2#
58 RESET RESET RESET

(Continued)
59 WAIT# WAIT# WAIT#
60 INPACK# INPACK#
61 REG# REG# REG#
62 BVD2 SPKR# Logic High unless BVD2: 4
BVD2: SPKR#
SPKR#
63 BVD1 STSCHG# Logic High unless BVD1: 5
BVD: STSCHG#
STSCHG#
64 D8 D8 D8
65 D9 D9 D9
66 D10 D10 D10
67 CD2# CD2# CD2#
68 GND GND GND
NOTES:
Signal names in the PC Card ATA columns indicate dual function signals by listing the Memory Interfaced
function, followed by a colon (:), and then the I/O Interfaced function of the signal. Signals in the PC Card ATA
Optional column may be mandatory for particular features which the card vendor may choose to implement.
The use of optional signals is described in the following numbered notes.
1. Address line A10 is mandatory if Memory Mapped addressing is supported. Otherwise, A10 is
permitted to be implemented at the discretion of the card vendor.
2. Address lines A[25::11] are permitted to be implemented at the discretion of the card vendor.
3. The use of the Vpp[2::1] supplies is optional. If they are used, it is recommended that the card vendor
select +12 V as the Vpp value. A card which does not require any Vpp supply, shall leave both Vpp
pins unconnected at the card.
The Vpp[2::1] supplies shall not be connected to each other on the card.
When only one supply is required, it is recommended that Vpp1 be used.
At power up, the host shall provide at least minimal current at Vcc Volts on both Vpp[2::1].
4. The I/O signal SPKR# is optional. If the function is not implemented, this pin shall be held at logic high
(negated) by the card. The memory signal BVD2 shall be held high unless it is indicating the state of a
battery on the card.
5. The I/O signal STSCHG# is optional, however it shall be implemented if both the Function
Configuration and Status register and the Pin Replacement register are implemented. If the function is
not implemented, this pin shall be held high (negated) by the card. The memory signal BVD1 shall be
held high unless it is indicating the state of a battery on the card.
6. The negated state of the READY signal shall be interpreted to be the Busy state of the signal. See 3.3
READY Signal and RREADY Bit, for additional information on the READY signal.
7. All signals shown in the PC Card ATA mandatory column shall be implemented by all PC Card ATA
mass storage cards.
ELECTRICAL INTERFACE
3.2 Reset Conditions

There are four distinct reset conditions associated with the PC Card ATA mass storage card. They
are as follows:
a) Card detected Power-On Reset;
b) Host generated PC Card Hardware Reset using the Reset signal;
c) Host initiated PC Card Soft Reset using SRESET bit in the Configuration Option register;
d) ATA Soft Reset using the SRST bit in the ATA Device Control register.
The host should always accompany a card Power-On event with a host generated hardware reset as
described in the Power-Up and Power-Down section of the Electrical Specification.
Power-On, PC Card Hardware Reset and PC Card Soft Reset all clear the Configuration Option
register (configuration index value of 0 H) as described in the RESET signal description in the
Electrical Specification and cause the card to perform the ATA Hard Reset protocol.
The PC Card Soft Reset has the same effect as the Host generated hardware reset with the exception
that the PC Card Software Reset bit itself is not cleared by the assertion of Soft Reset as described in
the Configuration Option register section of the Electrical Specification.
The ATA Soft Reset protocol does not affect the card's PC Card configuration, but does perform ATA
Soft Reset protocol as specified in the ANSI ATA Standard and modified in Section 6.1 ATA Soft
Reset, of this document.
3.3 READY Signal and RREADY Bit

The READY signal is available while the card is configured to use the Memory Interface. This
signal is unavailable and is replaced by the interrupt request signal, IREQ#, while the card is
configured to use the I/O interface. The READY signal is negated when the card is in the Busy
condition.
If the Pin Replacement register is implemented on the card, the RREADY bit in that register is
cleared when the card is busy and set when the card is ready.
The card shall be Busy under the following conditions:
a) From Power-On until the card is ready to be accessed.
b) From PC Card Hardware Reset until the card is ready to be accessed.
c) From PC Card Soft Reset until the card is ready to be accessed.
d) If a card supports the PC Card Power-Down bit in the Configuration and Status register, then
from a change in the PC Card Power-Down bit until the card has completed the requested
Power-Down or Power-Up operation.
e) While the card is in a Memory interface configuration, whenever the BSY bit in the ATA Status
register is set.
3.4 Interrupt Request: IREQ#

The interrupt request signal from the card (IREQ#) is available only when the card is configured to
use the PC Card I/O interface. The handling of this signal is slightly different from the handling of
the ATA interrupt request signal, IRQ.
The polarity of the PC Card IREQ# signal is opposite to that of the ATA IRQ signal. The PC Card
IREQ# signal has a mandatory PC Card level mode interrupt and an optional PC Card pulse mode
interrupt. The pulse mode interrupt is designed to allow sharing of interrupts in hosts which use an
ISA compatible system bus between the PC Card socket and the host's CPU. To take advantage of a
PC Card pulse mode interrupt, the host socket must be able to pass the interrupt request signal
without inversion from the PC Card to the internal ISA bus and to drive the ISA bus IRQn signal
with an open collector driver.
When the nIEN bit in the ATA Device Control register is set, the PC Card ATA mass storage card
shall not assert the IREQ# signal. This is in contrast to the ANSI ATA Standard which specifies that
the ATA interrupt request signal, IRQ, is placed in high impedance during these times.
4 . AT A S P E C I F I C R E G I S T E R D E F I N I T I O N S
4.1 PC Card ATA Drive Register and Protocol Definitions

PC Card ATA mass storage cards can be configured as a high performance I/O device through
standard I/O address spaces: 1F0H-1F7H, 3F6H-3F7H (primary); 170H-177H, 376H-377H (secondary)
and IRQ 14 or anywhere in the I/O space or memory space requiring a dedicated driver. The
communications to and from the drive is performed using the ATA Command Block which provides
all the necessary control and status information. The PC Card interface connects peripherals to the
host using four register mapping methods. Table 4-1: Standard Configurations is a description of
these methods:
Table 4-1: Standard Configurations

Config I/O or Memory Address Drive Socket & Mandatory or Description
Index Number Copy Optional
A[10::0]
0H1 Memory 0H - 0FH, 0 X000XXXX Optional Memory
Mapped
400H - 7FFH
1H1 I/O XX0H - XXFH 0 X000XXXX Mandatory I/O Mapped 16
Contiguous
Registers
2H1 I/O 1F0H -1F7H, 3F6H 0 X000XXXX Mandatory Primary I/O
- 3F7H Mapped Drive 0
-------------
5F0H - 5F7H,
7F6H - 7F7H
2H1 I/O 1F0H -1F7H, 1 X001XXXX Optional Primary I/O
3F6H- 3F7H Mapped Drive 1
-------------
5F0H - 5F7H,
7F6H - 7F7H
3H1 I/O 170H - 177H, 376H 0 X000XXXX Mandatory Secondary I/O
- 377H Mapped Drive 0
------------
570H - 577H, 776H
- 777H
3H1 I/O 170H - 177H, 376H 1 X001XXXX Optional Secondary I/O
- 377H Mapped Drive 1
-------------
570H - 577H, 776H
- 777H
NOTES:
1. The configuration indices indicated here are for example only.
The host selects the card's register mapping configuration by writing the Function Configuration
Index value to the least significant 6 bits of the card's Configuration Option register. The actual
configuration index values used by a card are vendor specific and are reported to the host using the
Configuration Table Entry tuples. However, configuration 0 H shall always select the PC Card
Memory-Only interface.
ATA SPECIFIC REGISTER DEFINITIONS
4.2 ATA Registers

The ATA registers are the registers which are provided on the card specifically to implement the
ATA aspects of the PC Card ATA protocol. The first eight registers and duplicates are referred to as
the ATA Command Block.
In accordance with the PC Card Standard each of the registers below which is located at an odd
address may be accessed using either data bus lines D[15::8] or using data bus lines D[7::0]. Refer to
Section 2.2, Differences Between PC Card ATA and ATA, or to the Electrical Specification for more
information.
4.2.1 Data Register

The Data register is a 16-bit register which is used to transfer data blocks between the card data
buffer and the host. Data may be transferred by either a series of word accesses to the Data register
or a series of byte accesses to the Data register. The ANSI ATA Standard Signal Descriptions and
Set Features Command sections specify under what conditions word and byte accesses from the host
are appropriate to access this register.
Table 4-2: Data Register

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0
Data Word
Data Byte
Refer to the ANSI ATA Standard for detailed information about this register. Refer also to Section
4.2.13, Duplicate Data, Error and Feature Registers, for additional information about the Data
register, the Duplicate Data registers, and the interactions between the Data register and the Error
or Feature register.
4.2.2 Error Register

This register contains additional information about the source of an error which has occurred in
processing of the preceding command. This register should be checked by the host when bit 0
(ERR) in the Status register is set. The Error register is a read only register. When writing to the
address of the Error register, the Feature register is written.
Table 4-3: Error Register

D7 D6 D5 D4 D3 D2 D1 D0
BBK UNC MC IDNF MCR ABRT TKNOF AMNF
All bits in this register are defined in the ANSI ATA Standard. Refer to the ANSI ATA Standard
for a detailed description of this register. Refer also to Section 4.2.13, Duplicate Data, Error and
Feature Registers, for additional information about the Error register, the Duplicate Error register,
and the interactions between the Data register and the Error register.
4.2.3 Feature Register

This register is written by the host to provide command specific information to the drive regarding
features of the drive which the host wishes to utilize. The Feature register is a write only register.
When reading from the address of the Feature register, the Error register is read. This register may
be ignored by some drives.
Table 4-4: Feature Register

D7 D6 D5 D4 D3 D2 D1 D0
Feature Byte
Refer to the ANSI ATA Standard for a detailed description of this register. Refer also to Section
4.2.13: Duplicate Data, Error and Feature Registers, for additional information about the Feature
register, the Duplicate Feature register, and the interactions between the Data registers and the
Feature register.
4.2.4 Sector Count Register

This register is written by the host with the number of sectors or blocks to be processed in the
subsequent command. After the command is complete, the host may read this register to obtain the
count of sectors left unprocessed by the command.
Table 4-5: Sector Count Register

D7 D6 D5 D4 D3 D2 D1 D0
Sector Count
Refer to the ANSI ATA Standard for a detailed description of this register.
4.2.5 Sector Number Register

This register is written by the host with the starting sector number to be used in the subsequent
Cylinder-Head-Sector command. After the command is complete, the host may read the final sector
number from this register. When logical block addressing is used, this register is written by the
host with bits 7 to 0 of the starting logical block number and contains bits 7 to 0 of the final logical
block number after the command is complete.
Table 4-6: Sector Number Register

D7 D6 D5 D4 D3 D2 D1 D0
Sector Number (CHS Addressing)
Logical Block Number bits A07-A00 (LBA Addressing)
4.2.6 Cylinder Low Register

This register is written by the host with the low-order byte of the starting cylinder address to be
used in the subsequent Cylinder-Head-Sector command. After the command is complete, the host
may read the low-order byte of the final cylinder number from this register. When logical block
addressing is used, this register is written by the host with bits 15 to 8 of the starting logical block
number and contains bits 15 to 8 of the final logical block number after the command is complete.
Table 4-7: Cylinder Low Register

D7 D6 D5 D4 D3 D2 D1 D0
Cylinder Number Low Byte (CHS Addressing)
4.2.7 Cylinder High Register

This register is written by the host with the high-order byte of the starting cylinder address to be
used in the subsequent Cylinder-Head-Sector command. After the command is complete, the host
may read the high-order byte of the final cylinder number from this register. When logical block
addressing is used, this register is written by the host with bits 23 to 16 of the starting logical block
number and contains bits 23 to 16 of the final logical block number after the command is complete.
Table 4-8: Cylinder High Register

D7 D6 D5 D4 D3 D2 D1 D0
Cylinder Number High Byte (CHS Addressing)
4.2.8 Drive/Head Register

The Drive/Head register is used to specify the selected drive of a pair of drives sharing a set of
registers. The bits are defined as follows:
Table 4-9: Drive/Head Register

D7 D6 D5 D4 D3 D2 D1 D0
1 LBA (0) 1 DRV HS3 HS2 HS1 HS0

LBA(1) LBA27 LBA26 LBA25 LBA24
Bit 7 1 This bit is '1'.

Bit 6 LBA This bit is '0' for Cylinder-Head-Sector addressing and '1' for Logical Block
Addressing.
Bit 5 1 This bit is '1'.
Bit 4 DRV This bit is number of the drive which the host has selected. When DRV is cleared,
drive 0 (card 0) is selected. When DRV is set, drive 1 (card 1) is selected. The card
is selected to be Card 0 or to be Card 1 using the "Copy" field of the PC Card Socket
and Copy configuration register, if present. If no Socket and Copy configuration
register is present on the card, or if the Card's CIS indicates that it does not support
twin-cards for the selected configuration, then DRV shall be cleared by the host.
Bit 3 HS3/LBA27 This is bit 3 of the head number in CHS addressing or bit 27 of the Logical Block
Number in LBA addressing.
Number in LBA addressing
4.2.9 Status and Alternate Status Registers

The Status register and the Alternate Status register return the card status when read by the host.
Reading the Status register clears a pending interrupt request while reading the Alternate Status
register does not.
The Status register and the Alternate Status register are read only registers. When writing to the
address of the Status register, the Command register is written. When writing to the address of the
Alternate Status register, the Device Control register is written.
The status bits are identified as follows:
Table 4-10: Status and Alternate Status Registers

D7 D6 D5 D4 D3 D2 D1 D0
BSY DRDY DWF DSC DRQ CORR IDX ERR
Refer to the ANSI ATA Standard for a description of the bits which are described in this register
except where the ANSI ATA Standard conflicts with the descriptions below.
Bit 1 IDX This bit is optional. If implemented it shall be implemented as described in the ANSI
ATA Standard.
Bit 5 DWF This bit is used to indicate a drive write failure. Drives which require Vpp for write
operations should use this bit to signal if the Vpp voltage is out of tolerance when a
write is attempted.
4.2.10 Command Register

The Command register contains the command code being sent to the device. Command execution
begins immediately after this register is written.
The Command register is a write only register. When reading from the address of the Command
register, the Status register is read.
D7 D6 D5 D4 D3 D2 D1 D0
Command
4.2.11 Device Control Register

This register is used to control the card interrupt request and to issue a soft reset to the card.
The Device Control register is a write only register. When reading from the address of the Device
Control register, the Alternate Status register is read.
The bits are defined as follows:
Table 4-11: Device Control Register

D7 D6 D5 D4 D3 D2 D1 D0
X X X X 1 SRST nIEN 0
Refer to the ANSI ATA Standard for the general description of the bits which are described in this
register except where it conflicts with the descriptions noted below:
Bit 1 nIEN While the card is operating in the memory mapped mode this bit is permitted to be
ignored; but see additional requirements in Section 7.1, Card Configuration Registers,
for cards which implement the Function Configuration and Status register.
While this bit is cleared, interrupts shall operate as described in the PC Card
Standard in response to the events described in the ANSI ATA Standard.
While this bit is set, the interrupts on the card shall be disabled. The IREQ# signal in
the PC Card I/O interface shall be negated unless the nIEN bit is cleared and an
interrupt has been requested.
Bit 2 SRST The Software Reset bit shall operate generally as described in the ANSI ATA
Standard with the following exceptions:
Sections of ANSI ATA Standard which refer to the PDIAG- and the DASP- signals
are not applicable to PC Card implementations. Section 6.1, ATA Soft Reset, of this
document shall define the Soft Reset Function and protocol.
4.2.12 Drive Address Register

This register is provided for compatibility with the AT disk drive interface. The bits can be read by
the host and are defined as follows:
Table 4-12: Drive Address Register

D7 D6 D5 D4 D3 D2 D1 D0
X nWTG nHS3 nHS2 nHS1 nHS0 nDS1 nDS0
Bit 7 X This bit shall be ignored by the host. Please see Appendix B: Card Information Structure of
this document for a discussion of the considerations involving this bit.
Bit 6 nWTG This bit is cleared while a write operation is in progress, otherwise, it is set.
When the bit is cleared the host should not alter the Vpp or Vcc supply voltages to the card.
Refer to the ANSI ATA Standard for description of the bits which are described in this register
except where the ANSI ATA Standard conflicts with the descriptions provided above.
4.2.13 Duplicate Data, Error and Feature Registers

The address space occupied by the Data register overlaps with space occupied by the Error and
Feature registers. The table below describes the combinations of Data register access and Error or
Feature register accesses. The table is provided here to assist in understanding the overlapped Data
register and Error or Feature register rather than to attempt to define general PC Card word and
byte access modes and operations. See the PC Card Standard for definitions of the Card Accessing
Modes for I/O and Memory cycles. These cycles are also summarized in Section 2.2 Differences
Between PC Card ATA and ATA.
Table 4-13: Duplicate Data Register

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0
Data Word
Odd Data Byte Only Even or Even-Odd Data Byte
Because of the overlapped registers, access to the Error or Feature registers at 1F1 H, 171H and offset
1H are not possible when word accesses are performed, i.e., with CE1# and CE2# both asserted. The
Duplicate Registers at relative addresses 8H, 9H and 0DH have no restrictions on the operations
which can be performed by the socket.
Table 4-14: Access to Data, Error and Feature Registers Including Duplicate Registers
Data Register CE2# CE1# A0 Offset Data Bus
Word Data register L L L 0H, 8H D15-D0

Word Data register L L H 1H, 9H D15-D0
Even Byte Data register H L L 0H,8H D7-D0
Odd Byte Data register H L H 9H D7-D0
Odd Byte Data register L H X 8H, 9H D15-D8
Error / Feature Register H L H 1H, 0DH D7-D0
Error / Feature Register L H X 0H, 1H D15-D8
Error / Feature Register L L X 0C, 0DH D15-D8
NOTES:
1. The Data register at 0H is accessed with both CE1# and CE2# asserted as a word register on the
combined Odd Data Bus and Even Data Bus (D[15::0]). This register may also be accessed by a pair
of byte accesses to the offset 0H with CE1# asserted and CE2# negated. Word accesses at odd
address N+1 is the same as a word access at address N, however, word accesses at odd addresses
are illegal for I/O accesses. Note that the address space of this word register overlaps the address
space of the Error and Feature byte-wide registers which are located at offset 1H. When accessed
twice as byte register with CE1# asserted, the first byte to be accessed is the Even byte of the Word
and the second byte accessed is the Odd byte of the equivalent Word access.
A byte access to address 0H with CE1# negated and CE2# asserted accesses the Error (read) or
Feature (write) register.
2. The registers located at offsets 8H, 9H and 0DH are non-overlapping duplicates of the registers at
offsets 0 and 1.
Register 8H is equivalent to register 0H, while register 9H accesses only the Odd byte of the Data
register. Therefore, if the registers are byte accessed in the order 9H then 8H the data will be
transferred Odd byte then Even byte. Repeated byte accesses to register 8H or 0H will access
consecutive (even then odd) bytes from the data buffer. Repeated word accesses to register 8H, 9H or
0H will access consecutive words from the data buffer. Repeated byte accesses to register 9H are not
supported. However, repeated alternating byte accesses to registers 8H then 9H will access
consecutive (even then odd) bytes from the data buffer. Byte accesses to register 9H access only the
odd byte of the data word.
3. Memory accesses to even addresses at offsets between 400H and 7FFH access register 8H.
Accesses to odd addresses at offsets between 400H and 7FFH access register 9H. This 1 Kbyte
memory window to the Data register is provided so that hosts can perform memory to memory block
moves to the Data register when the register lies in memory space. This entire window accesses the
Data register FIFO and does not directly address the data buffer within the card.
Some hosts, such as the 80x86 processors, increment both the source and destination addresses when
executing the memory to memory block move instruction. Some PC Card socket adapters also have
auto incrementing address logic embedded within them. This address window allows these hosts and
adapters to function efficiently.
4.3 ATA Specific Register Mapping
4.3.1 I/O Mapped Addressing

The Primary I/O, Secondary I/O, and Contiguous I/O address maps are shown in Table 4-15: I/O
Mapped Addressing.
The contiguous I/O mapping mode requires that the system decode a contiguous block of at least 16
I/O registers to uniquely select the card.
Table 4-15: I/O Mapped Addressing

REG# Primary Secondary Contiguous IORD# =0 IOWR# =0 Note
A[9::0] A[9::0] A[3::0]
L 1F0H 170H 0H Even Read Data Even Write Data 1
L 1F1H 171H 1H Error Register Feature 2
L 1F2H 172H 2H Sector Count Sector Count
L 1F3H 173H 3H Sector Number Sector Number
L 1F4H 174H 4H Cylinder Low Cylinder Low
L 1F5H 175H 5H Cylinder High Cylinder High
L 1F6H 176H 6H Drive/Head Drive/Head
L 1F7H 177H 7H Status Command
L --- --- 8H Duplicate Duplicate 1,3
Even Read Data Even Write Data
L --- --- 9H Duplicate Duplicate 1,3
Odd Read Data Odd Write Data
L --- --- 0DH Duplicate Error Duplicate Feature 3
L 3F6H 376H 0EH Alternate Status Device Control
L 3F7H 377H 0FH Drive Address Reserved
NOTES:
1. This register supports word or byte accesses. See note 1 for Table 4-14: Access to Data, Error and
Feature Registers Including Duplicate Registers.
2. This register overlaps the address space of the Data register. See note 1 for Table 4-14: Access to
Data, Error and Feature Registers Including Duplicate Registers.
3. This register address is a duplicate address assignment for another register. A duplicate address is not
available in the Primary I/O and Secondary I/O decodings. See note 2 for Table 4-14: Access to
Data, Error and Feature Registers Including Duplicate Registers.
Address lines which are not indicated in the decoding above are ignored by the card for accessing
these registers. The primary and secondary modes decode 10 address lines while the contiguous
decoding decodes only 4 address lines on the card.
4.3.2 Memory Mapped Addressing

When the card registers are accessed via memory references, the registers appear in the common
memory space window from 0-2K bytes as shown in Table 4-16: Memory Mapped Address Map.
Table 4-16: Memory Mapped Address Map

REG# A10 A[9::4] A3 A2 A1 A0 OE#=0 WE#=0 Notes
H L X L L L L Read Data Write Data 1

H L X L L L H Error Feature 2
H L X L L H L Sector Count Sector Count
H L X L L H H Sector Number Sector Number
H L X L H L L Cylinder Low Cylinder Low
H L X L H L H Cylinder High Cylinder High
H L X L H H L Drive /Head Drive/Head
H L X L H H H Status Command
H L X H L L L Duplicate Even Duplicate Even 1,3
Read Data Write Data
H L X H L L H Duplicate Odd Duplicate Odd 1,3
Read Data Write Data
H L X H H L H Duplicate Error Duplicate Feature 1,3
H L X H H H L Alt Status Device Ctl
H L X H H H H Drive Address Reserved
H H X X X X L Even Read Data Even Write Data 4
H H X X X X H Odd Read Data Odd Write Data 4
NOTES:
1. This register supports word or byte accesses. See note 1 for Table 4-14: Access to Data, Error and
Feature Registers Including Duplicate Registers.
2. This register overlaps the address space of the Data register. See note 1 Table 4-14: Access to Data,
Error and Feature Registers Including Duplicate Registers.
3. This register address is a duplicate address assignment for another register. A duplicate address is not
available in the Primary I/O and Secondary I/O decodings. See note 2 for Table 4-14: Access to Data,
Error and Feature Registers Including Duplicate Registers.
4. Memory accesses to even addresses at offsets between 400H and 7FFH access register 8H.
Accesses to odd addresses at offsets between 400H and 7FFH access register 9H. This 1 KB memory
window to the Data register is provided so that hosts can perform memory to memory block moves to
the Data register when the register lies in memory space. Note that this entire window accesses the
Data register FIFO and does not directly address the data buffer within the card.
Some hosts, such as the 80x86 processors, increment both the source and destination addresses when
executing the memory to memory block move instruction. Some PC Card socket adapters also have
auto incrementing address logic embedded within them. This address window allows these hosts and
adapters to function efficiently.
If memory mapped mode is supported, the card shall be implemented so that the card will respond
at the addresses indicated within the ranges of 0H-0FH and 400H-7FFH from the start of the address
space allocated to the PC Card ATA memory mapped registers as indicated by the CIS Device ID
and JEDEC ID tuples. Additional decoding is permitted to be provided at the discretion of the card
manufacturer.
5 . S O F T WA R E I N T E R F A C E
This section defines the software requirements and the commands the host sends to the card. The
controller executes the commands and reports the results to the host using the Status register.
5.1 ATA Command Block

The ATA command block includes the Data register and the group of seven registers which are
used to issue commands using the ATA command protocol. The interpretation of the contents of
these registers is a function of the addressing mode which is used to address the media in the card.
A Cylinder-Head-Sector addressing method of addressing, and a Logical Block addressing mode are
supported.
5.1.1 ATA Command Block for Cylinder-Head-Sector Addressing

To perform a function the host writes up to seven bytes to the card. These bytes, called the ATA
Command Block, specify the command to be executed and its associated parameters. The following
figure shows the general content of the ATA command block. Refer to specific commands in the
ANSI ATA Standard for the bytes required by each command.
Table 5-1: Commands with Cylinder-Head-Sector Encoding

Bit è D7 D6 D5 D4 D3 D2 D1 D0
(Byte offset)
1 Feature
2 Sector Count
3 Sector Number
4 Cylinder Low
5 Cylinder High
6 1 LBA=0 1 DRV Head
7 Command
SOFTWARE INTERFACE
5.1.2 ATA Command Block for Logical Block Addressing

To perform a function using Logic Block Addressing, the host writes to the same seven registers as
for Cylinder-Head-Sector addressing. However, the LBA bit is Set and the Sector Number, Cylinder
Low, Cylinder High and Head fields of the command block provide a starting logical block address
on the card. They are interpreted as follows:
Table 5-2: Commands with Logical Block Address Encoding

Bit è D7 D6 D5 D4 D3 D2 D1 D0
(Byte offset)
1 Feature
2 Sector Count
3 Logical Block Number A7-A0
6 1 LBA=1 1 DRV Logical Block Number A27-A24
7 Command
CHS to LBA translation formula: LBA = (C * HpC + H) * SpH + S- 1

LBA to CHS translation formulas: C = LBA / (HpC * SpH)
H = (LBA / SpH) mod HpC
S = (LBA mod SpH) + 1
where LBA is Logical Block Address

C is Cylinder Number
H is Head Number
S is Sector Number
HpC is Heads per Cylinder
SpH is Sectors per Head (Track)
5.2 Command Descriptions

The ANSI ATA Standard should be consulted for detailed tables and descriptions of the commands.
Exceptions to the descriptions are noted below and also in Section 2.2, Differences Between PC Card
ATA and ATA, of this document.
Section 2.2, Differences Between PC Card ATA and ATA describes a difference in the handling of
the Diagnostic command between the PC Card ATA Specification and the ANSI ATA Standard.
Implementation of the Identify Drive Command is mandatory in this PC Card Standard, but
optional in the ANSI ATA Standard.
6 . I N T E R F AC E PR OT OC OL
Refer to the Logical Interface section of the ANSI ATA Standard for Logical Interface descriptions
with the following exceptions:
a. All references to the PDIAG- and the DASP- signals shall be ignored.
b. Port addressing given in the ANSI ATA Standard I/O Port Functions/Selection Addresses is
replaced by Sections 4.2.3, Feature Register, and 4.3.1, I/O Mapped Addressing, of this
document.
c. The high impedance state of INTRQ is replaced by the interrupts disabled state as described in
Section 3.4, Interrupt Request: IREQ#, of this document.
d. Support for the Index bit (IDX) in the status registers is optional.
e. The host provides drive number configuration of each card by writing bit 4 of the Card's Socket
and Copy register with the value 0 for drive 0 or with the value 1 for drive 1.
f. DMA is not supported by PC Card ATA.
g. PC Card Standard bus timing applies for PC Card ATA.
6.1 ATA Soft Reset

This bit is set to 1 in the Device Control register to force the card to perform an AT Disk Controller
hard reset operation. This reset does not change the configuration of the card interface as would
either a PC Card hardware reset or a PC Card Soft Reset.
In Twin Card, use the following software protocol to determine when Drive 0 and Drive 1 are
ready.
6.1.1 ATA Soft Reset Timing Definitions

Definitions: tB Drive 0 is the time from ATA Soft Reset cleared until drive 0
clears BSY when Drive 1 may be present. It is specified
as a minimum.
tB Drive 1 is the time from ATA Soft Reset cleared until drive 1
clears BSY. It is specified as a maximum.
tN is the time from ATA Soft Reset set until the drive sets
BSY. It is specified as a maximum.
tU is the time from the posting of Drive Ready and
Diagnostic Results until the drive clears BSY. It is
specified as a minimum.
INTERFACE PROTOCOL
6.1.2 Software Reset One Drive

This protocol applies only when the drive is configured so that it is the only drive which can be
present at an address. This is the case when an I/O Mapped Configuration without Twin Cards
support or the memory mapped configuration is used.
1. Host sets SRST=1 in the Device Control register.
2. Drive 0 sets BSY within 400 ns after SRST is set to 1.
3. Drive 0 begins hardware initialization.
4. Drive 0 may revert to its default condition.
5. Drive 0 posts diagnostic results to the Error register.
6. Drive 0 clears BSY when ready to accept commands.
6.1.3 Software Reset Two Drives

This protocol applies whenever the drive is in a configuration which supports more than one drive
at a single address whether or not more than one drive is actually present at that address in the
system.
1. Host sets SRST=1 in the Device Control register.
2. Drive 0 and Drive 1 each set BSY within 400 ns after SRST is set.
3. Drive 0 and Drive 1 begin hardware initialization.
4. Drive 0 and Drive 1 may revert to their default condition.
Drive 1
5. Drive 1 performs initialization and diagnostics which will complete within tB Drive 1 after Soft
Reset is cleared.
6. With adequate time remaining to complete steps 7 through 9 before tB Drive 1 has expired,
Drive 1 determines whether it has completed diagnostics and is ready to execute a command.
7. If the diagnostic results are uncertain at this time, then the drive will report the diagnostics as
having passed. The drive shall place the value "01H" (passed diagnostic) in the Error register.
If the diagnostic results are available at this time, then the drive shall place the diagnostic result
in the Error register.
8. If the drive is ready to execute a command then the drive shall set the DRDY bit in the Status
register otherwise the drive shall clear the DRDY bit in the Status register.
9. The drive clears BSY in the Status register.
Drive 0
5. Drive 0 shall perform and complete initialization and diagnostics.
6. Drive 0 shall delay until tB Drive 0 has expired.
7. Drive shall place the diagnostic result in the Error register with the assumption that drive 1 has
passed diagnostics.
8. If the drive is ready to execute a command then the drive shall set the DRDY bit in the Status
register otherwise the drive shall clear the DRDY bit in the Status register.
9. The drive clears BSY in the Status register.
Table 6-1: Soft Reset Timing Diagram
SRST
BSY
Drive 0
tN tB Drive 0
DRDY
Result Drive 0
tU
BSY
Drive 1
tN tB Drive 1
DRDY
Result Drive 1
tU
Label Value Units Conditions

tN 400 nsec Max All
tB Drive 0 0 msec Min Single Drive Configuration
tB Drive 0 100 msec Min Multi Drive Configuration
tB Drive 1 50 msec Max Multi Drive Configuration
tU 0 nsec Min All
7 . P C C A R D S P E C I F I C C O N S I D E R AT I O N S
7.1 Card Configuration Registers

The PC Card Configuration registers are described in the Electrical Specification, Card
Configuration section. When only some of the bits in a register are required by a card, the
unsupported bits may be ignored by the card when written and should return stable data (typically
0) when read.
The Configuration Option register is the only register which is mandatory for all PC Card ATA
mass storage cards. This register is used to specify the addressing mode of the card, the interrupt
mode (Level or Pulsed) and to assert PC Card Soft Reset.
The Function Configuration and Status register is required to be implemented on the card only if
the card supports the PC Card power-down, audio, or Status Changed features, none of which are
mandatory. If PC Card power-down is supported, it is recommended that this place the drive in the
lowest power state available from which the drive can recover by restoring the PC Card Power
Down Bit to 0. The Status Changed feature also requires that the Pin Replacement register be
implemented.
If the Function Configuration and Status register is implemented on the card, the Interrupt Request
bit in the register shall be controlled as follows: The bit shall be set when the drive has an interrupt
request pending and the Interrupt Enable bit in the ATA Device Control register is set to permit
interrupts. While a drive is configured for the Memory-Only interface, the behavior of the Interrupt
Request bit in the Function Configuration and Status register is the same as if an I/O interface were
configured, although the Hardware Interrupt Request signal will not be available from the card.
The IOis8-bit in the Card Configuration and Status register is set by the host to inform the card that
the host will perform all I/O to the card as 8-bit I/O transferred on the Even Data Bus. This bit
should not be interpreted as controlling the width of data accesses to the card.
The Pin Replacement register is required to be implemented on the card only if the card is
designed to return READY, Write Protect Switch or Battery Status while the card is using the I/O
interface.
The Socket and Copy register, bit 4, is required to be implemented on the card if the card is
designed to be host selectable as either drive 0 or as drive 1. A card indicates this capability with
the Twin Cards field in the Configuration Table Entry Tuple of the Card Information Structure. The
drive number selection is performed by clearing bit 4 of the Socket and Copy register to 0 for drive
0 or setting the bit to 1 for drive 1. The twin card operation is intended for emulating ATA
Master/Slave operation in the AT Primary and AT Secondary I/O mapped addressing
configurations.
7.2 Card Removal, Insertion and Change Detection

The ATA Card insertion and removal shall be detected by having the socket monitor the Card
Detect pins of the card and notify the client driver when there is a change in their status. The
Identify Drive command can be used (Model and Serial Number) to determine whether a drive
which is inserted into a socket is already mounted by the system. Be aware, however, that the data
on the PC Card may have been altered on another system between the time it is removed from and
then returned to the first system.
8 . A P P E N D I X A : I M P L E M E N T AT I O N N O T E S
8.1 Special Handling of I/O Ports 3F7H and 377H

The standard, AT-BIOS compatible, address for the Drive Address register at its primary location is
shared with bit 7, the Disk Change bit, of the Floppy Disk Controller at its standard primary
location.
A non-PC Card ATA host adapter prevents a bus conflict between the Floppy Disk Controller and
the ATA peripheral by keeping data bit 7 in high-impedance at the system bus while the register is
read.
When an ATA host bus adapter is used, the Floppy Disk Controller and the ATA Drive are
connected to the same physical wires on the data bus, so that when the Drive Address register is
accessed, the Floppy Disk Controller places D[6::0] in the high impedance state while the ATA
drive places D7 in the high impedance state. This action prevents a bus conflict.
A PC Card socket in a host is likely to include a bus transceiver between the card's data pins and
the host's system data bus. Unless the socket has been custom designed to resolve this problem, the
bus transceiver is unable to generate a high-impedance output on the system data bus signal D7 in
response to a high impedance input from the D7 data line on the PC Card socket. Therefore, the
traditional ATA solution to the 3F7H register is not directly usable in the PC Card interface.
Therefore, a PC Card ATA mass storage card configured to operate at the Primary (or Secondary)
I/O addresses, conflicts with a Floppy Disk Controller which resides in the system and also uses
port 3F7H (or 377H). A conflict also occurs if the bus width supported by the PC Card ATA mass
storage card and the Floppy Disk Controller are not equal.
The following are methods to avoid this condition in PC Card implementations. The selection of the
best mechanism for a particular system will depend upon the characteristics of the host's socket, the
host's driver software and the PC Card ATA mass storage card installed in the socket.
1. Locate the PC Card ATA mass storage card at a non-conflicting address. In hosts where a Floppy
Disk Controller is potentially present at 3F7H in the PC Card ATA mass storage cardÕs Primary
I/O address range, the PC Card ATA mass storage card would not be configured to use its
Primary I/O address range. Either a contiguous I/O space decoded by the socket in a
non-conflicting area of the I/O space or the PC Card ATA mass storage cardÕs Secondary
address range, 170H to 177H and 376H to 377H, would be configured by the host.
This method will work with any socket and PC Card ATA mass storage card but requires that
the software which accesses the card be aware of the location of the I/O ports for the card.
2. Hosts in which it is impossible for a Floppy Disk Controller and a PC Card ATA mass storage
card to reside in the system at the same time are not subject to this problem.
This method will work only in systems where it is not possible to install both devices at the
same time. For example, a system with a single PC Card socket, no embedded Floppy Disk
Controller and no I/O expansion bus.
3. Avoid enabling the PC Card ATA mass storage cardÕs Drive Address register. There are two
conditions to allow this method. 1) The software used to access the PC Card ATA mass storage
card must not use this register. 2) The port on the PC Card ATA mass storage card must be
prevented by socket or card hardware from responding. This may be accomplished in two
ways.
APPENDIX A: IMPLEMENTATION NOTES
a) If byte granularity of I/O port address decoding is supported by the socket, the socket would
be programmed to enable the PC Card ATA mass storage card only for I/O addresses 1F0
through 1F7H and 3F6H for a Primary address conflict. For a Secondary address conflict, the
socket would be programmed to enable only I/O addresses 170 H through 177H and 376H to the
card.
b) If the PC Card ATA mass storage card provides an additional Primary or Secondary
configuration of the card which does not respond to accesses to I/O locations 3F7H or 377H, that
configuration should be selected in preference to the configuration which also includes 3F7H or
377H.
This method requires that either the socket or the PC Card ATA mass storage card have the
ability to selectively disable port 3F7H or 377H while keeping the other addresses in the
Primary or Secondary address range active. This method also requires that the host software
shall not attempt to use information in the Drive Address register.
4. If socket hardware in the system is designed specifically to avoid this conflict then it shall be
able to selectively force the socket's system data bus signal D7 to be in high impedance and the
PC Card's IOIS16# signal (IOCS16# on the host ISA or EISA bus) to treated as negated during
accesses to I/O address 3F7H or 377H. This feature would be used when PC Card ATA mass
storage card is installed. If a floppy disk controller PC Card is permitted to be installed in the
system, then each socket must also have the ability to force the socket's system data bus signal
lines D6 through D0 to be in high impedance and the card's IOIS16# signal to treated as
negated during accesses to I/O address 3F7H or 377H.
This method requires special socket hardware. This method does not require any special
treatment or modifications to existing software accessing the drive at the primary addresses.
9 . A P P E N D I X B : C A R D I N F O R M AT I O N
ST R U C T U R E
9.1 Card Information Structure

A Card Information Structure shall be present on the card. The minimum required tuples for the
card are not necessarily in order of appearance:
a) Required: Device ID Tuple, CISTPL_DEVICE, tuple code 01H. This tuple must be the first tuple
on the card. If the card supports the memory mapped PC Card ATA mode, a Device ID tuple
shall be present which identifies the region of memory space occupied by the ATA registers as
having a device type DH; Function Specific region. In PCMCIA 1.0 & 2.0/JEIDA 4.0 & 4.1
nomenclature, this device type was named "I/O".
b) Required: Configuration Tuple, CISTPL_CONFIG, tuple code 1AH. This tuple identifies the
location and presence of the Card Configuration registers in the attribute memory space of the
card. In the PCMCIA 2.0/JEIDA 4.1 nomenclature, this tuple was labeled "CISTPL_CONF".
c) Required: Configuration Entry Tuples, CISTPL_CFTABLE_ENTRY, tuple code 1B H. One of
these tuples shall be present for each Configuration Index value which is supported by the card.
In the PCMCIA 2.0/JEIDA 4.1 nomenclature, this tuple was labeled "CISTPL_CE".
d) Required: Function ID Tuple, CISTPL_FUNCID, tuple code 21H, with a function ID value of 04H
for disk function. This tuple allows Card Services clients to quickly determine the class of card
which is present in the socket. See 9.2 Function ID Tuple for Disk Function.
e) Required: Function Extension Tuple, CISTPL_FUNCE, tuple code 22, Type 1, Disk Interface
with an interface ID value of 01, PC Card ATA interface. This tuple identifies the card as being
PC Card ATA. See 9.3 Disk Device Interface Function Extension Tuple.
f) Recommended/Required: Function Extension Tuple, CISTPL_FUNCE, tuple code 22, Types 2
and 3, PC Card ATA Features. These tuples identify optional features of the PC Card ATA
protocol which are implemented on the card. These tuples are optional unless the card supports
the Dual drive mode in which case both Type 2 and Type 3 versions are required. See 9.4 PC
Card ATA Features Function Extension Tuple.
g) Recommended: JEDEC ID Tuple, CISTPL_JEDEC C, tuple code 18H. It is recommended that
cards which support the memory mapped ATA registers described in this document identify
the region of memory space containing the registers with a JEDEC ID code indicating PC Card
ATA protocol support. Use of a standardized ID from Section 9.5 PC Card ATA JEDEC ID's is
recommended, although a vendor specific JEDEC ID codes is permitted. If a vendor specific
JEDEC ID is used, the interoperability of the card will be limited to those host systems which
recognize vendor's unique IDs.
See Guidelines for ATA CIS considerations and samples.
9.2 Function ID Tuple for Disk Function

This tuple specifies that the card supports disk device functionality. This tuple is followed by one or
more Function Extension Tuples which further specify the disk function which is supported. The PC
Card ATA CIS shall include this tuple and a Function Extension Tuple describing the disk interface
protocol as PC Card ATA. Additional Function Extension tuples describing the disk function on the
APPENDIX B: CARD INFORMATION STRUCTURE
card are also permitted. For details on the tuple structure please refer to the Metaformat
Specification.
9.3 Disk Device Interface Function Extension Tuple

This tuple specifies the device interface protocol used in the disk function described in the Function
ID tuple of Section 9.2: Function ID Tuple for Disk Function. This tuple shall follow the Function ID
tuple for Disk Function described in Section 9.2: Function ID Tuple for Disk Function without any
other intervening Function ID tuples. For details on the tuple structure please refer to the
Metaformat Specification.
9.4 PC Card ATA Features Function Extension Tuple

This Function Extension Tuple specifies the PC Card ATA related features of the disk function
described in the Function ID tuple of Section 9.2: Function ID Tuple for Disk Function. This tuple is
optional unless the card contains a Dual drive (coupled Master and Slave drives) in which case the
tuples are required. When present, the extension tuple with function extension type code 02 H
(Single or Master Drive) shall follow the Function ID tuple for Disk Function described in Section
9.2: Function ID Tuple for Disk Function without any other intervening Function ID tuples. When
present, the extension tuple with type code 03H (Slave Drive) shall follow the extension tuple with
extension type 02H without any intervening tuples.
The PC Card ATA Slave Drive Features Extension Tuple applies only to card configurations (values
of Configuration Index) which have a value of 0 in the Max Twin Cards field (either explicit or
implied) of the Miscellaneous Features Field of the Configuration Entry tuple. For details on the
tuple structure please refer to the Metaformat Specification.
9.5 PC Card ATA JEDEC ID's

PCMCIA 2.01/JEIDA 4.1 and previous releases provide for the use of JEDEC Identifiers to specify
the access algorithm for regions of memory space on a PC Card. PCMCIA/JEIDA have adopted
specific JEDEC ID codes to indicate regions of memory space which contain the memory mapped PC
Card ATA registers as described in this document. These identifiers use the JEDEC Manufacturer ID
of DFH (95 decimal with odd parity), which has been assigned to PCMCIA/JEIDA by JEDEC. The
following two byte JEDEC ID's are used for PC Card ATA regions. The JEDEC ID's for PC Card
ATA identify both the access protocol, PC Card ATA, and the handling of the VPP supply within
the PC Card ATA protocol.
The JEDEC ID's for PC Card ATA are defined as follows:
First Byte Second Byte Description
DF H 01H PC Card ATA with no Vpp required for any operation.

DF H 02H PC Card ATA with Vpp required for media modification operations only.
DF H 04H PC Card ATA with Vpp required for all media access.
DF H 08H PC Card ATA with Vpp required continuously.
Volume 9
XIP Specification
PCMCIA
JEIDA
+1-408-433-9558 (Fax) IMPORTANT:
+81-3-3433-1923 PCMCIA
INFRINGEMENT,
YOU ÒAS IS.Ó

XIP SPECIFICATION
CONTENTS
1. Introduction ___________________________________________ 1
1.1 Purpose................................................................................................................................1
1.2 Scope....................................................................................................................................1
1.4 Data Sizes............................................................................................................................2
2. Overview ______________________________________________ 3
2.1 SXIP, LXIP and EXIP...........................................................................................................3
2.1.1 Hardware support for EXIP ..................................................................................................................................................3
2.1.2 Hardware support for LXIP ..................................................................................................................................................3
2.1.3 Hardware support for SXIP...................................................................................................................................................3
3. XIP Partitions __________________________________________ 5

3.1 XIP Partition Identification .................................................................................................5
3.2 XIP Partition Structure........................................................................................................5
3.2.1 XIP Partition Header Structure.............................................................................................................................................5
3.2.2 XIP Directory Structure ...........................................................................................................................................................6
4. XIP Device Driver Architecture__________________________ 11

4.1 Migration Path of Drivers..................................................................................................11
4.2 Sharing the Hardware Interface Between Device Drivers.................................................11
4.2.1 Device Driver Load Order...................................................................................................................................................1 1
4.3 XIP Loader.........................................................................................................................12

4.4 XIP IOCTL References.......................................................................................................12
4.5 XIP Driver Chain................................................................................................................12
5. XIP Applications Programming Interface _________________ 13

5.1 XIP API Calling Interface..................................................................................................13
5.1.1 Initializing the XIP Interface................................................................................................................................................1 3
5.1.2 Calling the XIP API..................................................................................................................................................................1 3
5.2 XIP API Functions.............................................................................................................13

5.2.1 Get XIP Version (Common)..................................................................................................................................................1 5
5.2.2 Get XIP Mappable Segments (SXIP, LXIP) ......................................................................................................................1 6
5.2.3 Get XIP Partition IDs (Common)........................................................................................................................................1 7
5.2.4 Get XIP Handle Range (Common) .....................................................................................................................................1 8
5.2.5 Map/Unmap an XIP Handle's Pages (SXIP, LXIP) ......................................................................................................1 9
5.2.6 Get XIP Mapping Context Size (Common) .....................................................................................................................2 1

CONTENTS
5.2.7 Get XIP Mapping Context (Common)...............................................................................................................................2 2

5.2.8 Set XIP Mapping Context (Common)................................................................................................................................2 3
5.2.9 Search for XIP Directory Entry (Common) ....................................................................................................................2 4
5.2.10 Search for full XIP Directory (Common) ......................................................................................................................2 5
5.2.11 Get First XIP Directory Entry (Common).....................................................................................................................2 6
5.2.12 Get Next XIP Directory Entry (Common).....................................................................................................................2 7
5.2.13 Add XIP Directory Entry (Write)....................................................................................................................................2 8
5.2.14 Copy XIP Page (Write).........................................................................................................................................................2 9
5.2.15 Delete XIP Directory Entry (Write).................................................................................................................................3 0
5.2.16 Erase XIP Partition (Write)................................................................................................................................................3 1
5.2.17 Close XIP Directory Entry (Write) ..................................................................................................................................3 2
5.2.18 Execute XIP Application (Common)...............................................................................................................................3 3
5.2.19 Map Extended Segment (EXIP)........................................................................................................................................3 4
5.2.20 Unmap Extended Segment (EXIP)..................................................................................................................................3 5
5.2.21 Get Partition ID from Address (Common)..................................................................................................................3 6
5.2.22 Get Slot Number (Common)..............................................................................................................................................3 7
5.2.23 Disable Partition ID (Common).......................................................................................................................................3 8
6. Appendices __________________________________________ 39
6.1 XIP Equate Values.............................................................................................................39
6.1.1 Summary of XIP Function Codes .......................................................................................................................................3 9
6.1.2 Summary of XIP Status Codes ............................................................................................................................................4 0
6.2 DOS Operating System Binding .......................................................................................41

6.2.1 Introduction...............................................................................................................................................................................4 1
6.2.1.1 Related Documents ..................................................................................................................................................4 1
6.2.1.2 Data Sizes....................................................................................................................................................................4 1
6.2.1.3 Included Code............................................................................................................................................................4 1
6.2.2 XIP Loader and Execution ...................................................................................................................................................4 1
6.2.2.1 Termination of XIP Execution..............................................................................................................................4 1
6.2.2.2 SXIP Execution...........................................................................................................................................................4 2
6.2.2.3 SXIP Image Format ..................................................................................................................................................4 2
6.2.2.4 LXIP Execution ..........................................................................................................................................................4 2
6.2.2.5 LXIP Image format...................................................................................................................................................4 2
6.2.3 XIP API Details .........................................................................................................................................................................4 3
6.2.3.1 Get XIP Version (Common)...................................................................................................................................4 3
6.2.3.2 Get XIP Mappable Segments (LXIP)...................................................................................................................4 3
6.2.3.3 Get XIP Partition IDs (Common).........................................................................................................................4 3
6.2.3.4 Get XIP Handle Range (Common) ......................................................................................................................4 3
6.2.3.5 Map/Unmap an XIP Handle's Pages (LXIP)...................................................................................................4 4
6.2.3.6 Get XIP Mapping Context Size (Common) ......................................................................................................4 4
6.2.3.7 Get XIP Mapping Context (Common)................................................................................................................4 4
6.2.3.8 Set XIP Mapping Context (Common).................................................................................................................4 4
6.2.3.9 Search for XIP Directory Entry (Common) .....................................................................................................4 4
6.2.3.10 Get First XIP Directory Entry (Common)......................................................................................................4 5
6.2.3.11 Get Next XIP Directory Entry (Common)......................................................................................................4 5
XIP SPECIFICATION
6.2.3.12 Add XIP Directory Entry (Write).....................................................................................................................4 5

6.2.3.13 Copy XIP Page (Write) ..........................................................................................................................................4 5
6.2.3.14 char_buffer DS:SI Delete XIP Directory Entry (Write) .............................................................................4 6
6.2.3.15 Erase XIP Partition (Write).................................................................................................................................4 6
6.2.3.16 Close XIP Directory Entry (Write) ...................................................................................................................4 6
6.2.3.17 Map Extended Segment (EXIP).........................................................................................................................4 6
6.2.3.18 Unmap Extended Segment (EXIP) ...................................................................................................................4 6
6.2.3.19 Get Partition ID from Address (Common)...................................................................................................4 7
6.2.3.20 Get Slot Number (Common)...............................................................................................................................4 7
6.2.3.21 Disable Partition ID (Common)........................................................................................................................4 7
6.2.3.22 Execute XIP Application (Common)................................................................................................................4 7
6.2.3.23 Search for full XIP Directory Entry (Common)...........................................................................................4 7
6.2.3.24 Secondary Map/Unmap an XIP Handle's Pages (LXIP)..........................................................................4 8
6.2.3.25 Secondary Set XIP Mapping Context (Common)........................................................................................4 8
6.2.3.26 Secondary Search for XIP Directory Entry (Common) ............................................................................4 8
6.2.3.27 Secondary Add XIP Directory Entry (Write)..............................................................................................4 8
6.2.3.28 Secondary Copy XIP Page (Write)....................................................................................................................4 9
6.2.3.29 Delete XIP Directory Entry (Write)..................................................................................................................4 9
6.2.4 XIP Applications Programming Interface ......................................................................................................................5 0
6.2.4.1 Initializing the XIP API...........................................................................................................................................5 0
6.2.5 IOCTL Read (Get Current XIP API Entry Point)...........................................................................................................5 3
6.2.6 IOCTL Write (Set New XIP API Entry Point).................................................................................................................5 5
6.2.7 Chaining into the XIP API .....................................................................................................................................................5 7
6.2.8 Example of XIP API Use ........................................................................................................................................................5 9
XIP SPECIFICATION
TABLES
Table 6-1: XIP API Functions............................................................................................39
Table 6-2: XIP Status Codes .............................................................................................40

XIP SPECIFICATION
1.1 Purpose
In order to achieve savings of both RAM and ROM1, it is beneficial to directly execute applications
from ROM, without loading the image of the application into RAM prior to execution. A number of
machines currently offer this capability; however, there is no application-level portability between
these machines. This specification outlines a standard method, hereinafter referred to as eXecute In
Place, or XIP, of achieving this.
This document shall describe the Metaformat tuples, data structures, driver architecture, and the
Application Programming Interface (API) for eXecute In Place (XIP), as well as the architecture and
load format of an XIP-compliant application.
1.2 Scope
This document is intended to provide enough information for software developers to design and
implement XIP applications. It is also intended to provide sufficient information to allow an
implementor to create an XIP implementation.

This section identifies documents related to the eXecute In Place Interface Specification. Information
available in the following documents is generally not duplicated within this document.
Volume 11: PC Card Host Systems Specification
PCMCIA Card Services Interface Specification, Release 2.00, November 1992, PCMCIA
PCMCIA Socket Services Interface Specification, Release 1.01, September 1991, PCMCIA
PCMCIA Socket Services Interface Specification, Release 2.00, November 1992, PCMCIA
Ê1 It will be seen that the physical media an XIP application is built into generally has little impact upon the application.
Thus, for the purposes ofthis document, unless otherwise noted, the term ROM will apply also to Flash memory, EEP ROM,
etc.
INTRODUCTION
1.4 Data Sizes

The Version 1.0 XIP Specification was oriented primarily towards X86 architectures. The data
structures in this document are an evolution of those specified in that earlier document. As such, the
data sizes in the table below hold true within data structures. Data organization is "Little Endian."
Data type Bits

char 8
short int 8
int 16
long int 32
Data sizes for passed parameters within API calls are functions of the particular Operating System
Binding. In general, they tend to follow those in the above table.
XIP SPECIFICATION
2. O V E R V IE W
Unlike other sections of the PC Card Standard, this specification is, to a very large extent
dependent upon the host processor class, and upon the host operating system. Thus, much of the
detail to be expected in a document such as this must be relegated to application notes within
appendices, each specific to a particular operating system and processor chip class.
2.1 SXIP, LXIP and EXIP

Three types of XIP support are defined in order to support three real-world architectures: LXIP,
SXIP, and EXIP.
LXIP is for systems where demand-paging is required (i.e., pages not in memory must be explicitly
paged in by software at some level). LXIP Applications are structured to operate in a 16KB paged-
execution environment.
SXIP (Simple XIP) is for those systems which have only very limited paging mechanisms. SXIP
applications are comprised of an execution image of at most 64K of code and/or read-only data, and
are monolithic in nature. These applications do no overlaying of any sort. The SXIP concept has
been added to this revision to allow execution of XIP on as wide a variety of systems as possible.
EXIP is for those systems with very large address spaces or with implicit paging (i.e., pages not in
memory when accessed are placed into memory without intervention at a software level). EXIP
applications are structured to operate in an environment where no paging is necessary, similar to an
Intel 80386 extended-addressing-mode-execution environment.
These differences have no effect on the Metaformat, XIP data structures, or driver architecture. They
are noticeable in the API described later in this document. There is significant difference in the
hardware support required, and in the way applications are structured in the respective
environments. There may also be a significant impact within particular Operating System Bindings.
2.1.1 Hardware support for EXIP

Hardware support for Card Services in protected mode is necessary and sufficient for EXIP support.
2.1.2 Hardware support for LXIP

Hardware support for Card Services in real mode is necessary and sufficient for LXIP support.In
addition to support for real mode Card Services, an XIP-compliant platform must provide, at
minimum, one contiguous window of at least 64K. This window must be capable of partitioning into
4 16K pages, each of which must be independently mappable. Additional windows and pages may
be utilized if provided.
2.1.3 Hardware support for SXIP

Hardware support for Card Services in real mode is necessary and sufficient for SXIP support.
XIP SPECIFICATION
3 . XI P PAR T IT ION S
XIP applications are stored, by definition, on XIP partitions. XIP partitions are used only to store XIP
applications, and are entirely distinct from any other partitions, such as FAT or Flash file-system
partitions. In order to ensure that XIP applications may be properly mapped into system memory,
any XIP partition must begin on a 16K boundary, relative to the start of the card. An XIP partition is
required to be an integral number of pages long, and each page of an XIP partition is also required
to be 16K in length. If an XIP partition is not aligned on erase block or device boundaries, data
outside of the XIP partition may be destroyed if the XIP_ERASE_PARTITION function is invoked.
3.1 XIP Partition Identification

There are two tuples relevant to XIP. The "Format Tuple (CISTPL_FORMAT)" defines the data-
recording format for a card as well as the location and size of the associated memory region on the
card. The "Organization Tuple (CISTPL_ORG)" defines the organization of the data in a specific
partition. This tuple must follow a format tuple to be associated with it.
The Format Tuple for an XIP partition should have a TPLFMT_TYPE field value of
TPLFMTTYPE_MEM. An error detection method may be specified. The TPLFMT_OFFSET and
TPLFMT_NBYTES fields define the location and size of the XIP partition. The TPLFMT_FLAGS
should be set to 0. The TPLFMT_ADDRESS field is not used, and should be set to 0.
The Organization Tuple for an XIP partition should have a TPLORG_TYPE field value of
TPLORGTYPE_ROMCODE. This is somewhat misleading, as it suggests that the XIP partition is
read-only; however, writing to areas of the partition is allowed when the card technology supports
write access. The TPLORG_DESC field should have an appropriate value; the only value currently
defined is "DOS_XIP" for DOS-compatible XIP partitions.
3.2 XIP Partition Structure

Within the XIP partition, a format for the XIP application images needs to be defined in order that
the XIP manager can locate the XIP images it is to manage and map. This format is comprised of an
XIP header and an XIP Directory. Based on the size of the data structure used to describe each entry
of the XIP directory, and its offset within the first 16K block of the partition, up to 511 XIP
applications could reside within a single XIP partition. The XIP directory is not required to be 16K
in size, but it must be located wholly within the first 16K block.
3.2.1 XIP Partition Header Structure

An XIP header is located at the beginning of the XIP partition. The header is structured as:
struct XIP_partition_header {
int max_directory_entries;
long int xip_serial_number;
int data_structure_version_number;
char xip_header_reserved[24];
}
The max_directory_entries field contains the maximum number of possible entries within the XIP
directory. The size of the directory structure may be inferred from this.
XIP PARTITIONS
The XIP_serial_number shall be set on creation of an XIP partition only. It is analogous to a DOS
volume serial number.
The data_structure_version_number field shall be set to 0002H for this release.
All bytes within the xip_header_reserved array shall be set to 0FFH.
The total length of the directory for an XIP partition can be determined by:
directory length = (max_directory_entries) * 32 bytes.
The XIP partition is divided into an integer multiple of 16K fixed-length pages, where each 16K
page is aligned on 16K boundaries. Each 16K region is assigned a page number. The relationship
between page n and the byte offsets, relative to the beginning of an n-byte-long XIP partition, is
illustrated below.
16K Page Byte Offset relative to the Page Usage

Number Beginning of an XIP
partition
0 00000h...03FFFh XIP Header and Directory
Structure
1 04000h...07FFFh XIP Applications
2 08000h...0BFFFh " "
3 0C000h...0FFFFh " "
4 10000h...13FFFh " "
. . " "
. . " "
. . " "
((n/4000h)-1) (n-4000h)...(n-1) " "
3.2.2 XIP Directory Structure

XIP directory entries are stored as an array of fixed-length structures. The layout of an XIP directory
entry is similar to that of a DOS FAT-file-system-directory entry.
The XIP driver uses the XIP directory to determine the number of applications which are present,
their names and extensions, time and date of creation, and their locations within the partition. The
XIP directory starts immediately after the XIP header.
An XIP application occupies some number of contiguous 16KB pages. All XIP application entries are
allocated from the beginning of the XIP directory, i.e., all directory entries are allocated
contiguously and all XIP pages are allocated from the beginning of the available XIP memory pages
in the partition.
An XIP driver can determine the next unallocated memory page and directory entry by
sequentially searching the XIP directory and finding the first entry that has never been allocated
(i.e., XIP_STATUS = 0xxxxx111b). This directory entry is available for allocation, and the previous
directory entry contains the information necessary to determine the next available XIP memory
page.
The XIP driver may need to read the directory at driver initialization time and whenever a card
with an XIP partition is installed in a slot in order to determine any information it needs to operate
properly. The XIP driver will also read the "directory" at driver run time in order to support XIP
functions that access the XIP directory. If the type of memory making up the XIP partition permits
it, the XIP driver may be able to add new XIP applications into the partition. ROM XIP partitions
XIP SPECIFICATION
cannot support adding new XIP applications; Flash or EEPROM XIP partitions could support this
functionality.
Byte Name
0...7 XIP_NAME
8...10 XIP_EXT
11 XIP_STATUS
12...13 XIP_APP_BEGIN
14...15 XIP_APP_OFFSET
16 XIP_APP_TYPE
17 XIP_VERSION_REQD
18..20 XIP_RESERVED
21 XIP_HEADER_CKSUM
22...23 XIP_CREATION_TIME
24...25 XIP_CREATION_DATE
26...27 XIP_FIRST_APP_PAGE
28...31 XIP_SIZE
Bytes 0-7 (XIP_NAME):

Specifies an ASCII string that is the primary name of this XIP application. The format of this name,
in combination with the next field, XIP_EXT, is the same as the DOS primary-file name: 8 characters
followed by three characters. If the name is less than eight (8) characters, it must be padded on the
right with blanks (20h).
Bytes 8-10 (XIP_EXT):
Specifies an ASCII string that is the name extension of this XIP application. The format of this name
is the same as the DOS file-name extension: 0 to 3 characters. If the extension is less than three (3)
characters it must be padded on the right with blanks (20h).
Byte 11 (XIP_STATUS):
Specifies the status of this XIP directory entry (see table below). Values for the status bits are chosen
so that an XIP directory may be updated in media like flash memory, without first erasing and then
re-recording it. Flash memory has unique constraints placed on how bit values in it may change.
If XIP_STATUS has a value of 0FFh, the previous XIP directory entry was the last one in the XIP
partition. New entries in the XIP directory may be made at this point in the directory. If the first
byte in the first directory entry has a value of 0FFh, the XIP directory is completely empty. If the
XIP directory is completely empty, the first page occupied by the directory may be partially
available, the last page may be partially available, and all remaining pages of the partition are
available for allocation. Whether there are any partially-available pages is determined by the total
size and location of the partition, and the size of the XIP directory. The size and physical location of
the XIP partition within the card's physical-address space, is determined by the tuple data
structures.
If XIP_STATUS indicates a deleted entry, the XIP_FIRST_APP_PAGE and XIP_SIZE are still
necessary for managing which pages may be allocated to new XIP applications that are being
copied into this partition. Also note that the XIP pages that have been deleted are not reusable
because they have not been erased. When an entry is marked deleted, the name and extension
fields of the directory entry must be ignored, since they are not required to be cleared.
XIP PARTITIONS
If bits 0...2 of the XIP_STATUS are set to 001, than bits 3 and 4 will indicate the structure of the
application. A value of 10 within bits 3 and 4 is invalid.
Bit Definition
0...2 XIP Allocation Status:
111 XIP Directory entry is free to be used to store the next XIP directory entry. The previous XIP
directory entry is the last valid entry in they XIP directory.
011 XIP directory entry and the contents of its associated XIP application are in the process of being
created. Since this XIP directory entry has not yet been completely processed, the application may not
be loaded, as the XIP application code has not been completely copied. However, the
XIP_FIRST_APP_PAGE and XIP_SIZE fields are valid for this directory entry. An XIP utility program
must "close" the XIP directory entry before the application may be loaded.
001 XIP directory entry is allocated and contains a valid XIP application.
000 XIP directory entry had been allocated, but is now deleted. It no longer contains a valid XIP
application. The fields XIP_FIRST_APP_PAGE and XIP_SIZE contain valid data that must be sued when
searching for the next free page within the XIP partition.
3...4 LXIP/EXIP Application

00 The application is structured for LXIP
01 The application is structured for EXIP
11 The application is structured for SXIP
5...7 Reserved for future use. Must be all ones.
Bytes 12-13 (XIP_APP_BEGIN):

Specifies the offset in the first page for the application's entry point. The offset shall be located on a
16-byte boundary.
Bytes 14-15 (XIP_APP_OFFSET):
Specifies the offset in the first page of the application for the application's first byte. The offset shall
be located on a 16-byte boundary.
Byte 16 (XIP_APP_TYPE):
Specifies the XIP application type. A list of application types are to be found in the table below;
however, future operating system bindings will cause this list to expand.
XIP_APP_TYPE Name Description

0 XIP_TYPE_NON_EXEC Non-executable. Examples of XIP Type 0 include pseudo-
volume labels, XIP V1.00 applications, etc.
1 XIP_TYPE_SXIP_DOS Simple executable image for execution under DOS. An XIP

Type 1 application does no overlaying, and can run under
an SXIP driver.
2 XIP_TYPE_V2_OVERLAY_D Overlaid executable image for execution under DOS. An
OS XIP Type 2 application is suitable for overlaid execution
under DOS. Executable image formats are specified in the
appropriate Operating System Binding Appendix.
XIP SPECIFICATION
Byte 17 (XIP_VERSION_REQD):
Specifies the version of XIP API Services required for execution.
Bytes 18-20 (XIP_RESERVED):
These bytes are reserved for future use. All reserved bytes must be set to a value of 0FFh.
Byte 21 (XIP_DIREC_CKSUM):
Specifies an 8-bit additive checksum of the 32 bytes of this XIP directory entry, exclusive of this
byte. Note that, in order to maintain compatibility with XIP Version 1.0, especially in cases where
bytes 16 or 17 are 0FFh, 0FFh must be considered a valid entry, even when a different value is
reached via calculation.
Bytes 22-23 (XIP_CREATION_TIME):
Specifies the time that this XIP directory entry was created, or added, to the XIP partition. For media
such as flash memory, it is not possible to "update" an XIP directory entry without first erasing the
entire XIP partition. Therefore, the time only refers to the time that the XIP application was added to
the XIP directory. The format of the create time is DOS compatible and is described in the following
table.
Bytes 24-25 (XIP_CREATION_DATE):
Specifies the date that this XIP directory entry was created, or added, to the XIP partition. For media
such as flash memory, it is not possible to "update" an XIP directory entry without first erasing the
entire XIP partition. Therefore, the date only refers to the time that the XIP application was added to
the XIP directory. The format of the create date is DOS compatible and is described in the following
table.
Bits Definition
0...4 Day of month (1-31)
5...8 Month (1-12)
9...15 Year (relative to 1980)
Bytes 26-27 (XIP_FIRST_APP_PAGE):

Specifies the first 16K page within an XIP partition that is allocated to this XIP application. Pages are
allocated contiguously within an XIP partition. There is nothing which precludes the possibility of
having multiple XIP applications within a single page.
Bytes 28-31 (XIP_SIZE):
Specifies the size, in bytes, of this XIP application. This size must include any padding required to
achieve any application-specific alignment. The size may be zero to allow an entry to simply be a
"label."
XIP SPECIFICATION
4. XI P DE V IC E DR IV E R AR C H IT E C T U R E
XIP functions are to be provided by a high-level device driver. The intent of this specification is that
this driver be reliant upon Card Services for lower level functionality. Card Services is in turn
dependent upon Socket Services. The XIP device driver simply manages the data in the XIP
partition, and provides the required services. Hardware-related services, such as those needed to
manipulate mapping hardware, are intended to be provided by Card Services. However, especially
for systems with limited resources, there is no intent to prohibit an XIP driver which does not rest
upon any underlying level of software.
XIP Device Drivers must be able to provide all functionality listed below as Common, and are
assured of being able to execute SXIP applications. Additionally, they may provide services listed
below as elements of the Write, LXIP, or EXIP functionality sets.
4.1 Migration Path of Drivers

Implementations of this architecture are expected to tend to migrate into BIOS functions over time.
The layered architecture will initially be implemented as loadable drivers. Some manufacturers
may initially provide all three drivers (XIP, Card Services, and Socket Services), or combinations of
two of the three, as a single unit. In any case, the location and partitioning of the drivers should
have no impact on XIP applications, as the applications should be unable to determine the location
and/or type (loaded or BIOS-resident) of the drivers, nor will the applications be able to distinguish
between a joint driver and completely separate drivers.
4.2 Sharing the Hardware Interface Between Device Drivers

It is possible that other device drivers or embedded software, distinct from the XIP driver, will need
to access the memory-mapping-interface hardware that maps memory on the card into the system's
address space. It should be obvious that such a memory-mapping interface is required for XIP.
However, a memory-mapping interface would be perfectly acceptable for a disk device-driver as
well. The same hardware interface could be used for XIP driver, a DOS FAT-file-system driver, and
a DOS Flash-file-system driver.
Consequently, it is very important for system designers to provide the ability to read, as well as
write, the state of their memory-mapping hardware. Write-only memory-mapping-hardware
registers are not acceptable. The reason for this requirement is that a disk-device driver, for
instance, would necessarily have to save and restore the state of the memory-mapping hardware,
before and after a disk access, as the mapping hardware may be in use by an XIP driver and XIP
application, as well as other drivers using the memory-mapping resource.
Note: An XIP driver shall not do saves/restores of its mapping hardware between
XIP function calls!
The virtualization that Card Services provides should alleviate much of the concern that multiple
and separate device drivers accessing the same hardware might cause.
4.2.1 Device Driver Load Order

The XIP and Card Services device drivers are to be loaded like any other device driver during
initial start-up processing.
XIP DEVICE DRIVER ARCHITECTURE
For the XIP drivers, any Socket Services and Card Services drivers are to be loaded before the XIP
driver. During initialization of the XIP device driver, information about the system's mapping
capabilities, which can only be provided by these drivers, is required. There is no requirement that
Memory Technology Drivers be loaded before the XIP driver.
4.3 XIP Loader

The XIP loader is responsible for preparing the system for the execution of an XIP application. The
function of the XIP loader is to look up, map, and start the XIP application execution. Naturally, the
XIP loader will perform different functions based on the XIP_APPLICATION_TYPE of the
application, as well as the operating system environment.
4.4 XIP IOCTL References

The XIP device driver requires that applications use general I/O Control calls (IOCTL) to get and/or
set the entry point for the XIP device driver. This allows an arbitrary chain of applications to
monitor or patch the device driver. The entry point of the XIP device driver is actually the
procedure that an application calls whenever it needs to call the XIP API (Application Programming
Interface). This being the case, it is required that all XIP device drivers support IOCTL open, read,
and write, and close calls, if the operating system supports such. No other IOCTL calls should be
assumed.
4.5 XIP Driver Chain

In the case that the XIP Device Driver does not supply a particular functionality set, additional
device drivers may chain in to provide such sets. An application should not be required to
differentiate in any way which driver provides which services; in fact, the combination of XIP
device drivers should appear monolithic to the application.
For a device driver to chain in, it must first determine the existing entry point in the same manner
as any client. Having saved the current XIP entry point, it may perform an IOCTL write to set up
the new entry point.
When a chained device driver is called, it should inspect the function parameters to determine if it
needs to handle the call. If not, it should pass control to the older XIP device driver.
XIP SPECIFICATION
5 . X I P A P P L I C AT I O N S P R O G R A M M I N G
I N T E R F AC E
In order for an application to use the XIP device driver, the device driver must obviously be present
and installed, and the XIP application must be able to determine both the presence and entry point
of the driver. Furthermore, additional device drivers should be allowed to chain into the current
driver to provide functionality not granted by the original driver. The specific mechanics of
interacting with the XIP device driver are, of course, dependent on the Operating System Binding;
however, the following generalities should be observed.
5.1 XIP API Calling Interface

The XIP device driver uses a procedure-call interface rather than a software-interrupt interface. The
callback interface, being private, means that other software, not directly related to the operation of
the XIP device, will not be chained into the execution path. The benefit of this interface is that there
are no software interrupt-chaining-compatibility problems.
Whether passed arguments are register-based or stack-based is a detail of the Operating System
Binding.
5.1.1 Initializing the XIP Interface

In order for an XIP client to use the XIP device driver, the client needs to know the entry point for
XIP services within the device driver. Generally, a client should request that the operating system
open a device with the name "XIP$$$$$.Ó The client should then request that the operating system
read the XIP entry point from that device, and then close that device. If any errors occur in the
course of the above steps, it will probably be necessary to install or re-install the XIP device driver
before further processing.
5.1.2 Calling the XIP API

Having read the entry point of the XIP device driver, calling the XIP API from a client involves a
simple two-step process. First, load the entry point previously read from the XIP device. Second, call
the address pointed to by that address. This secondarily indirect address is the XIP API entry point.
Operating System Bindings should probably contain examples to make this process clear.
The second level of indirection adds flexibility in being able to both chain into and unchain from an
XIP device driver. Furthermore, all future clients are immediately affected by changes in the device
chain, with no special effort on their part.
5.2 XIP API Functions

The following functions comprise the entire set of XIP functions that are required to be present
within a fully compliant XIP version 1.10 driver.
Each function is listed below in the following form:
XIP (*FUNCTION, parameters)
XIP APPLICATIONS PROGRAMMING INTERFACE
The details of how the parameters map to the calling sequence (i.e., parameter order, register based
parameters, et. al.) is an Operating System Binding and implementation issue.
Each function implicitly returns it's result as a binary success(true)/fail(false) indicator. Other return
values, and the meanings thereof, hinge on the function result. If the function fails (returns FALSE),
the FUNCTION returns a status code, and the other variables are undefined, unless otherwise
noted. If the function is successful (return TRUE), the FUNCTION variable is undefined.
Also note that variables may "overlay" one another; i.e., a variable with one meaning on input may
have another meaning on output, or a variable may have different meanings or structure
dependent upon the contents of other variables.
XIP SPECIFICATION
5.2.1 Get XIP Version (Common)

XIP (*function, *version, *functionality)
Purpose:
This function returns the version of the XIP driver installed in the system, as well as a bit flag
indicating the capabilities of the system. An application uses this function to determine if the set of
XIP functions it requires are supported by this XIP driver.
Calling Parameters:
function XIP_GET_VERSION
Results if successful:
version Contains the XIP driver's version number in binary coded decimal (BCD)
format. The upper four bits contain the integer digit of the version number.
The lower four bits contain the fractional digit of version number. For
example, version 1.10 is represented as 010Ah.
When checking for a version number, an application should check for a
version number or greater. Vendors may use the fractional digit to indicate
enhancements or corrections to their XIP drivers. Therefore, to allow for
future versions of XIP drivers, an application shall not depend on an exact
version number.
functionality A bitfield indicating which XIP functionality set(s) are supported by this driver.
Values are as in the table below.
Bits Description
7...3 Reserved (Set to 0)
2 Supports Write functionality set (if 1)
1 Supports EXIP functionality set (if 1)
0 Supports LXIP functionality set (if 1)
Status Codes:
XIP_STAT_UNKNOWN_ERROR
5.2.2 Get XIP Mappable Segments (SXIP, LXIP)

XIP (*function, *XIP_mappable_array, *mappable_array_length)
Purpose:
This function returns an array of addresses for each mappable XIP page in a system. The array is
sorted in ascending segment order.
Calling Parameters:
function XIP_GET_MAP_SEGS
XIP_mappable_array An un-initialized array. The first element of the array gives the acceptable
length of the array, not including the first element (thus a first word of 0,
although legal, would cause no change to the contents of this array). The
remainder of the array will be filled in by the function.
XIP_mappable_array The array will have been filled in with the segment address of each mappable
page in the system, up to the number of entries allowed in the array. The
array will be sorted in ascending order, with the length of the array first, the
lowest-valued page first, etc. SXIP environments will have only one entry in
the array.
mappable_array_length Actual number of mappable pages in the system. If an application wished to
be precise, it could call this function with *XIP_mappable_array set to 0,
allocate mappable_array_length+1 words of memory, then call this function
again with XIP_mappable_array set to the newly allocated memory, and
*XIP_mappable_array set to mappable_array_length.
Status codes
XIP SPECIFICATION
5.2.3 Get XIP Partition IDs (Common)

XIP (*function, partition_ids_array, *partition_array_length)
Purpose:
This function returns an array of XIP partition IDs currently accessible in the system. XIP partition
IDs are tokens used to uniquely identify each XIP partition. Token values are implementation
specific, and are valid only after this function is called.
Partition IDs are assigned at initialization time by the XIP driver. These IDs are valid only during a
given system boot. Thus, the ID for a specific partition may change from boot to boot. Normally, IDs
will not be reassigned to a different partition once they have been assigned to a specific partition,
however, the Disable Partition ID function can be used to allow a partition ID to be reassigned.
This function will not return a partition ID that has been disabled. However, it may return new
partition IDs that correspond to XIP partitions on a newly inserted card.
Calling Parameters:
function XIP_GET_PARTITIONS
partition_ids_array An un-initialized array. The first element of the array gives the acceptable
length of the array, not including the first element (thus a first word of 0,
although legal, would cause no change to the contents of this array). The
remainder of the array will be filled in by the function.
partition_ids_array The array will have been filled in with the partition IDs of each XIP partition
present in the system. No order to the resulting array may be assumed, other
than that the length of the array will be first.
partition_array_length Actual number of partitions in the system. If an application wished to be
precise, it could determine the length of the full array, and then allocate and fill
the array, analogous to the method given in Get XIP Mappable Segments.
Status codes
5.2.4 Get XIP Handle Range (Common)

XIP (*function, *XIP_first_handle, *XIP_last_handle, *total_handles)
Purpose:
This function returns the range of handle values that the XIP driver manages. The maximum range
of handle values is a detail of any particular XIP Operating System Binding.
The XIP driver assigns a unique handle value, in the specified range, to every XIP application
present in the XIP directory. An XIP application uses a handle as a parameter whenever it calls the
XIP driver to perform a map, unmap, or copy function.
Calling Parameters:
function XIP_GET_HANDLE_RANGE
XIP_first_handle This is the value of the first handle managed by the XIP driver. Shall be in the
range 8000H through 8FFFh, inclusive.
XIP_last_handle This is the value of the last handle managed by the XIP driver. This value
must obviously be greater than that value returned as XIP_first_handle. Shall
be in the range 8000H through 8FFFH, inclusive.
total_handles The maximum number of handles that this XIP driver is capable of
supporting.
Status Codes:
XIP SPECIFICATION
5.2.5 Map/Unmap an XIP Handle's Pages (SXIP, LXIP)

XIP (*function, handle, partition, *map_count, seg_map_array)
Purpose:
This function maps or unmaps one, several, all, or none of the logical pages associated with a
handle into as many mappable segments as the system supports. Both mapping and unmapping
pages may be done in the same invocation. Mapping or unmapping no pages is not considered an
error. If a request to map or unmap zero pages is made, nothing is done and no error is returned.
The segment map array passed to this function does not have to have any special order with respect
to mappable_segment elements.
The function should allow mapping a specific logical page at more than one mappable segment
address, provided that the hardware supports this. This same "feature" is also a part of the LIM
specification.
Calling Parameters:
function XIP_MAP_HANDLE
handle Handle of the XIP application owning the pages to be mapped in. This handle
is obtained through any of the search functions listed below.
partition Contains the ID of the partition containing the indicated XIP application
map_count Contains the number of entries in the seg_map_array. This argument is
ignored and assumed 1 in SXIP environments.
seg_map_array An array of seg_map structures, defined as:
struct seg_map_struct {
int log_page_number ;
int mappable_segment ;
};
log_page_number contains the number of the logical page to be mapped.
Logical pages are numbered zero relative with respect to the beginning of the
XIP application with which they are associated. Therefore, the number for a
logical page can range from zero to one less than the number of logical pages
allocated to the handle.
If the logical page number is set to -1, the associated mappable_segment is
unmapped. Unmapping a page makes it inaccessible.
mappable_segment contains the segment address within the system
memory address space at which the logical page is to be mapped. This
segment address must correspond exactly to a mappable segment address,
as returned via the XIP_GET_MAP_SEGS function.
Results:
map_count Contains the number of entries actually mapped, regardless of the function
status return. If the function fails, this number of pages has been mapped, and
may need to be unmapped by the application. The XIP driver will map the
pages sequentially, so if only n pages have been mapped, it may be assumed
that the first n pages have been mapped.
Status Codes:
XIP_STAT_HANDLE_NFOUND The specified XIP handle could not be found, and is probably corrupt. No
pages have been mapped.
XIP_STAT_BAD_PAGE One or more of the logical pages to be mapped is out of the range of logical
pages allocated to the given XIP handle.
XIP_STAT_BAD_SEGMENT One or more of the segment addresses is invalid, or, the map_count specified
exceeds the number of mappable segments in the system.
XIP_STAT_BAD_PARTITION The partition specified does not exist.
XIP_STAT_PAGE_MAPPED One or more of the logical pages specified is already mapped at a mappable
segment. The new logical page specified is not mapped.
XIP_STAT_CARD_CHANGED
XIP SPECIFICATION
5.2.6 Get XIP Mapping Context Size (Common)

XIP (*function, *map_context_size)
Purpose:
The Get XIP Mapping Context Size function returns the storage requirements for the array passed to
the XIP_GET_CONTEXT and XIP_SET_CONTEXT functions. The size returned is implementation-
dependent, but it is explicitly fixed (i.e., the return value of this function will never change).
Clearly, this implies that supplemental XIP device drivers should not intercept this function, or the
XIP_GET_CONTEXT and XIP_SET_CONTEXT functions.
Calling Parameters:
function XIP_GET_CONTEXT_SIZE
Results if Successful:
map_context_size Contains the size of the block that will be transferred to or from the memory
area which an application will supply to the XIP_SET_CONTEXT or
XIP_GET_CONTEXT functions.
Status Codes:
5.2.7 Get XIP Mapping Context (Common)

XIP (*function, *xip_context)
Purpose:
This function saves the mapping context to the specified buffer. The format and content of the
resultant buffer is strictly implementation dependent.
Calling Parameters:
function XIP_GET_CONTEXT
xip_context A buffer of at least the size given by the XIP_GET_CONTEXT_SIZE function.
xip_context The buffer contains the state of the XIP mapping hardware. It also contains
any additional information necessary to restore the XIP mapping hardware to
the current state when this function is invoked. The content and size of this
information is vendor specific.
Status Codes:
XIP SPECIFICATION
5.2.8 Set XIP Mapping Context (Common)

Purpose:
This function restores the physical and logical mapping context for all XIP mappable regions to the
state it was in when the specified buffer was filled in via the XIP_GET_CONTEXT function. The
format and content of the buffer is strictly implementation dependent.
Calling Parameters:
function XIP_SET_CONTEXT
xip_context A buffer that has previously been passed to the XIP_GET_CONTEXT
function. The buffer is of at least the size given by the
XIP_GET_CONTEXT_SIZE function.
none
Status Codes:
XIP_STAT_BAD_MAP_ARRAY The contents of the xip_context buffer have been corrupted, or an invalid
pointer has been passed to the function.
5.2.9 Search for XIP Directory Entry (Common)

XIP (*function, partition, *application_name, *handle, *page_count)
Purpose:
This function searches the XIP directory for a specific XIP application. If the name is found, the
function returns only the handle associated with the name and the number of logical pages allocated
to it.
The XIP handle returned by the XIP driver always specifies the same XIP application within the XIP
partition. For example, if you searched the XIP directory six times for an existing XIP application
named "WORDPROC.XIP", the XIP driver would return the same handle value each time because
the position of the XIP application within the XIP directory structure had not changed.
An XIP handle is somewhat analogous to an index into an array of fixed length structures. The
handle returned may be used by as many processes as need access to the XIP application.
Calling Parameters:
function XIP_SEARCH
partition The partition ID of the XIP directory to be searched
application_name The name of the application to be searched for. The name must be in 8.3
format, i.e., an 8-letter name, followed by the 3 letter extension. If either the
name is shorter than 8 characters, or the extension is shorter than 3
characters, they must be padded with spaces on the right to the appropriate
size.
handle The value of the handle assigned to the specified XIP application.
page_count The number of logical pages allocated to the XIP application. This value can
be zero.
Status Codes:
XIP_STAT_APP_NOT_FOUND
XIP_STAT_BAD_APP_NAME
XIP_STAT_BAD_PARTITION
XIP SPECIFICATION
5.2.10 Search for full XIP Directory (Common)

XIP (*function, partition, *XIP_dir_entry, *handle, *page_count)
Purpose:
This function searches the XIP directory for a specific XIP application. If the name is found, the
function returns the full XIP directory information associated with the name, as well as the handle
and number of logical pages allocated to the application.
This function is very similar to the XIP_SEARCH function, save that it fills in the entire XIP
directory entry if the specified application is found.
Calling Parameters:
function XIP_SEARCH_FULL
partition The partition ID of the XIP directory to be searched
XIP_dir_entry A structure of the form:
struct xip_dir_entry_struct {
char xip_name[8];
char xip_ext[3];
short int xip_status;
int xip_app_begin;
int xip_app_offset;
short int xip_app_type;
short int xip_version_reqd;
char xip_reserved[3];
short int xip_header_cksum;
int xip_creation_time;
int xip_creation_date;
int xip_first_app_page;
long int xip_size;
}
The xip_name and xip_ext field must be filled in, and padded on the right with
spaces. All other fields will be ignored.
XIP_dir_entry The entire structure will be filled in with the appropriate values, copied from
the XIP directory.
page_count The number of logical pages allocated to the XIP application. This value may
be zero.
Status Codes:
XIP_STAT_UNKNOWN_ERRO
R
5.2.11 Get First XIP Directory Entry (Common)

Purpose:
This function returns the full XIP directory information associated with the first active entry in the
XIP directory in the specified partition, as well as the handle and number of logical pages for that
XIP application.
Calling Parameters
function XIP_SEARCH_FIRST
partition Contains the ID of the partition containing the XIP directory
XIP_dir_entry An XIP_dir_entry_struct structure. The structure need not be initialized
the XIP directory.
be zero.
Status Codes:
XIP SPECIFICATION
5.2.12 Get Next XIP Directory Entry (Common)

Purpose:
This function returns the full XIP directory information associated with the next (relative to the
given handle) active entry in the XIP directory in the specified partition, as well as the handle and
number of logical pages for that XIP application.
Calling Parameters
function XIP_SEARCH_NEXT
partition Contains the ID of the partition containing the XIP directory.
XIP_dir_entry An XIP_dir_entry_struct structure. The structure need not be initialized.
handle Contains the value of the handle returned from a XIP_SEARCH_FIRST or
XIP_SEARCH_NEXT function call. The XIP driver uses this handle value to
begin the search for the next active entry in the XIP directory.
the XIP directory.
handle The value of the handle assigned to the specified XIP application
be zero.
Status Codes:
XIP_STAT_HANDLE_NFOUND The handle passed to the function is invalid. The application has probably
corrupted the XIP handle previously obtained.
XIP_STAT_APP_NOT_FOUND No more active entries were found in the XIP directory.
5.2.13 Add XIP Directory Entry (Write)

XIP(*function, partition, *XIP_dir_entry, *handle)
Purpose:
This function allows one to create a new XIP directory entry, most probably in the process of adding
a new XIP application to the XIP partition. One would use this function to name the XIP application,
and allocate space for it within the XIP partition. One would subsequently map the allocated pages
into memory, and then copy the new XIP application into them.
Calling Parameters:
function XIP_ADD_ENTRY
partition Contains the ID of the partition containing the XIP directory.
XIP_dir_entry An XIP_dir_entry_struct structure. The structure must be initialized, with the
exception of the XIP_status field.
handle The value of the handle assigned to the newly added XIP application.
Status:
XIP_STAT_NO_HANDLES
XIP_STAT_NO_PAGES
XIP_STAT_NO_FREE_PAGES
XIP_STAT_NAME_EXISTS
XIP_STAT_NO_WRITE
XIP_STAT_NO_DIR_SPACE
XIP_STAT_COPY_ERROR
XIP_STAT_NO_WRITE_MEDIA
XIP SPECIFICATION
5.2.14 Copy XIP Page (Write)

XIP (*function, partition, logical_page_number, write_count, handle,
*char_buffer)
Purpose:
This function allows an application to copy data from a buffer into one page allocated to an XIP
application. The XIP driver should do the copying because the type of programmable memory
which the XIP application is being copied into may not respond to simple memory writes issued by
an application program.
Updates to existing memory pages may be made if the card technology and system supports write
access.
Calling Parameters:
*char_buffer)
function XIP_COPY_PAGE
partition Contains the ID of the partition which is to have a page copied into it.
logical_page_number The logical page number of the given XIP application to write. If logical page
zero is specified, the buffer is copied to the offset in the XIP page specified in
the XIP_OFFSET field of the directory entry for this application.
write_count Number of bytes to write to the XIP page.
handle The value of the handle assigned to the newly added XIP application. This is
the handle value returned by the "Add XIP Directory Entry" function.
char_buffer Contains a far pointer to an area of RAM memory which contains the XIP
application code or data to be copied into the logical page specified.
Results:
None
Status Codes:
XIP_STAT_HANDLE_NFOUND
XIP_STAT_BAD_PAGE
XIP_STAT_NO_WRITE
XIP_STAT_TOO_MANY_BYTES
XIP_STAT_COPY_ERROR The function failed due to an error in copying. The media supports this
function but the logical page to which the buffer is being copied to is not blank,
and the data cannot be correctly copied.
5.2.15 Delete XIP Directory Entry (Write)

XIP (*function, partition, *application_name)
Purpose:
This function deletes an XIP application from the XIP directory.
Calling Parameters:
function XIP_DELETE_ENTRY
partition Contains the ID of the partition containing the XIP application to be deleted.
application_name The name of the application to be searched for. The name must be in 8.3
format, i.e., an 8-letter name, followed by the 3 letter extension. If either the
name is shorter than 8 characters, or the extension is shorter than 3
characters, they must be padded on the right with spaces to the appropriate
size.
Results:
None
Status Codes:
XIP_STAT_NO_WRITE
XIP SPECIFICATION
5.2.16 Erase XIP Partition (Write)

XIP (*function, partition)
Purpose:
This function allows an XIP utility to erase the entire contents of an XIP partition in preparation for
reuse. The entire XIP partition must be aligned on erase block or device boundaries for this function
to erase only the XIP partition, and nothing else.
Calling Parameters:
function XIP_ERASE_PARTITION
partition Contains the ID of the partition to be erased.
Results:
None
Status Codes:
XIP_NO_WRITE
5.2.17 Close XIP Directory Entry (Write)

XIP (*function, partition, handle)
Purpose:
This function ends the process of creating a new XIP entry. Until this function is executed, a newly-
created XIP application cannot be executed. The function "activates" the newly added XIP
application by setting the status bits of the corresponding XIP directory entry to a value indicating
that it may be loaded and executed.
Calling Parameters:
function XIP_CLOSE_ENTRY
partition Contains the ID of the partition containing the XIP directory entry which is to
be closed.
handle The value of the handle assigned to the newly created XIP application.
Results:
None
Status Codes:
XIP_STAT_NO_WRITE
XIP SPECIFICATION
5.2.18 Execute XIP Application (Common)

XIP (*function, partition, app_name, *return_code)
Purpose:
This function causes the specified XIP application to be mapped in and executed.
Calling Parameters:
function XIP_EXEC
be mapped.
app_name The ASCIIZ name of the application to be executed.
return_code Exit code set by the specified application.
Status Codes:
XIP_STAT_APP_NOT_EXEC
XIP_STAT_MAP_HWARE_BUSY
5.2.19 Map Extended Segment (EXIP)

XIP (*function, partition, handle, *system_address, *map_count)
Purpose:
This function maps memory PC Cards into the system's extended address space. The specified
application on the memory PC Card will appear at the address range returned by this function. A
system may support simultaneous mapping of multiple segments.
Calling Parameters:
function XIP_MAP_EXTENDED
be mapped.
handle The value of the handle assigned to the XIP application.
system_address System memory address corresponding to the specified application.
map_count The size, in bytes, of the block mapped system memory.
Status Codes:
XIP_STAT_MAP_HWARE_BUSY
XIP_STAT_NO_EXIP_DRIVER
XIP_STAT_NO_EXIP
XIP SPECIFICATION
5.2.20 Unmap Extended Segment (EXIP)

XIP(*function, partition, handle)
Purpose:
This function removes the mapping of the specified application. The specified application will no
longer appear in the address space.
Calling Parameters:
function XIP_UNMAP_EXTENDED
be mapped.
handle The value of the handle assigned to the XIP application.
Results:
None
Status Codes:
XIP_STAT_NO_EXIP_DRIVER
XIP_STAT_NO_EXIP
5.2.21 Get Partition ID from Address (Common)

XIP(*function, *partition, system_address)
Purpose:
This function returns the ID of the partition onto which the specified system address is currently
mapped.
Calling Parameters:
function XIP_XLATE_PARTITION
system_address The system address to be translated to a partition ID.
partition partition which is mapped to the specified system address.
Status Codes:
XIP_STAT_ADDR_NOT_MAPPED
XIP SPECIFICATION
5.2.22 Get Slot Number (Common)

XIP (*function, partition, *slot)
Purpose:
This function returns the number of the slot that contains the specified partition.
Calling Parameters:
function XIP_GET_SLOT
partition The ID of the partition to be investigated.
slot The slot number that holds the specified partition. Note that the slot number is
vendor specific.
Status Codes:
5.2.23 Disable Partition ID (Common)

Purpose:
This function marks a partition ID as invalid and frees it for future reassignment to an XIP partition.
Calling Parameters:
function XIP_DISABLE_PARTITION
partition Partition ID of the partition to be disabled.
Results:
None
Status Codes:
XIP SPECIFICATION
6. AP P E N D IC E S
6.1 XIP Equate Values
6.1.1 Summary of XIP Function Codes

The following functions are provided by a compliant XIP driver.
Table 6-1: XIP API Functions

Name Description Attributes
XIP_GET_VERSION Get XIP Version Common
XIP_GET_MAP_SEGS Get XIP Mappable Segments LXIP
XIP_GET_PARTITIONS Get XIP Partition IDs Common
XIP_GET_HANDLE_RANGE Get XIP Handle Range Common
XIP_MAP_HANDLE Map/Unmap an XIP Handle's Pages LXIP
XIP_GET_CONTEXT_SIZE Get XIP Mapping Context Size Common
XIP_GET_CONTEXT Get XIP Mapping Context Common
XIP_SET_CONTEXT Set XIP Mapping Context Common
XIP_SEARCH Search for XIP Directory Entry Common
XIP_SEARCH_FIRST Get First XIP Directory Entry Common
XIP_SEARCH_NEXT Get Next Directory Entry Common
XIP_ADD_ENTRY Add XIP Directory Entry Write
XIP_COPY_PAGE Copy XIP Page Write
XIP_DELETE_ENTRY Delete XIP Directory Entry Write
XIP_ERASE_PARTITION Erase XIP Partition Write
XIP_CLOSE_ENTRY Close XIP Directory Entry Write
XIP_MAP_EXTENDED Map Extended Segment EXIP
XIP_UNMAP_EXTENDED Unmap Extended Segment EXIP
XIP_XLATE_PARTITION Get Partition ID from Address Common
XIP_GET_SLOT Get Slot Number Common
XIP_DISABLE_PARTITION Disable Partition ID Common
XIP_EXEC Execute XIP Application Common
XIP_SEARCH_FULL Search for specific XIP Directory Entry Common
APPENDICES
6.1.2 Summary of XIP Status Codes

The following status codes are returned by a compliant XIP driver.
Table 6-2: XIP Status Codes

Number Name Description
082h XIP_STAT_APP_NOT_EXEC XIP Application is marked as non-executable, or is of a type not
executable by this driver.
083h XIP_STAT_HANDLE_NFOUND XIP handle not found.
085h XIP_STAT_NO_HANDLES Insufficient XIP handles to complete the operation.
087h XIP_STAT_NO_PAGES Insufficient total logical pages within the XIP partition to complete the
operation.
088h XIP_STAT_NO_FREE_PAGES Insufficient unallocated logical pages within the XIP directory to
complete the operation.
08Ah XIP_STAT_BAD_PAGE Logical XIP page out of the range of logical pages allocated to the XIP
application.
08Bh XIP_STAT_BAD_SEGMENT Mappable segment address is not mappable by the XIP driver.
0A0h XIP_STAT_APP_NOT_FOUND XIP application not found in the XIP directory, or there are no more
XIP applications present in this XIP directory.
0A1h XIP_STAT_NAME_EXISTS XIP application name already exists.
0A2h XIP_STAT_BAD_APP_NAME XIP application name is invalid.
0A3h XIP_STAT_BAD_MAP_ARRAY XIP mapping array contents are invalid.
0F3h XIP_STAT_ADDR_NOT_MAPPED Address not currently mapped.
0F4h XIP_STAT_MAP_HWARE_BUSY All mapping hardware currently in use.
0F5h XIP_STAT_NO_EXIP_DRIVER Function not available. Hardware extended memory mapping not
available.
0F6h XIP_STAT_NO_EXIP Function not available. Processor does not support extended memory
addressing.
0F7h XIP_STAT_NO_WRITE The driver or system does not support Write functionality. The media
may or may not support Write functionality.
0F8h XIP_STAT_BAD_PARTITION The specified partition does not exist.
0F9h XIP_STAT_NO_DIR_SPACE Insufficient space in the XIP directory to complete the operation.
0FAh XIP_STAT_TOO_MANY_BYTES The number of bytes requested is too large to write.
0FBh XIP_STAT_PAGE_MAPPED Page already mapped into system.
0FCh XIP_STAT_CARD_CHANGED The card containing the XIP partition has changed since the last XIP
API call.
0FDh XIP_STAT_COPY_ERROR An error occurred in copying the XIP application into the XIP partition.
0FEh XIP_STAT_NO_WRITE_MEDIA This media does not support write functionality (ROM).
0FFh XIP_STAT_UNKNOWN_ERROR The function failed. Cause unknown.
XIP SPECIFICATION
6.2 DOS Operating System Binding
6.2.1 Introduction
This appendix gives details for implementation and utilization of a XIP Operating System Binding
(OSB) for DOS. The scope of this implementation is limited to SXIP and LXIP only.
In general, the XIP Operating System Binding for DOS is quite straightforward. One point of
confusion may arise with parameter passing; as the XIP OSB for DOS is a register-based API,
distinctions between passing by value and passing by reference may become somewhat blurred,
and there is naturally some overlaying of parameters within API functional definitions (i.e., a
particular register is used as one variable on entry to the API function, and another on exit). Context
should resolve the confusion.
6.2.1.1 Related Documents

This section identifies documents related to the XIP DOS Operating System Binding Specification.
Information available in the following documents, or in documents listed in the Related documents
section of the XIP Specification, is not duplicated within this document.
DR DOS 6.0 System and Programmer's Guide, Second Edition, August 1991, Novell, Inc.
IBM-AT Technical Reference Manual, First Edition, March 1984, International Business Machines.
Schulman, Andrew, et al Undocumented DOS, First Edition, October 1990, Addison-Wesley
Publishing Company, Inc.
6.2.1.2 Data Sizes

Data sizes are as defined within the main specification for all data structures. For API parameters,
pointers and long ints are 32-bits, ints are sixteen bits, and chars and short ints are 8 bits.
6.2.1.3 Included Code

All code fragments included within this document presuppose the availability of previously defined
entry points and routines (i.e., definition of a routine in one fragment allows calling that routine in
later fragments with no further explanation).
6.2.2 XIP Loader and Execution

The DOS XIP Device driver includes a loader. SXIP device drivers support only XIP Type 1
applications. LXIP device drivers accept both type 1 and 2 applications.
6.2.2.1 Termination of XIP Execution

It is important to note that XIP applications must terminate with either an IntÊ21H, Service 4CH
(EXIT) request, or an Int 21H, Service 31H (KEEP) request. None of Int 20H, IntÊ21H, Service 0, or Int
27H are acceptable, as all require that CS be equal to the segment of the active PSP, which, when an
XIP terminates, is not the case.
APPENDICES
6.2.2.2 SXIP Execution

SXIP (Type 1) applications are similar in form to .COM programs. The executable image is less than
64K in size, and is not overlaid. These programs are loaded in the following way:
1. The entire image of the program is mapped into memory.
2. A block of memory large enough to hold the environment and program name is allocated, and
the current environment is copied to that block.
3. The name of the XIP image (including an ascii number representing the partition number) is
appended to the new environment.
4. The rest of memory is allocated, and a PSP created at the beginning of the newly allocated
memory.
5. The newly created environment is marked as belonging to the newly created PSP.
6. DS, ES, and SS are set to the segment of PSP. SP and all other registers are set to 0.
7. The entry point specified in the first page of the application is jumped to.
As an example, if the XIP application WORDPROC.XIP were to be executed from partition 10, the
ASCIIZ string appended to the end of the environment would be "10:WORDPROC.XIP.Ó
Note that, in contrast to the Version 1.0 specification, the above method of loading is not a suggested
method; it is now specified, and any other loading methods must be compatible.
6.2.2.3 SXIP Image Format

SXIP applications are direct execution images. No header of any type is used. No code or data is
relocated into RAM at startup.
6.2.2.4 LXIP Execution

LXIP (Type 2) applications are, in general, much more complex than SXIP applications. However,
the majority of the loading sequence is identical. The primary difference in the load sequence is that
only the first 16K page of the application is mapped into memory. Steps 2 through 7, above, are
identical.
Note again that, in contrast to the Version 1.0 specification, the above method of loading is not a
suggested method; it is now specified, and any other loading methods must be compatible.
6.2.2.5 LXIP Image format

LXIP (Type 2) applications are responsible for managing their own overlays, as well as data
initialization. Thus, the Image format of an LXIP application is strictly the responsibility of the
developer.
XIP SPECIFICATION
6.2.3 XIP API Details

The details of each API entry calling format are listed below. One should refer to the XIP
specification for additional information. In all cases, the return values are based upon the
assumption that the operation succeeded, and thus, that the carry flag is clear. If such is not the case,
AH will return with the appropriate error code.
6.2.3.1 Get XIP Version (Common)

XIP (*function, *version, *functionality)
function AH XIP_GET_VERSION 80h

version AL
functionality AH
6.2.3.2 Get XIP Mappable Segments (LXIP)

XIP (*function, *XIP_mappable_array, *mappable_array_length)
function AH XIP_GET_MAP_SEGS 81h

XIP_mappable_array ES:DI
mappable_array_length CX
6.2.3.3 Get XIP Partition IDs (Common)

XIP (*function, partition_ids_array, *partition_array_length)
function AH XIP_GET_PARTITIONS 82h

partition_ids_array ES:DI
partition_array_length CX
6.2.3.4 Get XIP Handle Range (Common)

XIP (*function, *XIP_first_handle, *XIP_last_handle, *total_handles)
function AH XIP_GET_HANDLE_RANGE 83h

XIP_first_handle BX
XIP_last_handle DX
total_handles CX
APPENDICES
6.2.3.5 Map/Unmap an XIP Handle's Pages (LXIP)

function AH XIP_MAP_HANDLE 84h

handle DX
partition AL
map_count CX
seg_map_array DS:SI
6.2.3.6 Get XIP Mapping Context Size (Common)

XIP (*function, *map_context_size)
function AH XIP_GET_CONTEXT_SIZE 85h

map_context_size AL
6.2.3.7 Get XIP Mapping Context (Common)

function AH XIP_GET_CONTEXT 86h

xip_context ES:DI
6.2.3.8 Set XIP Mapping Context (Common)

function AH XIP_SET_CONTEXT 87h

xip_context DS:SI
6.2.3.9 Search for XIP Directory Entry (Common)

function AH XIP_SEARCH 88h

partition AL
application_name DS:SI
handle DX
page_count CX
XIP SPECIFICATION
6.2.3.10 Get First XIP Directory Entry (Common)

function AH XIP_SEARCH_FIRST 89h

partition AL
XIP_dir_entry ES:DI
handle DX
page_count CX
6.2.3.11 Get Next XIP Directory Entry (Common)

function AH XIP_SEARCH_NEXT 8Ah

partition AL
XIP_dir_entry ES:DI
handle DX
page_count CX
6.2.3.12 Add XIP Directory Entry (Write)

function AH XIP_ADD_ENTRY 8Bh

partition AL
XIP_dir_entry DS:SI
handle DX
6.2.3.13 Copy XIP Page (Write)

*char_buffer)
function AH XIP_COPY_PAGE 8Ch

partition AL
logical_page_number BX
write_count CX
handle DX
APPENDICES
6.2.3.14 char_buffer DS:SI Delete XIP Directory Entry (Write)

function AH XIP_DELETE_ENTRY 8Dh

partition AL
application_name DS:SI
6.2.3.15 Erase XIP Partition (Write)

function AH XIP_ERASE_PARTITION 8Eh

partition AL
6.2.3.16 Close XIP Directory Entry (Write)

XIP (*function, partition, handle)
function AH XIP_CLOSE_ENTRY 8Fh

partition AL
handle DX
6.2.3.17 Map Extended Segment (EXIP)

XIP (*function, partition, handle, *system_address, *map_count)
function AH XIP_MAP_EXTENDED 90h

partition AL
handle DX
system_address EDX
map_count ECX
6.2.3.18 Unmap Extended Segment (EXIP)

XIP(*function, partition, handle)
function AH XIP_UNMAP_EXTENDED 91h

partition AL
handle DX
XIP SPECIFICATION
6.2.3.19 Get Partition ID from Address (Common)

XIP(*function, *partition, system_address)
function AH XIP_XLATE_PARTITION 92h

system_address ES:DI
partition AL
6.2.3.20 Get Slot Number (Common)

XIP (*function, partition, *slot)
function AH XIP_GET_SLOT 93h

partition AL
slot AL
6.2.3.21 Disable Partition ID (Common)

function AH XIP_DISABLE_PARTITION 94h

partition AL
6.2.3.22 Execute XIP Application (Common)

XIP (*function, partition, app_name, *return_code)
function AH XIP_EXEC 95h

partition AL
app_name ES:DI
6.2.3.23 Search for full XIP Directory Entry (Common)

function AH XIP_SEARCH_FULL 96h

partition AL
XIP_dir_entry ES:DI
APPENDICES
6.2.3.24 Secondary Map/Unmap an XIP Handle's Pages (LXIP)

function AH SECOND_XIP_MAP_HANDLE 97h

handle DX
partition AL
map_count CX
seg_map_array ES:DI
6.2.3.25 Secondary Set XIP Mapping Context (Common)

function AH SECOND_XIP_SET_CONTEXT 98h

xip_context ES:DI
6.2.3.26 Secondary Search for XIP Directory Entry (Common)

function AH SECOND_XIP_SEARCH 99h

partition AL
application_name ES:DI
handle DX
page_count CX
6.2.3.27 Secondary Add XIP Directory Entry (Write)

function AH SECOND_XIP_ADD_ENTRY 9Ah

partition AL
XIP_dir_entry ES:DI
handle DX
XIP SPECIFICATION
6.2.3.28 Secondary Copy XIP Page (Write)

*char_buffer)
function AH SECOND_XIP_COPY_PAGE 9Bh

partition AL
logical_page_number BX
write_count CX
handle DX
char_buffer ES:DI
6.2.3.29 Delete XIP Directory Entry (Write)

function AH SECOND_XIP_DELETE_ENTRY 9Ch

partition AL
application_name ES:DI
APPENDICES
6.2.4 XIP Applications Programming Interface
6.2.4.1 Initializing the XIP API

1. Issue a DOS "open read-only mode" request (INT 21h, Service 3D00h). This function requires a
far pointer to the ASCIIZ string containing the device name to open. In this case, the device
name is actually the internal name found in the XIP device driver's header. The pointed-to
ASCIIZ string should have the following format:
XIP_device_name DB "XIP$$$$$", 0
If DOS does not return an error status, one can assume that either a device with the name
"XIP$$$$$" is installed, or a file with this name is on the current disk drive. Proceed to step 4.1.4,
otherwise, proceed to the next step.
1. If DOS returned a "too many open files" status, one can modify one's application so that it opens
the XIP device before it opens any other files. The XIP handle is not used after the entry point is
obtained. If this was not the error one's application received, proceed to the next step.
2. If DOS returned a "file/path not found", the XIP-device driver is not installed. If one's
application requires the XIP-device driver, there is only one way to correct the problem. The
user must install the XIP-device driver, modify the CONFIG.SYS file to reflect the installation,
and reboot the system before proceeding. One's application cannot proceed further.
3. Issue a DOS IOCTL "get device data" using the handle obtained in step 1. This function returns
device data that allows one to determine whether XIP is a device or a file.
4. If DOS returns any error status, one may assume that the XIP device driver is not installed. The
user will have to follow the procedure outlined in step 3 to correct the problem.
5. Check that "XIP$$$$$" is a device and not a file with the same name. The device data returned
by the previous DOS function contains the ISDEV bit (DX bit 7). If the ISDEV bit is a 1 then
"XIP$$$$$" is a character device and not a file. If ISDEV is bit is a 0 then "XIP$$$$$" is a file and
there is no XIP-device driver installed. The user will have to follow the procedure outlined in
step 3 to correct the problem. Also, the file named XIP shall be renamed so that the user may
access it after the XIP driver is installed. This should be an extremely rare situation.
6. Issue a DOS "IOCTL read" using the handle obtained in step 1 for a maximum of 4 bytes.
7. If DOS returns any error status, or the driver does not transfer the specified number of bytes,
one may assume that the XIP-device driver is not a compliant driver. The user will have to
follow the procedure outlined in step 3 to correct this problem.
8. Save the device driver entry-point address returned by the Òread.Ó
9. Issue a DOS "close" command using the handle obtained in step 1. Doing so frees up the handle
allocated by the original "open.Ó The handle is not used again.
XIP SPECIFICATION
The following procedure is an example of the technique outlined in this section.

;------------------------------------------------------------------;
; open_XIP_driver ;
; The procedure verifies that the XIP driver is installed in the ;
; system and returns a handle so that driver IOCTLs may be done ;
; if it is present. ;
; If XIP driver is installed ;
; CARRY CLEAR ;
; (bx) = handle for XIP device driver get/set calls ;
; else ;
; CARRY SET ;
;------------------------------------------------------------------;
open_XIP_driver proc
;------------------------------------------------------------------;
; Open the XIP device. ;
;------------------------------------------------------------------;
mov dx, offset XIP_device_name
; (ds:dx) = far ptr to
; device name string
mov ax, 3D00h ; (ax) = open read-only function
int 21h ; issue device read-only open
jc oXd_02 ; error during device open
;------------------------------------------------------------------;
; Get the info flags for the XIP handle.
;
;------------------------------------------------------------------;
mov bx, ax ; (bx) = handle returned by open
mov ax, 4400h ; (ax) = IOCTL get device data function
int 21h ; issue get device data IOCTL
jc oXd_01 ; error during IOCTL get device info
;------------------------------------------------------------------;
; Test the ISDEV bit in the device info flags. ;
;------------------------------------------------------------------;
test dx, 0080h ; (dx) = file or device data
jz oXd_01 ; XIP is a file, NOT a device
;------------------------------------------------------------------;
; XIP driver is installed in this system. ;
; Return: ;
; (bx) = XIP driver handle. ;
; (CARRY CLEAR) to indicate that the XIP device is ;
; installed. ;
;------------------------------------------------------------------;
clc
ret
;------------------------------------------------------------------;
; XIP driver is not installed in this system. ;
; Close the file named XIP$$$$$. ;
APPENDICES
; (bx) = handle returned by open call ;

;------------------------------------------------------------------;
oxd_01: mov ah, 3Eh ; (ah) = close function
int 21h ; close XIP$$$$$ file/driver
;------------------------------------------------------------------;
; XIP driver is not installed in this system. ;
; Return: ;
; (CARRY SET) to indicate that the XIP device is not ;
; installed. ;
;------------------------------------------------------------------;
oXd_02: stc
ret
open_XIP_driver endp
;------------------------------------------------------------------;
; XIP driver name. ;
;------------------------------------------------------------------;
XIP_device_name db "XIP$$$$$", 0
XIP SPECIFICATION
6.2.5 IOCTL Read (Get Current XIP API Entry Point)

The DOS "IOCTL read" function (INT 21h, function 4402h) is used to obtain the XIP API entry point.
This function will read, into a buffer supplied by the application, a dword pointer supplied by the
XIP driver. The dword pointer in the buffer is a far pointer to a far pointer to the XIP API. All
applications needing to use the XIP API must obtain this entry point before they can make an XIP
API call.
The following example builds on the previous example and demonstrates how an application
obtains the XIP API entry point.
;------------------------------------------------------------------;
; Get the current XIP API entry point. ;
; If XIP API services are available ;
; CARRY CLEAR ;
; (bx) = handle for future XIP device driver get/set calls ;
; (XIP_callback) = far pointer to far pointer to the XIP API ;
; else ;
; CARRY SET ;
;------------------------------------------------------------------;
get_XIP_callback proc
call open_XIP_driver ; check for the XIP driver & open it
jc gXc_02 ; XIP driver not installed
;------------------------------------------------------------------;
; Get the XIP API entry point. ;
; (bx) = XIP driver handle returned by open ;
;------------------------------------------------------------------;
mov dx, offset XIP_callback; (ds:dx) = far ptr to XIP callback
buffer
mov cx, 4 ; (cx) = # bytes to transfer (dword size)
mov ax, 4402h ; (ax) = IOCTL read device data
int 21h ; issue IOCTL read device data
jc gXc_01 ; error during IOCTL read device data
;------------------------------------------------------------------;
; Verify that only the XIP API entry point was transferred. ;
;------------------------------------------------------------------;
cmp ax, 4 ; (ax) = # bytes actually transferred
jne gXc_01 ; driver did not transfer the
specified
; # of bytes
;------------------------------------------------------------------;
; XIP API services are available. ;
; Return: ;
; (XIP_callback) = far pointer to far pointer to the XIP API. ;
; (CARRY CLEAR) to indicate that the XIP API services ;
; are available. ;
;------------------------------------------------------------------;
clc
ret
;------------------------------------------------------------------;
APPENDICES
; Close the XIP device. ;

; (bx) = handle returned by open_XIP_driver call ;
;------------------------------------------------------------------;
gXc_01: mov ah, 3Eh ; (ah) = close function
int 21h ; close XIP device
;------------------------------------------------------------------;
; XIP API services are not available. ;
; Return: ;
; (CARRY SET) to indicate that the XIP API services are ;
; are not available. ;
; ;
;------------------------------------------------------------------;
gXc_02: stc
ret
get_XIP_callback endp
;------------------------------------------------------------------;
; XIP callback storage. ;
;------------------------------------------------------------------;
XIP_callback dd ?
XIP SPECIFICATION
6.2.6 IOCTL Write (Set New XIP API Entry Point)

The DOS "IOCTL write" function (INT 21h, function 4403h) is used to set a new XIP API entry point.
This function will write a dword pointer, supplied by the application, to the XIP driver. This dword
pointer is a far pointer to the new XIP entry procedure. The function provides an XIP utility, or
another device driver that needs to trap XIP API accesses, with the ability to chain into the XIP API's
path of execution.
If one is creating an XIP utility that absolutely must chain into the XIP API, remember to restore the
original XIP entry point before one's utility exits back to DOS. If one does not, and one's code exits,
the next application that attempts to use the XIP API will probably hang the users system.
The following example builds on the previous examples and demonstrates how an application sets a
new XIP API entry point.
;------------------------------------------------------------------;
; Get the current XIP API entry point and set a new XIP ;
; API entry point. ;
; If XIP API services are available ;
; CARRY CLEAR ;
; (bx) = handle for XIP device driver get/set calls;
; (XIP_callback) = far pointer to far pointer to the XIP API ;
; (old_XIP_ent_pt) = address of the current XIP API entry point.
;
; (new_XIP_ent_pt) = address of the new XIP API entry point. ;
; else ;
; CARRY SET ;
;--------------------------------------------------------------------;
set_XIP_callback proc
;--------------------------------------------------------------------;
; Open the XIP driver and get the XIP callback. ;
;--------------------------------------------------------------------;
call get_XIP_callback ; get XIP callback
jc sXc_01 ; could not get the XIP callback
;------------------------------------------------------------------;
; Save the address of the current XIP API entry point so that ;
; it can be restored later. The example assumes that the old ;
; XIP entry point is accessible via the example code segment. ;
;------------------------------------------------------------------;
les di, XIP_callback ; (es:di) = far ptr to far ptr
; to XIP API entry point
les di, dword ptr es:[di] ; (es:di) = far ptr XIP entry
; point address
mov word ptr cs:old_XIP_ent_pt[0], di
mov word ptr cs:old_XIP_ent_pt[2], es
; (old_XIP_ent_pt) = current XIP entry point address
;------------------------------------------------------------------;
; Initialize a far pointer in a buffer so that it points to ;
; the new XIP API entry point. ;
APPENDICES
;------------------------------------------------------------------;
mov word ptr new_XIP_ent_pt[0], offset XIP_trap
mov word ptr new_XIP_ent_pt[2], cs
; (new_XIP_ent_pt) = new XIP entry point address
;------------------------------------------------------------------;
; Send the new XIP API entry point to the XIP driver. ;
; (bx) = handle returned by get_XIP_callback ;
;------------------------------------------------------------------;
mov dx, offset new_XIP_ent_pt
; (ds:dx) = far ptr to new XIP entry point buffer
mov cx, 4 ; (cx) = # bytes to transfer (dword size)
mov ax, 4403h ; (ax) = IOCTL write device data
int 21h ; issue IOCTL write device data
jc gXc_01 ; error during IOCTL read device data
;------------------------------------------------------------------;
; New XIP entry point has been set. ;
; Return: ;
; (bx) = handle for future XIP device driver get/set calls ;
; (CARRY CLEAR) to indicate that the XIP API services are ;
; available. ;
;------------------------------------------------------------------;
clc
ret
;------------------------------------------------------------------;
; XIP API services are not available. ;
; Return: ;
; (CARRY SET) to indicate that the XIP API services are ;
; not available. ;
;------------------------------------------------------------------;
sXc_01: stc
ret
set_XIP_callback endp
;------------------------------------------------------------------;
; New XIP entry point storage. ;
;------------------------------------------------------------------;
new_XIP_ent_pt dd ?
;------------------------------------------------------------------;
; Old XIP entry point storage. This example assumes that this ;
; pointer resides in the same CODE segment as do the ;
; set_XIP_callback and XIP_trap procedures. ;
;------------------------------------------------------------------;
old_XIP_ent_pt dd ?
XIP SPECIFICATION
6.2.7 Chaining into the XIP API

The following example builds on the previous examples and demonstrates how an XIP utility would
properly chain into the XIP API. The hypothetical example provided assumes that the original XIP
driver cannot either write or erase the special devices the XIP_trap code supports. However, the
original driver is capable of doing all other functions. Therefore, the example inspects the function
codes passed to the XIP API and traps only erase and write functions rather than permitting the
original XIP driver to do them. All other function will be passed on through.
The example also assumes that set_XIP_callback has been called and has completed successfully.
;------------------------------------------------------------------;
;This example code simply checks to see if the XIP API code passed;
;to the XIP driver performs writes or erases. If it does, it ;
;services the erase or write. If it doesn't, it chains through ;
;to the original XIP API entry point. ;
;------------------------------------------------------------------;
XIP_trap proc far

;------------------------------------------------------------------;
;Trap the three XIP functions that perform writes or erases. ;
;------------------------------------------------------------------;
cmp ah, XIP_Add ; (ah) = XIP function code
je Xt_Add_XIP_Dir ; trap Add XIP Directory Entry
cmp ah, XIP_Copy

je Xt_Copy_XIP_Dir ; trap Copy XIP Directory Entry
cmp ah, XIP_Erase

je Xt_Erase_Partn ; trap Erase XIP Partition
;------------------------------------------------------------------;
;Chain into the original XIP API entry point. ;
;------------------------------------------------------------------;
jmp dword ptr cs:old_XIP_ent_pt
;------------------------------------------------------------------;
;Your special trap code continues here. ;
;------------------------------------------------------------------;
Xt_Add_XIP_Dir: .
.
Xt_Copy_XIP_Dir: .
.
Xt_Erase_Partn: .
.
;------------------------------------------------------------------;
;Your trap code has finished its work. ;
;------------------------------------------------------------------;
XIP_trap_OK:
clc
ret ; CARRY CLEAR indicates operation passed
APPENDICES
XIP_trap_err:
; (ah) = error status of operation
stc ; CARRY SET indicates operation failed
ret
XIP_trap endp
XIP SPECIFICATION
6.2.8 Example of XIP API Use

An example is included to illustrate some of the more complex processes involved in using an XIP
driver and the companion XIP directory structure managed by the driver.
Suppose one wishes to install a new XIP application named "WORDPROC.XIP" to an XIP partition
within a user's PC Memory Card. Further assume that the new XIP application is 109 Kbytes long.
Assume further that the XIP partition on this hypothetical PC Memory Card already has some XIP
applications in it, but absolute-page 17 through absolute-page n within this partition are free. The
following steps illustrate how one might copy this new XIP application into the partition. This
example assumes an XIP installation tool that adds applications on page boundaries.
1. An XIP-copy-utility would search the existing XIP directory structure, using the "Search for XIP
Directory Entry" function, for an existing XIP application with the same name.
2. If an XIP application with the same name already existed in the XIP directory, the XIP-copy-
utility might inform the user of this condition and, if instructed to do so by the user, delete the
old XIP application by using the "Delete XIP Directory Entry" function.
3. The XIP-copy-utility, knowing the size of the new XIP application, and that no XIP application is
in the current XIP directory with the same name as the new one being added, would create for
the new application using the "Add XIP Directory Entry" function.
The data structure for adding this XIP application would look like:
XIP_dir_struct STRUC
name DB "WORDPROC"
ext DB "XIP" ; if necessary
status DB 8h ; this is an EXIP application
begin DW xxxxh ; entry point offset
offset DW 0 ; beginning of page
reserved DW 0,0,0 ; reserved words
creation_time DW xxxxh ; DOS formatting of time bits
creation_date DW xxxxh ; DOS formatting of date bits
first_page DW xxxxh ; based on previous entry
size DD (109*1024) ; size in Kbytes
XIP_dir_struct ENDS
4. After this structure is written into the XIP partition, pages 17, 18, 19...23 are now used by the
XIP application named "WORDPROC.XIP.Ó
5. The XIP-copy-utility would then copy the first 16-Kbyte portion of the new XIP application, from
whatever media it was contained on, into a RAM buffer . The XIP-copy-utility then copies this
buffer into the first logical page allocated to the new XIP application by using the "Copy XIP
Page" function. Realize that the type of memory that XIP applications are stored will typically
not be normal RAM. It is necessary to have the XIP driver do the copying because it is aware of
the nature of the memory on the card. The call may even fail if the memory type happens to be
ROM, which is not writable. The call may also fail if a defect is discovered in the memory in the
XIP partition. The important point to remember is that the status of every operation must
always be checked.
6. The process begun in step 4 is repeated for logical pages 1, 2, 3, 4, 5, and 6.
7. The last step required is to use the "Close XIP Directory Entry" function. This essentially makes
the XIP directory entry and its corresponding application "active" so that it can be loaded and
executed.
APPENDICES
8. Once all logical pages of the new XIP application have been initialized and the entry has been
closed, the process of adding a new XIP application to the partition is complete. At this point,
the XIP-copy-utility is done and the user would have a new XIP application in their XIP
partition.
Volume 10
Guidelines
PCMCIA
JEIDA
+1-408-433-9558 (Fax) IMPORTANT:
+81-3-3433-1923 PCMCIA
INFRINGEMENT,
YOU ÒAS IS.Ó

GUIDELINES
CONTENTS
1. Introduction____________________________________________1
1.1 Purpose................................................................................................................................1
1.2 Scope....................................................................................................................................1
1.4 Guidelines Format ...............................................................................................................2
2. Electrical Guidelines ____________________________________3

2.1 CardBus/PCI Common Silicon Requirements...................................................................3
2.1.1 Summary ......................................................................................................................................................................................3
2.1.2 Background .................................................................................................................................................................................3
2.1.3 Guideline ......................................................................................................................................................................................3
2.1.3.1 Pin Definition Differences........................................................................................................................................3
2.1.3.2 Functional Differences..............................................................................................................................................5
2.1.3.3 Electrical Differences ................................................................................................................................................6
2.1.3.4 Configuration Space Differences...........................................................................................................................7
2.1.3.5 Software Driver Differences...................................................................................................................................8
2.2 Compatibility Icons...........................................................................................................10

2.2.1 Introduction...............................................................................................................................................................................1 0
2.2.2 Usage Guidelines.....................................................................................................................................................................1 0
2.2.3 Thermal Rating Icons.............................................................................................................................................................1 1
3. Physical Guidelines ____________________________________13

3.1 15 Position Shielded Latching I/O Connector..................................................................13
3.1.1 I/O Connector ...........................................................................................................................................................................1 3
3.1.1.1 Card I/O Connector.................................................................................................................................................1 4
3.1.1.2 Cable I/O Connector................................................................................................................................................1 6
3.1.1.3 Key Standards...........................................................................................................................................................1 7
3.1.1.4 Plating...........................................................................................................................................................................1 8
3.1.1.5 Test Sequence..............................................................................................................................................................1 8
3.1.2 I/O Connector Reliability.....................................................................................................................................................1 9
3.1.2.1 Mechanical Performance .......................................................................................................................................2 0
3.1.2.1.1 Office Environment........................................................................................................................................2 0
3.1.2.1.2 Harsh Environment .......................................................................................................................................2 0
3.1.2.1.3 Total Insertion Force (with latches disengaged) ................................................................................2 0
3.1.2.1.4 Total Pulling Force (with latches disengaged)....................................................................................2 0
3.1.2.1.5 Single Contact Forces ....................................................................................................................................2 0
3.1.2.1.6 Single Contact Holding Force ....................................................................................................................2 0
3.1.2.1.7 Vibration ...........................................................................................................................................................2 1
3.1.2.1.8 Shock ...................................................................................................................................................................2 1
3.1.2.1.9 Latch Retention Force....................................................................................................................................2 1

CONTENTS
3.1.2.1.10 Polarization and Key Force .....................................................................................................................2 1

3.1.2.1.11 Connector Plug Torque and Flex ............................................................................................................2 1
3.1.2.1.12 Strain Relief....................................................................................................................................................2 2
3.1.2.2 Electrical Performance ...........................................................................................................................................2 2
3.1.2.2.1 Contact Resistance (low level) ...................................................................................................................2 2
3.1.2.2.2 Withstanding Voltage and Isolation Voltage .....................................................................................2 2
3.1.2.2.3 Insulation Resistance.....................................................................................................................................2 2
3.1.2.2.4 Current Capacity.............................................................................................................................................2 3
3.1.2.2.5 Insulation Material........................................................................................................................................2 3
3.1.2.3 Environmental Performance ................................................................................................................................2 3
3.1.2.3.1 Operating Environment ...............................................................................................................................2 3
3.1.2.3.2 Storage Environment ....................................................................................................................................2 3
3.1.2.4 Environmental Resistance.....................................................................................................................................2 3
3.1.2.4.1 Moisture Resistance.......................................................................................................................................2 3
3.1.2.4.2 Thermal Shock.................................................................................................................................................2 3
3.1.2.4.3 Durability (High Temperature).................................................................................................................2 3
3.1.2.4.4 Humidity (Normal Condition)..................................................................................................................2 4
3.1.2.4.5 Mixed Flowing Gases...................................................................................................................................2 4
3.1.2.4.6 Salt Water Spray.............................................................................................................................................2 4
3.1.3 Connector Durability .............................................................................................................................................................2 4
3.1.3.1 Office Environment..................................................................................................................................................2 4
3.1.3.2 Harsh Environment .................................................................................................................................................2 5
3.1.4 PC Card LAN 15 Position I/O Connectivity..................................................................................................................2 5
3.1.4.1 Connector Pinout Configurations .......................................................................................................................2 6
3.1.4.2 Common Mode Note ...............................................................................................................................................2 8
3.1.4.3 Cable Assembly Notes ............................................................................................................................................2 8
3.2 Modem I/O Unshielded Connector for Open Systems....................................................30

3.2.1 Introduction...............................................................................................................................................................................3 0
3.2.1.1 Purpose .........................................................................................................................................................................3 0
3.2.1.2 Scope..............................................................................................................................................................................3 0
3.2.1.2.1 Modem/FAX Cards ......................................................................................................................................3 0
3.2.1.2.2 Connectors.........................................................................................................................................................3 0
3.2.2 Overview ....................................................................................................................................................................................3 1
3.2.3 Connector Physical..................................................................................................................................................................3 2
3.2.3.1 Card I/O Connectors...............................................................................................................................................3 2
3.2.3.2 Cable Plug Connectors ............................................................................................................................................3 2
3.2.3.2.1 Identification....................................................................................................................................................3 2
3.2.3.2.2 Reservations .....................................................................................................................................................3 2
3.2.3.2.3 Card I/O Connector.......................................................................................................................................3 3
3.2.3.2.4 Cable Plug Connector ....................................................................................................................................3 5
3.2.3.3 Materials and Finishes...........................................................................................................................................3 8
3.2.3.3.1 Insulators...........................................................................................................................................................3 8
3.2.3.3.2 Contacts..............................................................................................................................................................3 8
3.2.3.3.2.1 Materials...............................................................................................................................................3 8
3.2.3.3.2.2 Plating and Finish..............................................................................................................................3 8
iv ©1999PCMCIA/JEIDA
GUIDELINES
3.2.3.4 Polarization................................................................................................................................................................3 8
3.2.4 Test and Performance Criteria ...........................................................................................................................................3 8
3.2.4.1 Test Sequence..............................................................................................................................................................3 8
3.2.4.2 Standard Test Conditions.....................................................................................................................................4 0
3.2.4.3 Mechanical Performance Criteria Tests...........................................................................................................4 1
3.2.4.3.3 Total Insertion Force .....................................................................................................................................4 1
3.2.4.3.4 Total Withdrawal Force..............................................................................................................................4 1
3.2.4.3.5 Single Contact Forces ....................................................................................................................................4 1
3.2.4.3.6 Single Contact Retention Forces ................................................................................................................4 1
3.2.4.3.7 Vibration ...........................................................................................................................................................4 2
3.2.4.3.8 Shock ...................................................................................................................................................................4 2
3.2.4.3.9 Inverse Mating.................................................................................................................................................4 2
3.2.4.3.10 Connector Plug Torque and Flex ............................................................................................................4 2
3.2.4.3.11 Strain Relief....................................................................................................................................................4 3
3.2.4.4 Electrical Performance Criteria..........................................................................................................................4 3
3.2.4.4.1 Contact Resistance (low level) ...................................................................................................................4 3
3.2.4.4.2 Dielectric Withstanding Voltage..............................................................................................................4 3
3.2.4.4.3 Insulation Resistance.....................................................................................................................................4 3
3.2.4.4.4 Current Capacity.............................................................................................................................................4 3
3.2.4.4.5 Insulation Material........................................................................................................................................4 4
3.2.4.4.6 High Voltage Common Mode Isolation.................................................................................................4 4
3.2.4.5 Environmental Performance Criteria...............................................................................................................4 4
3.2.4.5.1 Environmental Conditions.........................................................................................................................4 4
3.2.4.5.2 Moisture Resistance.......................................................................................................................................4 4
3.2.4.5.3 Thermal Shock.................................................................................................................................................4 4
3.2.4.5.4 Durability (High Temperature).................................................................................................................4 4
3.2.4.5.5 Humidity (Normal Condition)..................................................................................................................4 5
3.2.4.5.6 Mixed Flowing Gas.......................................................................................................................................4 5
3.2.4.6 Durability Mating Requirements .......................................................................................................................4 5
3.2.5 Contact Position Assignment ..............................................................................................................................................4 7
3.2.5.1 Contact Position Marking .....................................................................................................................................4 7
3.2.5.2 Cable Interconnections............................................................................................................................................4 7
3.2.6 Intermatability .........................................................................................................................................................................4 8
3.2.6.1 Intermateability Assurance ..................................................................................................................................4 8
3.2.7 PC Card Modem 4 Pin I/O for PSTN Connectivity.....................................................................................................4 9
3.2.7.1 Pinout Configuration for 4 Pin PC Card Modem I/O Connector............................................................4 9
3.2.8 PC Card Modem 7 Pin I/O with Audio Interface........................................................................................................4 9
3.2.8.1 Pinout Configuration for 7 Pin PC Card Modem I/O Connector............................................................4 9
3.2.8.2 Electrical Characteristics for the Audio Interface........................................................................................5 0
3.3 Guideline for Maximum Dimensions for I/O Connectors...............................................52

3.3.1 Background ...............................................................................................................................................................................5 2
CONTENTS
3.3.2 Guideline ....................................................................................................................................................................................5 2
3.4 Extended PC Cards...........................................................................................................54
4. Software Guidelines ___________________________________ 59

4.1 Enabler Capabilities and Behavior....................................................................................59
4.1.1 Summary ....................................................................................................................................................................................5 9
4.1.2 Background ...............................................................................................................................................................................5 9
4.1.3 Guideline ....................................................................................................................................................................................5 9
4.2 CardÐApplication Interaction...........................................................................................61

4.2.1 Summary ....................................................................................................................................................................................6 1
4.2.2 Background ...............................................................................................................................................................................6 1
4.2.3 Guideline ....................................................................................................................................................................................6 2
4.2.3.1 PC Card-Unaware Applications.........................................................................................................................6 2
4.2.3.2 PC Card-Aware Applications..............................................................................................................................6 2
4.3 CardBus Operational Scenarios ........................................................................................64

4.3.1 Summary ....................................................................................................................................................................................6 4
4.3.2 Background ...............................................................................................................................................................................6 4
4.3.3 Guideline ....................................................................................................................................................................................6 4
4.4 Fax/Modem CIS Design ...................................................................................................66

4.4.1 Summary ....................................................................................................................................................................................6 6
4.4.2 Background ...............................................................................................................................................................................6 6
4.4.3 Guideline ....................................................................................................................................................................................6 7
4.4.3.1 The Device Information Tuple (01H) .................................................................................................................6 7
4.4.3.2 Level 1 Version/Product Information Tuple (15H) .....................................................................................6 8
4.4.3.3 ManufacturerÕs ID Tuple (20H) ...........................................................................................................................6 9
4.4.3.4 Function ID Tuple (21H) .........................................................................................................................................6 9
4.4.3.5 Modem Function Extension Tuple (22H) .........................................................................................................7 0
4.4.3.6 Configuration Tuple (1AH) ...................................................................................................................................7 2
4.4.3.7 Configuration-Entry Tuple (1BH).......................................................................................................................7 3
4.4.3.8 No Link Tuple (14H) ................................................................................................................................................7 6
4.4.3.9 End of Tuple Chain (FFH) ......................................................................................................................................7 6
4.5 Wireless CIS.......................................................................................................................77

4.5.1 Summary ....................................................................................................................................................................................7 7
4.5.2 Background ...............................................................................................................................................................................7 7
4.5.3 Guideline ....................................................................................................................................................................................7 7
4.5.3.1 Wireless Modems.....................................................................................................................................................7 7
4.5.3.2 Wireless LANS ..........................................................................................................................................................7 7
4.5.3.3 Wireless Pagers .........................................................................................................................................................7 7
4.6 Sample PC Card ATA Tuple Options..............................................................................78

4.6.1 Summary ....................................................................................................................................................................................7 8
4.6.2 Background ...............................................................................................................................................................................7 8
4.6.3 Guideline ....................................................................................................................................................................................7 8
4.6.3.1 CIS Usage for PC Card ATA Cards ...................................................................................................................7 9
vi ©1999PCMCIA/JEIDA
GUIDELINES
4.6.3.2 Sample Tuples for PC Card ATA Cards ..........................................................................................................8 3
4.7 Guideline for CIS Tuples for 3.3 or 3.3/5 volt Operation................................................97
4.7.1 Introduction...............................................................................................................................................................................9 7
4.7.1.1 Purpose .........................................................................................................................................................................9 7
4.7.1.2 Scope..............................................................................................................................................................................9 7
4.7.2 CIS for a PC Card with 3.3 volt Only Operation..........................................................................................................9 8
4.7.2.1 CISTPL_DEVICE_OC.............................................................................................................................................9 8
4.7.2.2 CISTPL_CONFIG......................................................................................................................................................9 9
4.7.2.3 CISTPL_CFTABLE_ENTRY................................................................................................................................9 9
4.7.2.3.1 First CISTPL_CFTABLE_ENTRY.........................................................................................................100
4.7.2.3.2 Second CISTPL_CFTABLE_ENTRY....................................................................................................101
4.7.3 CIS for a PC Card with 3.3 or 5 volt Operation.........................................................................................................102
4.7.3.1 CISTPL_DEVICE...................................................................................................................................................102
4.7.3.2 CISTPL_DEVICE_OC..........................................................................................................................................102
4.7.3.3 CISTPL_CONFIG...................................................................................................................................................104
4.7.3.4 CISTPL_CFTABLE_ENTRY.............................................................................................................................10 4
4.7.3.4.1 First CISTPL_CFTABLE_ENTRY.........................................................................................................105
4.7.3.4.2 Second CISTPL_CFTABLE_ENTRY....................................................................................................106
4.7.3.4.3 Third CISTPL_CFTABLE_ENTRY ......................................................................................................107
4.7.3.4.4 Fourth CISTPL_CFTABLE_ENTRY.....................................................................................................108
4.7.4 CIS for a CardBus PC Card...............................................................................................................................................109
4.7.4.1 CISTPL_DEVICE_OC..........................................................................................................................................109
4.7.4.2 CISTPL_CONFIG_CB ..........................................................................................................................................109
4.7.4.3 CISTPL_CFTABLE_ENTRY_CB.....................................................................................................................110

GUIDELINES
FIGURES
Figure 2-1: Card-Side Thermal Icons................................................................................11
Figure 2-2: Host-Side Thermal Icons ................................................................................12
Figure 3-1: PCB Connector................................................................................................14
Figure 3-2: Cable Connector..............................................................................................16
Figure 3-3: Key Size and Locations...................................................................................17
Figure 3-4: Open Standard LAN Connector Key Configuration .....................................18
Figure 3-5: Reserved Connector Key Configuation...........................................................18
Figure 3-6: Reserved Connector Key Configuration .........................................................18
Figure 3-7: Card I/O Connector, 4 Position.....................................................................33
Figure 3-8: Card I/O Connector, 7 Position.....................................................................34
Figure 3-9: Cable Plug Connector, 3 Position...................................................................35
Figure 3-10: Cable Plug Connector, 4 Position .................................................................36
Figure 3-11: Cable Plug Connector, 7 Position .................................................................37
Figure 3-12: Microphone Input with Bias Supply ............................................................51
Figure 3-13: Maximum Dimensions for I/O Connector ..................................................53
Figure 3-14: Type I Extended PC Card Package Dimensions .........................................55
Figure 3-15: Type I Extended (3-D)..................................................................................56
Figure 3-16: Type II Extended PC Card Package Dimensions........................................57
Figure 3-17: Type II Extended (3-D) ................................................................................58
GUIDELINES
TABLES
Table 3-1: PCB Connector Dimensions.............................................................................15
Table 3-2: PCB Connector Contact Lengths .....................................................................15
Table 3-3: Cable Connector Dimensions...........................................................................17
Table 3-4: Key Dimensions................................................................................................17
Table 3-5: Recommended Test Sequence..........................................................................19
Table 3-6: Ethernet with AUI and 10BaseT......................................................................26
Table 3-7: Ethernet with AUI and 10 Base 2....................................................................26
Table 3-8: Token Ring UTP and STP ................................................................................27
Table 3-9: ARCNET with UTP and Coax.........................................................................27
Table 3-10: ATM................................................................................................................28
Table 3-11: Card I/O Connector Dimensions ..................................................................33
Table 3-12: Cable I/O Connector Dimensions .................................................................36
Table 3-13: Connectors Per Test Group............................................................................38
Table 3-14: Test Sequence .................................................................................................39
Table 3-15: Cable Type, Point-to-Point Wiring Physical Definition ................................47
Table 3-16: 4 Pin PC Card Modem I/O Connector Pinouts ............................................49
Table 3-17: 7 Pin PC Card Modem I/O Connector Pinouts ............................................50
Table 4-1: Tuple Codes for Fax/Modem Card Example.................................................67
Table 4-2: Device Information Tuple................................................................................67
Table 4-3: Version Product Information Tuple ................................................................68
Table 4-4: Manufacturers ID Tuple..................................................................................69
Table 4-5: Function ID Tuple............................................................................................69
Table 4-6: Function Extension Tuples...............................................................................71
Table 4-7: Configurable Card Tuple.................................................................................72
Table 4-8: Configuration Entry Tuple...............................................................................74
Table 4-9: Power Extension Fields for Tuple 1BH ............................................................74
Table 4-10: Current /Voltage Scales.................................................................................75
Table 4-11: Mantissa Values.............................................................................................75
Table 4-12: No Link Tuple ................................................................................................76
Table 4-13: End of Tuple Chain........................................................................................76
Table 4-14: PC Card ATA Tuple Usage Chart ................................................................79
Table 4-15: Sample Device Info TupleÐ01H Required on PC Card ATA Cards ............83
© 1999 PCMCIA/JEIDA xi
TABLES
Table 4-16: Sample Other Conditions Device Info TupleÐ1CH Required only if 3V VCC or
WAIT# signal is supported by card for Common Memory cycles......................84
Table 4-17: Sample JEDEC ID TupleÐ18H Required for PC Card ATA Cards supporting
Memory Mapped PC Card ATA Registers...........................................................85
Table 4-18: Sample ManufacturerÕs ID TupleÐ20H Optional but recommended, for PC Card
ATA Devices..........................................................................................................85
Table 4-19: Sample Level 1 Version / Product Info TupleÐ15H Recommended ............86
Table 4-20: Function ID Tuple, Disk FunctionÐ21H Required for PC Card ATA Cards86
Table 4-21: Disk Function Extension TupleÐInterface Type Required for PC Card ATA Cards
................................................................................................................................87
Table 4-22: Sample Disk Function ExtensionÐPC Card ATA Parameters Tuple Strongly
Recommended. Required for PC Card Standard Feb. 1995 and Dual Drive PC Card
ATA .......................................................................................................................87
Table 4-23: Sample Configuration Tuple Required for all PC Card ATA cards. ...........88
Table 4-24: Sample Configuration Entry Tuple for Memory Mapped I/O PC Card ATA
Configuration Required if Memory Mapped ATA Registers Supported ............89
Table 4-25: Sample Contiguous I/O Mapped ATA Registers Configuration Entry Tuple
Required for PC Card ATA Devices.....................................................................91
Table 4-26: Sample ATA Primary I/O Mapped Configuration Entry Tuple Required for PC
Card ATA Devices ................................................................................................93
Table 4-27: Sample ATA Secondary I/O Mapped Configuration Entry Tuple Required for PC
Card ATA Devices ................................................................................................95
Table 4-28: Sample No Link Tuple: 14H Optional but recommended, for PC Card ATA
Devices...................................................................................................................96
Table 4-29: Sample End of Tuple Chain: FFH Required for PC Card ATA Devices as the last
tuple on each chain which is not terminated with a link value of FFH. ...............96
xii ©1999PCMCIA/JEIDA
GUIDELINES
1.1 Purpose
This document is designed to provide implementation examples and further explanations of the PC
Card Standard in order to:
· enhance the interoperability of PC Card components, including card hardware and software,
system hardware and software, and applications.
· facilitate the development of PC Card hardware and software by increasing the understanding
of the standard by PC Card implementation community.
These guidelines are not requirements made by the PCMCIA/JEIDA standards organizations.
Rather, they are implementation examples, suggestions and hints.
1.2 Scope
Guidelines may address any of the following areas:
1. difficult portions of the standard which could use further explanation
2. implementation hints and considerations which a PC Card designer wishes to make public
3. examples which other implementers could use as starting points for their own designs
4. PC Card product areas for which no PC Card Standards exist, e.g., applications
5. interaction of PC Card designs with other areas, e.g., other buses
Guidelines may cover any PC Card hardware or software, whether system or card-based. A
guideline may restrict itself to a given architecture, operating system, or other implementation
constraint in order to be more effective.
In summary, this guidelines section is meant to be a useful adjutant to the PC Card Standard and
not to be an additional source of such standards.
INTRODUCTION

PC Card Standard, Release 7.0 (February 1999)March 1997, PCMCIA/JEIDA
Volume 11. PCMCIA Specific Extensions
Volume 12. JEIDA Specific Extensions
MIL-STD-202F, Military Standard, Test Methods for Electrical Connectors, U.S. Department of
Defense.
MIL-STD-1344A, Military Standard, Test Methods for Electrical Connectors, U.S. Department of
Defense.
ANSI/UL 94-1979, November 16, 1979, Standard for Tests for Flammability of Plastic Materials
for Parts in Devices and Appliances
ANSI/EIA-364-65-1992, March 6, 1992, EIA Standard TP-65, Mixed Flowing Gas, Electronic
Industries Association
CB14, June 1993, EIA Engineering Bulletin, Contact Lubrication, Electronic Industries Association
EIA-364B, August 1990, Electrical/Socket Test procedures including Environmental Classifications,
Electronic Industries Association
IEC Standard No. 950, Second Edition 1991, Safety of Information Technology Equipment,
including Electrical Business Equipment, International Electrotechnical Commission.
1.4 Guidelines Format

This section is a compendium of individual guidelines. Each guideline has subsections as follows:
Summary indicates the objective of the guideline and the result
of following it
Background explains purpose of the guideline. In some cases it
also gives information on current implementations
Guideline gives the actual guideline
2 ©1999PCMCIA/JEIDA
GUIDELINES
2 . EL E C T R IC AL G U ID E L IN E S
2.1 CardBus/PCI Common Silicon Requirements
2.1.1 Summary
One of the goals of the CardBus specification is to allow a component to be designed so that it can
function either in the PC Card environment when mounted on a CardBus PC Card or in the PCI
environment when attached directly to a PCI bus. While the CardBus specification makes it possible
to do this, this guideline provides specific details of how the design must be done in order to
achieve this goal.
2.1.2 Background
The PCI specification, Rev 2.0, served as the starting point in developing the CardBus interface.
Any differences between the two standards were driven primarily by differences in the electrical
environment (the PC CardÕs 68-pin connector vs. PCIÕs 120 pin), the point-to-point interconnect
mandated by 16-bit PC Card support (vs. PCIÕs bused environment), and the dynamic
insertion/removal characteristics inherent to PC Card but not PCI. This guideline describes the
tradeoffs made to overcome these differences and documents how common silicon should be
designed and used in the CardBus environment.
The information in the guideline is structured in similar fashion to the CardBus specification to
make it easier to identify where CardBus differs from PCI. As a result, this guideline covers the
following areas:
1. pin definition differences
2. functional differences
3. electrical differences
4. configuration space differences
5. software driver differences
This guideline should not be used as a substitute for either the CardBus or PCI specifications by
design engineers. Its only purpose is to highlight differences, explain why the difference exists, and
show what CardBus implementations must do to overcome them. The detail contained is not
sufficient to enable a design to be undertaken.
2.1.3 Guideline
2.1.3.1 Pin Definition Differences

The pinout differences between CardBus and PCI are:
1. CardBus does not have an IDSEL signal.
PCI uses IDSEL as a chip select for configuration read and configuration write cycles. Since
CardBus PC Cards always operate in a point-to-point environment, they are always the
ELECTRICAL GUIDELINES
intended target of configuration cycles on the interface. Therefore, a CardBus PC Card will
always claim a configuration cycle.
Common silicon components must implement IDSEL in order to meet PCI requirements. This
signal should be strapped high (always asserted) when mounted on a CardBus PC Card. This
will cause the component to be selected whenever a configuration cycle is executed on the
CardBus interface.
2. CardBus does not have the SBO# or SDONE signals.
PCI uses these optional pins to signal address snooping results to the target of a transaction. The
target continues the access when CLEAN is signaled (SBO# deasserted and SDONE asserted) or
terminates with retry when HITM is signaled.
The CardBus adapter can take appropriate action on the system bus (e.g., terminate with retry)
and on CardBus (e.g., discard read data, terminate write cycles) without informing the card of
the snoop results. Therefore, CardBus does not implement these two signals.
Common silicon which implements SBO# and SDONE, but not CBLOCK#, must strap SBO#
and SDONE high on CardBus PC Cards so the component will always see the CLEAN state. If
CBLOCK# is implemented, SBO# and SDONE must be disabled. Strapping them high causes
CLEAN to be signaled during the address phase of a write to a locked resource. This causes the
component to conclude the write cycle is a writeback of a dirty cache line so it would override
the locked status and complete the write. If you intend to implement a function with SBO#,
SDONE, and LOCK#, please contact the PCI SIG for assistance in defining this disable
mechanism.
3. CardBus does not have the 64-bit bus extension pins.
Because of pin constraints in the 68-pin connector, CardBus does not support AD[63::32],
C/BE[7::4]#, REQ64#, ACK64#, and PAR64. If common silicon implements these signals, the
REQ64# signal must be pulled up to VCC on CardBus cards so that it is put in 32-bit mode
during reset. Floating inputs on AD[63::32], C/BE[7::4]#, PAR64, and ACK64# must be dealt
with during runtime. This could be done by enabling input ÒkeepersÓ when REQ64# is seen
high during reset.
4. CardBus does not have the JTAG pins.
Because of pin constraints in the 68-pin connector, CardBus does not support IEEE 1149.1
ÒStandard Test Access Port and Boundary Scan ArchitectureÓ across the interface. If the
capability is not needed in CardBus, common silicon must tie TRST# and TCK to ground and
leave TDI, TDO, and TMS unconnected.
If the scan chain is to be used on the CardBus card, then the common silicon component and
card design must provide a means for manipulating it across the CardBus interface. In general,
this will involve incorporating BIST circuitry and using the BIST register defined in
5. CardBus has a CSTSCHG pin.
CardBus uses CSTSCHG to signal battery low/dead, write protect, ready, and remote wakeup
conditions. Common silicon must implement this pin if the functionality is desired for CardBus.
It will be a no-connect, or available as a sideband signal when attached to the motherboard, in
the PCI environment.
6. CardBus has a CAUDIO signal.
Common silicon requiring access to the speaker must implement this signal. Usage of this
silicon in the PCI environment requires either a local speaker, a connection to the system
GUIDELINES
speaker via a cable from PCI add-in boards, or a sideband signal when mounted on the
motherboard.
7. CardBus has a CCLKRUN# signal.
Common silicon desiring a hardware mechanism to start the clock, or continue it for a period of
time, must implement this function. CCLKRUN# should be strapped low when the PCI
environment doesnÕt support this capability.
8. CardBus only has one interrupt (CINT#) pin.
PCI allows interrupts to be signaled using up to four INTx# pins. Due to pin constraints,
CardBus requires using a single interrupt signal, CINT#. If common silicon chooses to
implement multiple INTx# pins, they must be wire-ORÕd together (shorted) when mounted on
a CardBus card.
9. CardBus does not provide exceptions to supporting CPERR# and CSERR#.
Common silicon must implement the CPERR# and CSERR# pins along with the associated
parity generation and checking logic.
2.1.3.2 Functional Differences

The functional differences between CardBus and PCI are:
1. CardBus doesnÕt support PCIÕs Interrupt Acknowledge command.
This command is intended for the target responsible for interrupt handling duties. Such
hardware cannot reside on a CardBus PC Card due to the dynamic insertion/removal nature of
PC Cards. A common silicon component, which requires this capability in the PCI environment,
must implement this command. This will not cause problems because the command will never
occur on CardBus. Also, CardBus will never assign a different meaning to the bit encoding for
this command.
2. CardBus doesnÕt support PCIÕs Dual address cycle (DAC) command.
CardBus does not address the issue of 64-bit addressing although the intention is to add it later.
Common silicon that could benefit from this command (i.e., bus masters) should implement it.
Although the command has no meaning on the CardBus interface based on the present
specification, CardBus will never assign a different meaning to the bit encoding for this
command.
3. CardBus doesnÕt address ignoring byte enables when the target determines cacheability.
In PCI, targets which determine cacheability (e.g., memory controllers) must ignore the byte
enables and return all bytes when the access is cacheable. An example for Intel Architecture
systems is a memory controller telling the CPU that the access is cacheable via the KEN# signal.
This capability does not exist across the CardBus interface.
This has no impact on common silicon. Even if a function existed, which could signal
cacheability information to the CPU and had use in the CardBus environment, the CPU would
never use the non-requested bytes returned from CardBus cards. This is because the
cacheability indication mechanism will never exit the card.
4. CardBus imposes additional usage rules on CBLOCK#.
CardBus PC Cards, like PCI add-in boards, are targeted for usage across multiple CPU
architectures. These differing architectures place different constraints on which transactions can
be guaranteed to be atomic. CardBus has additional usage rules for CBLOCK# to clarify how
exclusive accesses can be guaranteed across differing architectures. These rules apply only to
software developers. The operation of CardBusÕs CBLOCK# pin is identical to PCIÕs LOCK# pin.
Therefore, there is no impact to the design of common silicon.
PCI also requires locking a minimum of 16 bytes, naturally aligned, while CardBus only
requires locking what was read. Common silicon must lock at least 16 bytes when lock is
established.
5. CardBus does not support PCIÕs Configuration Mechanism #2.
PCI requires usage of mechanism #1 for new designs but defined a second mechanism for
existing designs. The components which implemented configuration mechanism #2 do not have
any use on CardBus PC Cards (e.g., host bridges for PCI). In general, functions which have
applicability on PCI and CardBus will never generate configuration cycles.
However, if common silicon ever does need to generate configuration cycles, it must be
designed to use mechanism #1.
6. CardBus requires parity checking and reporting without exception.
CardBus does not allow PCIÕs exceptions for functions which Ònever deal with or contain or
access any data which represents permanent or residual system or application state, e.g., human
interface and video/audio devices.Ó Therefore, all common silicon must implement the CPERR#
and CSERR# pins along with the associated parity checking and reporting logic for address and
data.
7. CardBusÕs CSTSCHG capability requires registers in memory space.
The implementation of CSTSCHG requires providing the Event, Mask, Force, and Present
Value registers. These registers reside in memory. Common silicon which implements the
CSTSCHG capabilities for CardBus must implement these registers and indicate the need for
address space in the appropriate manner (PCI = base address register in configuration space,
CardBus = base address register and the CISTPL_CFTABLE_CB and CS\ISTPL_BAR tuples). A
unique base address register is not required for these registers, other memory requirements
may be included as appropriate.
8. CardBus does not require cards to drive CAD[31::0], CC/BE[3::0]#, and CPAR when CGNT# is
asserted but REQ# isnÕt.
CardBus doesnÕt allow cards to be designated the default owners of an idle interface. However,
PCI requires any bus master to assume such ownership when directed. Therefore, common
silicon must be designed to drive these signals when CGNT# is asserted but CREQ# isnÕt. Since
this condition will never occur on CardBus, there is no conflict.
2.1.3.3 Electrical Differences

The electrical differences between CardBus and PCI are:
1. CardBus requires special slew rate controlled buffers.
CardBus cannot tolerate the switching characteristics of PCI buffers due to the limited number of
ground pins on the connector. Further, the slew rate controlled buffers typically offered by ASIC
houses do not provide enough edge rate control to meet the CardBus requirements. Therefore,
common silicon must do one of the following:
a) Incorporate dual mode buffers (PCI + CardBus modes) and a mechanism to enable the
appropriate mode. Note that the primary difference between these two modes is the slew rate
control. Therefore, the difference in the bufferÕs modes could be as simple as reducing or
disabling the pre-driver for CardBus.
GUIDELINES
b) Series terminate each line to get acceptable di/dt characteristics. These resistor must be
located very close to the interface component on the card so that signals being driven by the
adapter are not affected.
c) Add inductance or resistance to the VCC and GND paths to pull up or pull down the bufferÕs
supply rails during transitions. This reduces the edge rate by making it a function of the RC
time constant of the VCC, or GND, supply. The rate can be controlled by adjusting the value of
resistance/inductance and the amount of current switched through it.
CardBus uses the same DC characteristics as PCI but the loading is reduced. Therefore, input
buffer behavior is identical between the two standards. Only in the AC characteristics do
differences emerge where CardBus simply specifies a rise/fall time since it operates in a
lumped load regime rather than PCIÕs transmission line environment.
2. CardBus does not support the 5V signaling environment.
Common silicon must be designed to operate in the 3.3V signaling environment with
VCC=3.3V. It may additionally be designed to accept VCC=5.0V for the PCI domain.
3. Timing differences.
CardBus is a point-to-point environment so there is no need to distinguish between CREQ#,
CGNT#, and the other signals with respect to timings. The timing differences are:
a) Tval is measured at the DC Vih and Vil values instead of PCIÕs 0.4(VCC) to cleanly specify
what constitutes a valid signal in the CardBus environment.
b) CardBus specifies the minimum time from CCLK stable to the deassertion of CRST# as 100
clocks instead of PCIÕs 100msec. This change better defines reset requirements with any speed
clock. Common silicon must be fully reset in 100 clock cycles.
4. CardBus assigned pins on the connector in a different sequence than PCI.
This was done to better align CardBus signals with the PCMCIA 2.0 & 1.0/JEIDA 4.1 & 4.0
publicationÕs cards since the adapter must configure the interface for any of the three protocols.
The signals affected are CSERR#, CAD16, CGNT#, CINT#, CCLK, CRST#, and CREQ#. The
impact is to the PC Card or PCI add-in board, since the routing of a common silicon component
will require traces crossing each other. The component designer needs to choose the
environment in which these crossovers will occur (CardBus vs. PCI).
5. CardBus specifies a maximum current immediately following power up or reset.
The parameter Icc(CIS) gives CardBus PC Card sockets a guarantee that they can power up any
CardBus PC Card and read the CIS without causing a power fault condition by putting too much
load on the battery. PCI has no equivalent parameter. Since this may extend beyond the
common silicon component, the designer must ensure that cards using their component will not
exceed this value when reading the CIS or reading and writing configuration space.
2.1.3.4 Configuration Space Differences

The configuration space differences between CardBus and PCI are:
1. CardBus does not define all the configuration space fields defined by PCI.
Due to dynamic insertion/removal and generic configuration concerns, CardBus chose to
provide all configuration information in the CIS rather than using PCIÕs predefined header
region in configuration space. As a result, CardBus functions must provide configuration
information in a different manner than PCI. This means that:
a) Common silicon must implement the 16-byte header required by PCI including Vendor ID,
Device ID, Class code, and Revision ID.
b) Common silicon must implement PCIÕs Max_Lat, Min_GNT, and Interrupt line registers if the
function requires them for PCI.
c) The base address registers must be encoded with size information as defined by PCI. These
fields, and encodings, are not used by CardBus so there are no implications with respect to
common silicon.
2. Certain Command register fields are not optional for CardBus.
Both PCI and CardBus define a Command register in configuration space. CardBus requires
common silicon to implement the following fields:
a) Memory Space must be implemented on all cards which support I/O space because I/O space
must be mappable into memory space.
b) Parity Error Response must always be implemented because CardBus does not allow the
exceptionÕs provided by PCI.
c) SERR# Enable must always be implemented because CardBus does not allow the exceptionÕs
provided by PCI.
3. Certain Status register fields are not optional for CardBus.
Both PCI and CardBus define a Status register in configuration space. CardBus requires common
silicon to implement the following fields:
a) Signaled System Error must always be implemented because CardBus requires all functions
to be able to check and report address and data parity errors.
b) Detected Parity Error must always be implemented because CardBus requires all functions to
be able to check and report address and data parity errors.
4. CardBus uses four bytes in the configuration space header for a CIS pointer.
Common silicon must implement these bytes with a pointer to the beginning of the CIS
structure (see the Metaformat and Electrical Specification for details). In addition, if the CIS
cannot fit in configuration space along with PCIÕs driver dependent information, common silicon
must locate it in memory or expansion ROM space and provide a mechanism(s) to access it (i.e.,
base address registers and a data path). Unique base address registers are not required.
5. CardBus requires a memory-mapped base address register whenever I/O space is used by the
card.
CardBus requires all I/O space to be mappable into memory space. This means that I/O base
address registers must be accompanied with a memory base address register. Therefore,
common silicon must implement this companion memory base address register.
2.1.3.5 Software Driver Differences

If a common software driver is to be developed, the following differences must be recognized:
1. CardBus imposes additional interrupt handling requirements.
CardBus defined the INTR field, in the Event, Mask, Force, and Present Value registers, so
Card Services could do end of interrupt (EOI) processing in environments which donÕt provide a
system-level interrupt handler. This created a standard mechanism for clearing interrupts.
Common silicon must implement this field in the above registers. In PCI, the functionÕs device
GUIDELINES
driver must either use this standard mechanism to clear interrupts or a means to disable it and
enable the desired proprietary method must be provided.
2. CardBus requires drivers to have a Card Services interface including tuple comprehension.
This means that a Òcommon driverÓ must implement the Card Services interface. When
implemented in a PCI system, the driver must first check for its functionÕs existence on PCI. If it
doesnÕt find anything, or if it can handle more than one instance, it must then register with
Card Services. If Card Services doesnÕt exist in the system, determined with the
GetCardServicesInfo call, the driver may disable its Card Services interface and proceed
knowing no PC Card will show up.
Upon finding its function, the driver must proceed with completing the configuration in the
appropriate manner ¾ tuple traversal for CardBus vs. configuration space interrogation for PCI.
3. Common drivers must handle dynamic insertion and removal events.
The driver must allow for the fact that its function may disappear or appear at any time and
must not treat it as a catastrophic error condition. (See 4.2: CardÐApplication Interaction
guideline for appropriate behavior when this occurs.)
4. PCI specifies that expansion ROM code is never executed in place.
The only software usage model that PCI defines is where ROM code is always copied from the
ROM device to RAM and executed out of RAM. There is nothing in the architecture which
prohibits execute-in-place (XIP) operation. On the other hand, CardBus allows this ROM code to
be executed-in-place.
When XIP capability becomes a part of CardBus, a common software driver which wants to take
advantage of XIP must deal with differences between the two usage models (copy to RAM for
PCI vs. XIP for CardBus). Details of what these differences are cannot be determined until the
capability is defined.
2.2 Compatibility Icons
2.2.1 Introduction
Compatibility Icons have been designed for use on both products and product packaging as a
standardized method for communicating key product features. By annotating the key compatibility
features it becomes a simple process for an end-user to find and purchase compatible products
including but not limited to Host Systems and PC Cards.
The Compatibility Icons currently defined for use include:
· The PC Card Logo Denoting PCMCIA or JEIDA Membership
· 16-bit
· CardBus
· 3V Only Operation
· 5V Only Operation
· 3.3V and 5V Operation
· Zoomed Video
· DMA
· DVB
· Thermal Rating Icons
P L E A S E C O N T A C T P C MC IA F O R A R T WO R K F IL E S F O R
T H E C O MP A T IB IL IT Y IC O N S
2.2.2 Usage Guidelines

All Compatibility Icons utilize the same basic size, shape, and fonts. Although there are some basic
deployment guidelines for the icons, the usage of the Compatibility Icons by PCMCIA and JEIDA
member companies is completely voluntary.
The following guidelines are provided as a means to improve the end-user recognition and use of
the icons when deployed on products and/or product packaging:
· The use of these icons is restricted to member companies of PCMCIA or JEIDA.
· The use of these icons is completely voluntary.
· No new icons may be implemented without the consent of PCMCIA and JEIDA.
· In packaging, documentation, and other literature the original PC Card Logo should be printed
first in the series, with the appropriate icons next to it indicating the capabilities of the product.
· For PC Card Sockets and PC Cards, only the compatibility icons should be used.
· PCMCIA suggests that the icons be reproduced no smaller than .25Ó wide by .15Ó tall.
· If you have any questions about the usage restrictions or suggestions, please contact the
PCMCIA office.
GUIDELINES
To assist member companies in determining if/which Compatibility Icons may be of value for their
products the following sub-sections are provided with technology overviews and section level cross-
references to areas within the PC Card Standard.
2.2.3 Thermal Rating Icons

The Thermal Rating Icons are based upon a Proactive Thermal Management system designed into
several of the PC Card Standard component layers. The affected component layers include: software
(Card Services and Client Drivers), PC Cards (CIS Ð Card Information Structure), and Host Systems
(HSDT Ð Host System Data Table).
A high level view of how this integrated thermal management system works is provided as follows:
1. The host system is booted and the system software loads. Card Services retrieves the HostÕs
Thermal Rating value from the HSDT.
2. A PC Card is inserted. Card Services and optional Client Drivers read the cardÕs CIS and
retrieve configuration data including the CardÕs Thermal Rating value.
3. Card Services validates the system resources required for the cardÕs configuration. To validate
the Thermal system resource Card Services subtracts the CardÕs thermal rating value from
available HostÕs thermal rating value.
4. If the result of the subtraction in step 3 is greater than or equal to zero then ample thermal
system resource is available and the card configuration process can proceed.
5. If the result of the subtraction in step 3 is less than zero than the card requires more thermal
resource than the host currently has available so the card can not be configured. Enhanced
system software working with Card Services may provide the user feedback indicating that the
card could not be configured as well as offering possible user actions or options to restart the
process.
Note: In a multi-slot host configuration the slots may share the systemÕs thermal
resources. Hence, a second card may need less than the systemÕs rating
value but still not be configurable due to another card already being
present and using some of the thermal resource.
As previously noted, cases can arise where cards may not be configurable due to either the
capabilities of the host (e.g., laptop versus palmtop) or the presence of other cards. To help identify
these conditions well before they occur (e.g., at purchase time) manufacturers can use the thermal
rating icons on their packaging and the customer can perform the subtraction logic to determine if
the desired products are compatible. To assist with the customer usage of the Thermal Rating Icons
two slightly different icon formats have been defined.
The thermal icon format defined for PC Cards is presented as follows:
Figure 2-1: Card-Side Thermal Icons
The thermal icon format defined for host systems is presented as follows:
Figure 2-2: Host-Side Thermal Icons
Both formats utilize a unitless whole number value provided in increments ranging from 1 to 99.
The Thermal Rating Icon values are based directly off of the CIS/HSDT values. The CIS/HSDT
values are converted to whole numbers by multiplying them by 10 and then rounding to the
nearest whole number. For example, a CIS/HSDT value of 1.23 would be converted to a reported
icon value of 12. A CIS/HSDT value of 0.75 would be a reported icon value of 8.
For more information regarding the technical details of the various thermal management
components please refer to the following volumes/sections of the PC Card Standard:
· For PC Card Thermal Ratings details see the Physical Specification Ð PC Card Thermal Ratings
section.
· For CIS Thermal tuple data see the Metaformat Specification Ð CISTPL_CFTABLE_ENTRY,
TPCE_MI Field and CISTPL_CFTABLE_ENTRY_CB, TPCE_CBMI Field description sections.
· For System Software and Driver details see the Card Services Specification Ð ConfigureFunction
and InquireConfiguration service description sections.
· For HSDT and Host Thermal Ratings details see the PC Card Host System Specification.
GUIDELINES
3 . PH YS IC AL G U ID E L IN E S
U N L E S S O T H E R WIS E S P E C IF IE D , A L L D IME N S IO N S A R E
IN MIL L IME T E R S (MM).
3.1 15 Position Shielded Latching I/O Connector
3.1.1 I/O Connector

This section specifies physical characteristics of Open System LAN and modem I/O connectors.
Open System PC Cards are those which contain I/O connectors compliant with this section,
including keying assignments and are further compliant with functional and electrical descriptions.
Open System compliance:
· Does not guarantee interoperability of independent implementations.
· Does not guarantee certifiability to any external (non-PCMCIA/JEIDA) organizations including
FCC, VDE, IEC, UL, etc.
· Does guarantee electricial damage avoidance associated with inadvertent connection.
· Does facilitate uniform implementation interfaces for developers.
· Does promote availability of multi-sourced I/O connectors satisfying PC Card Standard-
mandated design criteria.
PC Cards with I/O connectors or cable assemblies which are not compliant with the Open System
are Closed System cards. This specification does not define nor address Closed System cards.
PHYSICAL GUIDELINES
3.1.1.1 Card I/O Connector

The male PCB connector shall be configured as shown in Figure 3-1: PCB Connector and Table 3-1:
PCB Connector Dimensions and Table 3-2: PCB Connector Contact Lengths.
Shielded Receptacle (Board)
B10 Pos. # 1
B5
B9
B4 - B -
B8 B2 0.05mm s B s
B18
B6
B7 0.1 mm s A s
B3 -A-
B1 0.1 mm s A s
B17
B11
B13
B14
B12 B15
B16
Figure 3-1: PCB Connector
GUIDELINES
Table 3-1: PCB Connector Dimensions

Dimension Millimeters
B1 14.8 ± 0.15
B2 2.5 +0, -0.1
B3 12.38 +0, -0.08
B4 0.7 ± 0.05
B5 30° +0.5, -0
B6 0.8 ±0.05
B7 11.2 ±0.1
B8 2.9 Max
B9 2.0 ±0.1
B10 0.8 ±0.1
B11 0.5 Ref
B12 3.9 Min
B13 1.2 Ref
B14 4.5
B15 4
B16 Refer toTable 3-2
B17 0.95 ±0.1
B18 0.2 ±0.3
Table 3-2: PCB Connector Contact Lengths

Connector Pin Contact Length
Numbers Millimeters
Pins 1,15 3.9
Pins 2..14 3.0
PHYSICAL GUIDELINES
3.1.1.2 Cable I/O Connector

The female cable plug connector shall be configured as shown in the figure below and Table 3-3:
Cable Connector Dimensions
Shielded Jack (Cable)
A13
A9
A10
A11
A12 A8
A1 0.1 mm s A s
A3 -A-
Pos. # 1
0.1 s B s A20 A21
A14 A4 - B -
A2 0.05mm s B s
A6 A5
A7 0.1 mm s A s
Figure 3-2: Cable Connector
GUIDELINES
Table 3-3: Cable Connector Dimensions

A1 14.6 Max
A2 2.4 Max
A3 12.4 Min
A4 0.8 Min
A5 30° +0, -0.05
A6 0.8 ±0.05
A7 11.2 ±0.1
A8 0.3 ±0.05 Ref
A9 4.5 Max
A10 3.7 ±0.2
A11 0.9 Max
A12 0.25 Ref
A13 3.0 Ref
A14 6.0 Max
3.1.1.3 Key Standards

The dimensions and locations of keys are shown in the figure below and in Table 3-4: Key
Dimensions.
C3 C3
C2
C1 C1
Figure 3-3: Key Size and Locations
Table 3-4: Key Dimensions

C1 4 ±0.1
C2 1.6 ±0.1
C3 0.25±0.05
PHYSICAL GUIDELINES
Three keying configurations are defined, one for LAN and two are reserved for future definition.
Figure 3-4 shows LAN keying.
Figure 3-5 and Figure 3-6 show those reserved for future definition.
LAN PCB Connector LAN Cable Connector
Figure 3-4: Open Standard LAN Connector Key Configuration
Modem Simple PCB Connector Modem Simple Cable Connector
Figure 3-5: Reserved Connector Key Configuation
Modem Multifunctional PCB Connector Modem Multifunctional Cable Connector
Figure 3-6: Reserved Connector Key Configuration
3.1.1.4 Plating
The outermost plating of the connector system contact mating area shall be hardened gold, or
materials compatible with gold.
The outermost plating of the shield shall be nickel plated or other plating material compatible with
nickel. Recommended shield material is stainless steel.
The interconnect system shall pass all requirements of Section 3.1.2, I/O Connector Reliability and
Section 3.1.3, Connector Durability.
3.1.1.5 Test Sequence

The following table defines recommended test sequences. The table assumes 12 test groups, each
represented by a vertical column. One or tests are performed on each group. In a particular column,
the number 1 appears in the row of the test to be executed first, the number 2 in the row of the test
to be executed second and so on.
GUIDELINES
Table 3-5: Recommended Test Sequence

Test Test item Test group
No
1 2 3 4 5 6 7 8 9 10 11 12 13
Test sequence
1 Insulation Resistance 1,7 1
2 Dielectric Withstanding Voltage 2 2
3 Contact Resistance (low level) 1,5 1,4,6,8,10 1,4 3,6 3 1, 1, 1 1,3
5 3
4 Contact Forces 2 2 2
5 Connector Insertion/withdrawal Forces 3 3 3
6 Contact Retention Force 1
7 Durability-Office Environment 4 2
8 -Harsh Environment 5
9 Vibration 2
10 Mechanical Shock 3
11 Humidity (Normal Condition) 7 4
12 Moisture Resistance 4
13 Thermal Shock 5
14 High Termperature Life 4
15 Cold Resistance 2
16 Hydrogen Sulfide 9 2
17 Salt Water Spray 2
18 Current Rating 1
19 Latch Strength 6
20 Mechanical Torque/Flex 1
21 Polarization & Key Force 1,3
3.1.2 I/O Connector Reliability

The I/O interconnect system as specified in Section 3.1.1 shall meet or exceed all reliability test
requirements of this Section. Unless otherwise specified, all test and measurements shall be made
at:
Temperature o o
15 C to 35 C
Relative humidity 25% to 85 %
be:
Temperature o o
23 C + 1 C
Relative humidity 50% + 2%
PHYSICAL GUIDELINES
3.1.2.1 Mechanical Performance

The I/O interconnect system mechanical performance is specified as follows:
3.1.2.1.1 Office Environment

Standard Testing
Guaranteed number of insertions/extractions = 10,000 min. Paragraph 3.1.3.1
3.1.2.1.2 Harsh Environment

Standard Testing
Guaranteed number of insertions/extractions = 5,000 min. Paragraph 3.1.3.2
3.1.2.1.3 Total Insertion Force (with latches disengaged)

Standard Testing
29.4 N6.6 lbs. (3.0 kg) max. Insert at speed of
25.4mm/min
3.1.2.1.4 Total Pulling Force (with latches disengaged)

Standard Testing
1.5 lbs. (0.68 kg) min. Extract at speed of 25.4mm/min
3.1.2.1.5 Single Contact Forces

Standard Testing
Using gauge pin shown below: Insert and extract gauge pin at speed of
25.4mm/min
0.220 lbs. 100 grams max insertion force
0.044 lbs. 20 grams min. extraction force
0.75 ± 0.05
R 0.5 ± 0.1 REF
R0.3
0.40 ± 0.05
Tool steel gauge pin (HRC=50-55, surface finish=
.406mmm max, chamfer all sharp edges)
3.1.2.1.6 Single Contact Holding Force

Standard Testing
Contact shall not be displaced from insulator when a 1 kg Apply a minimum force of 1 kg to the contact in
minimum force is applied to the contact in the axis of both directions along the axis of retention while
retention. holding the insulator rigid.
GUIDELINES
3.1.2.1.7 Vibration
Standard Testing
a. No mechanical damage shall occur on the parts. MIL-STD-202F, Method 204D
b. No current interruption greater than 100 nsec. Test condition B (15 G peak)
c. Contact resistance 3.1.2.2.1b. 10 Hz to 2000 Hz
3.1.2.1.8 Shock
Standard Testing
a. No mechanical damage shall occur on the parts. MIL-STD-202F, Method 213B
b. No current interruption greater than 100 nsec. Acceleration 50G, Standard holding time 6 msec,
Semi-sine wave.
3.1.2.1.9 Latch Retention Force

Standard Testing
12 lbs. (5.5 kg) min Minimum latch retention force before and after
durability (office environment) testing.
3.1.2.1.10 Polarization and Key Force

Standard Testing
13 lbs. (6 kg) minimum, polarization and keys must remain Connector system must not mate when keyed
intact and functionally to this requirement after durability cable plug connector is mismated upside down
testing. to PCB male connector, or with any other
polarization Type, or any other keying standard,
with a force up to 13 lbs.
3.1.2.1.11 Connector Plug Torque and Flex

Standard Testing
a. No mechanical damage shall occur on the parts. 1) Clamp PC Card at I/O connector end, within
b. No current interruption greater than 100 nsec. 50 mm of the card edge15 pin connector end.
Clamp PC Card 2) Apply clockwise torque of 0.226 N-m to the
cable end of the connector, hold at extreme for 5
minutes. Repeat test in counter-clockwise
direction. Repeat 5 times in each direction.
3) Apply upward torque of 0.226 N-m to the cable
end of the connector. Hold for 5 minutes. Repeat
in downward, left and right directions. Repeat 5
B times in all 4 directions.
C
A 4) Apply upward torque of 0.0226 N-m to the
cable end of the connector. Hold for 3 seconds.
PC Card
Repeat in downward, left and right directions.
Repeat 100010,000 times in all 4 directions.
I/O Connector
C B
PHYSICAL GUIDELINES
3.1.2.1.12 Strain Relief

Standard Testing
The strain relief shall be capable of retaining the attaching Clamp connector housing.
cable with no separation or damage to conductor(s),
shielding (if applicable), or insulation when subjected to
force equal or greater than that required to extract the Apply force to cable outward from connector
connector. housing. If cable assembly does not implement
latching mechanism, force shall be 1.6 Kg. If
cable assembly implements latching
mechanism, force shall be 6.4 Kg or the
maximum observed during the tests of
paragraph 3.1.2.1.9.
3.1.2.2 Electrical Performance

The I/O interconnect system electrical performance is specified as follows.
3.1.2.2.1 Contact Resistance (low level)

Standard Testing
a. Initial.....40 mW maximum MIL-STD-1344A, METHOD 3002.1
b. After test...45 mW maximum Open voltage 20 mV
Test current 1 mA
a) Measure and record the initial resistance (Ri)
of the connector system (from attachment of male
connector to the PCB, to the wire of the cable plug
connector):
Ri < 40 mW
b) Measure and record resistance (Rf) of the

connector system after test of the connector
system. Resistance value after test:
Rf < 45 mW
3.1.2.2.2 Withstanding Voltage and Isolation Voltage

Standard Testing
a) No shorting, breakdown, flashover or other damages MIL-STD-202F, METHOD 301,
when 1000 Vrms AC is applied for 1 minute between measured between adjacent contacts, and
adjacent contacts or from each contact to shell. measured from contact to shell
b) Current leakage 1 mA max.
3.1.2.2.3 Insulation Resistance

Standard Testing
a. Initial........1,000 MW min. MIL-STD-202F, METHOD 301
b. After test.......100 MW min. Measure within 1 minute after applying 500 V
DC
GUIDELINES
3.1.2.2.4 Current Capacity

Standard Testing
0.5 A per contact o
20 C max temp rise over ambient at rated
current
3.1.2.2.5 Insulation Material

Standard Testing
UL 94 V-0 rated material in thickness used Per UL Specification 94
3.1.2.3 Environmental Performance
3.1.2.3.1 Operating Environment

Standard
o o
Operating Temperature: -20 C to + 60 C
Relative Humidity: 95% Max. (non-condensing)
3.1.2.3.2 Storage Environment

Standard
o o
Operating Temperature: -20 C to + 70 C
Relative Humidity: 95% Max. (non-condensing)
3.1.2.4 Environmental Resistance
3.1.2.4.1 Moisture Resistance

Standard Testing
Contact resistance: 3.1.2.2.1 MIL-STD-202F, METHOD 106E
(excluding vibration)
Insulation resistance: 3.1.2.2.3 b.
10 cycles (1 cycle=24 hours) with connector
system mated
3.1.2.4.2 Thermal Shock

Standard Testing
No physical damage shall occur during testing MIL-STD-202F, METHOD 107G
Contact resistance: 3.1.2.2.1 o o
Test condition A, -55 C to + 70 C
Insulation resistance: 3.1.2.2.3 b. 5 cycles (1 cycle=1 hours) with connector
system mated
3.1.2.4.3 Durability (High Temperature)

Standard Testing
Contact resistance: 3.1.2.2.1 b. MIL-STD-202F, METHOD 108A
o
Test Condition B, 70 C, 250 hours min. with
connector system mated
PHYSICAL GUIDELINES
3.1.2.4.4 Humidity (Normal Condition)

Standard Testing
Contact resistance: 3.1.2.2.1 MIL-STD-202F, METHOD 103B
Insulation resistance: 3.1.2.2.3 b . o
Test Condition B, 40 C , 90 to 95% RH with
connector system mated
3.1.2.4.5 Mixed Flowing Gases

Standard Testing
No visible corrosion under 3X magnification EIA-364-65 (TP-65), Class II environment for 48
hours after stablization. Performed with 50% of
Contact resistance: 3.1.2.2.1 except max. increase to be 20
test group connectors mated; rest unmated.
mW above initial measurement
Measurement made on 100% of contacts on all
connectors in test group.
3.1.2.4.6 Salt Water Spray

Standard Testing
No harmful corrosion (or degradation of contact MIL-STD-202F, METHOD 101D
performance) should occur on the contacts. Test condition B, Concentration 5%
Contact resistance 3.1.2.2.1 o
35 C, 48 hours min., with connectors unmated
3.1.3 Connector Durability

The I/O interconnect system as specified in Section 3.1.1 shall meet or exceed all durability
requirements of this subsection.
Cycle rate 400-600 cycles per hour

Temperature o o
15 C to 35 C
3.1.3.1 Office Environment

The office environment is defined in EIA-364A as class 1.1 - year round air conditioning (non-
filtered) with humidity control.
Test sequence:
Contact resistance per 3.1.2.2.1 a.

Mate and unmate the connector for a total of 10,000 cycles
Contact resistance per 3.1.2.2.1 b.
GUIDELINES
3.1.3.2 Harsh Environment

The harsh environment is defined in EIA-364A as class 1.3 ¾ no air conditioning, no humidity with
normal heating and ventilation.
Test sequence:
Contact resistance per 3.1.2.2.1. a.

Mate and unmate the connector 1,000 cycles total cycles = 1,000 cycles
Humidity per 3.1.2.4.4
Mixed Flowing Gases per 3.1.2.4.5
3.1.4 PC Card LAN 15 Position I/O Connectivity

This recommendation defines the pinout for LAN PC Cards. Several specific pinouts are defined,
each serving a different technology or technology-media combination. All assume the use the same
physical connector and keying shown for LAN in Figure 3-1, Figure 3-2, and Figure 3-3. All Open
System LAN PC Cards use the common 15 pin I/O connector. The same swap cable assembly works
with two popular network configurations, Ethernet 10BASE-T and Token Ring UTP. Pin
assignments are chosen so that accidental connection of an open standard LAN card to a different
technology network will not cause damage to the card or the network.
The option is provided to power external transcievers through the PC Card. This simplifies some
configurations. The option is also provided to power the PC Card from an external supply allowing
LAN cards to be utilized in very low power platforms. Two status LEDs can be powered through
the cable assembly.
PHYSICAL GUIDELINES
3.1.4.1 Connector Pinout Configurations

The pinouts defined for Open System LAN I/O Connector are shown in the following tables.
Table 3-6: Ethernet with AUI and 10BaseT

Pin Signal Description
1 10BASE-T receive, negative phase
2 10BASE-T receive, positive phase
3 Power into PC card from external supply
4 AUI receive, negative phase
5 AUI receive, positive phase
6 10BASE-T link status LED
7 Cable activity (receive) status LED
8 AUI transmit, negative phase
9 AUI transmit, positive phase
10 Power out of PC card to external modules
11 AUI collision input negative phase
12 AUI collision input positive phase
13 Ground
14 10BASE-T transmit, negative phase
15 10BASE-T transmit, positive phase
Table 3-7: Ethernet with AUI and 10 Base 2

1 Not connected
2 Not connected
4 AUI receive, negative phase
5 AUI receive, positive phase
6 Transmit status LED
8 AUI transmit, negative phase
9 AUI transmit, positive phase
11 AUI collision input negative phase
12 AUI collision input positive phase
13 Ground
14 10BASE-2 coax shield
15 10BASE-2 coax center conductor
GUIDELINES
Table 3-8: Token Ring UTP and STP

1 UTP transmit, negative phase
2 UTP transmit, positive phase
4 STP receive, negative phase
5 STP receive, positive phase
7 Receive status LED
8 Not connected
9 Not connected
11 UTP receive, negative phase
12 UTP receive, positive phase
13 Ground
14 STP transmit, negative phase
15 STP transmit, positive phase
Table 3-9: ARCNET with UTP and Coax

1 Not connected
2 Not connected
4 Not connected
5 Not connected
8 UTP negative phase
9 UTP positive phase
11 Not connected
12 Not connected
13 Ground
14 Coax shield
15 Coax center conductor
PHYSICAL GUIDELINES
Table 3-10: ATM

1 UTP transmit, negative phase
2 UTP transmit, positive phase
4 External transmit, negative phase
5 External transmit, positive phase
6 link status LED
8 External receive, negative phase
9 External receive, positive phase
11 External Signal Detect, negative phase
12 External Signal Detect, positive phase
13 Ground
14 UTP receive, negative phase
15 UTP receive, positive phase
3.1.4.2 Common Mode Note

There is an issue which must be considered regarding pins 11, 12. It is physically possible via a
standard swap cable to connect these, accidentally, to a Token Ring MAU. The IEEE 802
specification indicates that such a cable connection must be able to sustain high common mode
voltages without damage. Solutions to this problem are implementation specific. One solution is to
provide an isolated receiver as is in 802.3 ethernet coax transceivers. Since this is only a receiver,
the power requirements are very low and implementations should be low cost.
3.1.4.3 Cable Assembly Notes

The PC Card LAN pinout assignments specified in this document allow for several levels of
functionality in cable assemblies. For example, the cable assembly shown in the following table
would connect any Pinout Configuration 1 PC card to an Ethernet 10BASE-T concentrator or any
Pinout Configuration 3 PC Card to a Token Ring MAU.
PC Card Connector Pin RJ45 Connector Pin
1 Twisted 3
2 Pair 6
11 Twisted 4
12 Pair 5
14 Twisted 1
15 Pair 2
GUIDELINES
Adding LEDs to the external box or molding which houses the RJ45 connector and utilizing PC
Card connector pins 6, 7 and 13 according to the following table adds additional value to the cable
assembly.
PC Card Connector Pin External Module
6 Single Conductor Link/Transmit LED
7 Single Conductor Receive LED
13 Single Conductor Ground Returns From Both LEDs
Utilizing PC Card pins 3, 10 and 13 adds value to the cable assembly by allowing for power from
the PC Card to an external module (for example, to power an Ethernet AUI to 10BASE-2 transceiver)
and/or power from an external power source into the PC Card (for example, to power the PC Card
in a low power palmtop PC). Connections for this are shown in the following table.
PC CARD CONNECTOR PIN EXTERNAL MODULE
3 Single Conductor External Module Power Input
10 Single Conductor External Power Source
13 Single Conductor Ground
PHYSICAL GUIDELINES
3.2 Modem I/O Unshielded Connector for Open Systems
3.2.1 Introduction
3.2.1.1 Purpose
This document describes connectors suitable for use as external input/output interface from PC
Cards used for Modem, FAX, voice and audio applications in accordance with applicable PC Card
standards. Applicable cards are those which adhere to the Open Standard for I/O Interconnection.
Applications and testing are based upon "harsh environments."
3.2.1.2 Scope
3.2.1.2.1 Modem/FAX Cards

The intent of this document is to provide sufficient information for Modem/FAX, I/O Card
Developers to design such devices for use with external media access devices by using common
connectors and interface. This document describes connectors suitable for use with Type II and Type
III Modem/FAX PC Cards incorporating internal DAAs. Also supported are Modem/FAX PC Cards
incorporating audio features which interface to external audio devices having speaker and
microphone capabilities. It is intended to allow such Modem/FAX PC Cards to use cables involving
connectors described herein, interchangeably without concern for physical or electrical damage,
when properly applied. PC Card Standard specified Signal-Contact interconnection assignments
shall be according to Section 3.2.7 herein.
3.2.1.2.2 Connectors
This document is intended to provide sufficient information of applicable mechanical and interface
parameters involved with the use and selection of the connectors described herein. This specification
covers only information that is applicable to the mating interface and is not intended to be a
complete product specification.
GUIDELINES
3.2.2 Overview
The potential proliferation of modems and specialized communications cards, all based upon the PC
Card Standard, has lead to a need for standardization on connectors for direct connection between
the PC Card and various media.
In order to assure that any I/O Card could have any access devices connected without harm, the
Open Connector concept allows for the definition of interface signal levels and mechanical
parameters to assure that different PC Card form factors are not subject to damage when properly
terminated with the connectors herein.
It is accepted that vendors may wish to have different interconnection schemes that would function
properly only when interconnect components of their specific choice are used. These are termed
"closed systems." Interchangeability with respect to cabling and the mechanical I/O interface of the
modem cards (per this specification) is not expected nor desired. Vendors using such "closed
systems" are instructed to not use the connectors described in this specification so that potentially
destructive interface problems will be prevented.
Since PC Cards used for Modem applications may be used in non-office environments as part of
mobile operating systems, testing herein is based upon standards for "harsh environments" as
defined by the PC Card Standard.
This specification gives several options to designers and users of PC Card modems. The "minimum
interface" presents a standardization of a 4 position connector for applications wherein only one type
of simple interface is desired. The "maximum interface" connector provides a split-insert, in two
sections, with 4 and 3 contacts respectively. This maximum interface connector can receive a cable
with a 4 position plug for one type of interface, or it can receive a separate cable with a 3 position
plug for another type of interface. If a more complicated interconnection is required, a third cable
having 7-positions may be used. It is expected that all PC Card Standard compliant cards for
Modem/FAX applications will have either a 4 or 7 position card connector installed at the end of the
card opposite that which is inserted into the host's socket.
Due to expected structural constraints of applicable PC Card modems, the connectors defined herein
are suitable for all PC Cards except the thinner Type I. Wherever applicable, illustrations and
testing discussed in this specification shall incorporate Type II PC Cards.
Current Modem and Modem/FAX Card applications do not require use of shielded cables.
Therefore, for economical benefits, connectors described herein are not intended for use with
shielded cables or shell-to-case grounds. Connectors for Local Area Network applications may need
to be shielded and may be described by other PC Card specifications.
The "open system" compliance presented herein does not guarantee interoperability of independent
implementation schemes, nor does it guarantee certifiability to any external (non-PCMCIA/JEIDA)
criteria such as FCC, UL or the like. However, it does prevent mechanical damage associated with
inadvertent interconnection. "Open system interconnection" facilitates uniform interfaces for PC
Card Developers by promoting availability of multi-sourced I/O connectors satisfying the PC Card
Standard's criteria per this specification.
PHYSICAL GUIDELINES
3.2.3 Connector Physical
3.2.3.1 Card I/O Connectors

The "minimum interface" 4 position connector is shown in Figure 3-7: Card I/O Connector, 4
Position with dimensions per Table 3-11: Card I/O Connector Dimensions. The "maximum
interface" 7 position connector is shown in Figure 3-8: Card I/O Connector, 7 Position with
dimensions also per Table 3-11.
Card I/O Connector, 4 position per Figure 3-7: Card I/O Connector, 4 Position.
Card I/O Connector, 7 position per Figure 3-8: Card I/O Connector, 7 Position.
Card I/O Connector dimensions per Figure 3-11: Cable Plug Connector, 7 Position.
3.2.3.2 Cable Plug Connectors
3.2.3.2.1 Identification
Cable Plug Connector, 3 position per Figure 3-9: Cable Plug Connector, 3 Position.
Cable Plug Connector dimensions per Table 3-12: Cable I/O Connector Dimensions.
3.2.3.2.2 Reservations
Use of the 7 position and 3 position cable plugs with the 7 position card I/O receptacle are reserved
for future circuit definition(s).
GUIDELINES
3.2.3.2.3 Card I/O Connector
Figure 3-7: Card I/O Connector, 4 Position
Table 3-11: Card I/O Connector Dimensions

4 Position 7 Position
Dimension Millimeters Inches Millimeters Inches
A1 16.4 ± 0.2 .646 ± .008 24 ± 0.2 .945 ± .008
A2 15.4 ± 0.2 .606 ± .008 23 ± 0.2 .906 ± .008
A3 12.4 +0 .488 +0 20 +0 .787 +0
-0.1 -.004 -0.1 -.004
A4 3 ± 0.15 .118 ± .006 11 ± 0.15 .433 ± .006
A5 1 ± 0.05 .039 ± .002 1 ± 0.05 .039 ± .002
A6 (6) (.236) (6) (.236)
A7 3.7 ± 0.2 .146 ± .008 3.7 ± 0.2 .146 ± .008
A8 2.3 ± 0.1 .090 ± .004 2.3 ± 0.1 .090 ± .004
A9 3.7 +0 .146 + 0 3.7 + 0 .146 + 0
-0.1 -.004 -0.1 -.004
A10 3 + 0 .118 + 0 3 + 0 .118 + 0
-0.1 -.004 -0.1 -.004
A11 1.2 ± 0.1 .047 ± .004 1.2 ± 0.1 .047 ± .004
A12 3.45 ± 0.1 .136 ± .004 3.45 ± 0.1 .136 ± .004
Note: Figures in brackets ( ) are Òreference.Ó
PHYSICAL GUIDELINES
Figure 3-8: Card I/O Connector, 7 Position
GUIDELINES
3.2.3.2.4 Cable Plug Connector
Figure 3-9: Cable Plug Connector, 3 Position
PHYSICAL GUIDELINES
Table 3-12: Cable I/O Connector Dimensions

3 Position 4 Position 7 Position
Dimension Millimeters Inches Millimeters Inches Millimeters Inches
B1 15.0 ± 0.3 .590 ± .012 15.0 ± 0.3 .590 ± .012 24.5 ± 0.3 .590 ± .012
B2 1.0 ± 0.1 .039 ± .004 1.0 ± 0.1 .039 ± .004 1.0 ± 0.1 .039 ± .004
B3 2.00 ± 0.15 .079 ± .006 3.00 ± 0.15 .118 ± .006 11.00 ± 0.15 .433 ± .006
B4 5.00 +0 .197 +0 5.00 + 0 .197 + 0 5.00 + 0 .197 + 0
-0.25 -.010 -0.25 -.010 -0.25 -.010
B5 9.80 ± 0.15 .386 ± .006 10.80 ± 0.15 .425 ± .006 18.4 ± 0.15 .724 ± .006
B6 4.8 ± 0.1 .189 ± .004 4.8 ± 0.1 .189 ± .004 4.8 ± 0.1 .189 ± .004
B7 2.40 ± 0.05 .094 ± .002 2.40 ± 0.05 .094 ± .002 2.4 ± 0.05 .094 ± .002
B8 1.20 ± 0.05 .047 ± .002 1.20 ± 0.05 .047 ± .002 1.20 ± 0.05 .047 ± .002
B9 2.7 ± 0.1 .106 ± .004 2.7 ± 0.1 .106 ± .004 2.7 ± 0.1 .106 ± .004
GUIDELINES
PHYSICAL GUIDELINES
3.2.3.3 Materials and Finishes
3.2.3.3.1 Insulators
Materials shall be suitable for the purposes intended including the following:
Material: Shall be UL approved.
Flammability: Per UL94V-0.
PWB termination: Card Connectors shall be suitable for Surface Mounting, including (but not
limited to) IR at 250 C for 10 seconds, without damage.
3.2.3.3.2 Contacts
3.2.3.3.2.1 Materials
Shall be suitable for the purposes intended.
3.2.3.3.2.2 Plating and Finish

Contact plating in engaging areas shall be nickel-palladium alloy with gold flash overplate, with
suitable underplate. Plating of terminals on the card connectors shall be suitable for reflow
mounting. Wire termination portions of the cable plugs shall be suitably plated using materials that
are compatible with plating materials elsewhere on the contact. If lubrication is applied, it shall be
per EIA CB14; lubricated contacts are required to pass the same test requirement as non-lubricated
contacts.
3.2.3.4 Polarization
Alternate polarizations are not included within this specification. Connector versions similar to those
per this specification that differ only by schemes of alternate polarization of keying are deemed to
be in non-conformance with this specification. Such connectors are not suitable for the "open system"
interface intentions of this specification. This is a different criteria than that applicable to "mis-
mating" which is specified herein.
3.2.4 Test and Performance Criteria
3.2.4.1 Test Sequence

Table 3-14 defines Test Sequence. There are 17 Test Groups. Connectors per each Test Group are per
the table below.
Table 3-13: Connectors Per Test Group

Group No: 1 through 11 12 and 13 14 and 15 16 and 17
Quantity Pairs 6 4 4 4
Size, Card 7-position 7-position 7-position 4-position
Connector
Size, Cable 7-position 4-position 3-position 4-position
Connector
GUIDELINES
Table 3-14: Test Sequence

Test Item Test Group
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 Ref. Para
7 No.
Test Sequence
1 Insulation Resistance 1, 1 1 1 3.2.4.4.3
7
2 Dielectric Withstanding 2 2 2 2 3.2.4.4.2
Voltage
3 Contact Resistance 1, 1, 1, 3, 3, 1, 1, 1, 1 1,3, 1,3 1,3 1,3 3,6 3,8 1, 3.2.4.4.1
(low level) 5 4, 4 6 5 5 3 3 5 ,5 3
6,
8
4 Contact Forces 2 2 2 4 4 3.2.4.3.5
5 Contact Insertion/ 3 3 3 2 2 2 5 4 3.2.4.3.3
Withdrawal Forces 3.2.4.3.4
6 Contact Retention 1 5 3.2.4.3.6
Force
7 Durability - Office 4 4 2 3.2.4.6.1
Environment
8 Durability - Harsh 5 3.2.4.6.2
Environment
9 Vibration 2 3.2.4.3.7
10 Mechanical Shock 3 3.2.4.3.8
11 Humidity (Normal 7 4 3.2.4.5.5
Condition)
12 Moisture Resistance 4 3.2.4.5.2
13 Thermal Shock 5 3.2.4.5.3
14 High Temperature Life 4 3.2.4.5.4
15 Cable Strain Relief 4 3.2.4.3.11
16 Mixed Flowing Gases 2 3.2.4.5.6
17 Current Rating 2 3.2.4.4.4
(capacity)
18 Inverse Mating 6 3 4 6 3.2.4.3.9
19 Mechanical Torque/ 4 2 7 3.2.4.3.10
Flex
20 High Voltage Common 2 3.2.4.4.6
Mode Isolation
Note: Each test group is represented by its own vertical column. In each column, the sequence of test(s) to be
performed is indicated by the number 1,2,3, and so forth which indicates the order involved.
PHYSICAL GUIDELINES
3.2.4.2 Standard Test Conditions

The I/O interconnect system as specified in Section 3.2.3 shall meet or exceed all reliability test
requirements of this subsection. Unless otherwise specified, all tests and measurements shall be
made at:
Temperature 15 °C to 35 °C
be:
Temperature 23°C ± 1C
Relative humidity 50% ± 2%
GUIDELINES
3.2.4.3 Mechanical Performance Criteria Tests

Mechanical performance criteria are as follows, based upon testing per Table 3-14: Test Sequence.

Standard Test
Guaranteed number of insertions/extractions = 10,000 minimum Paragraph 3.2.4.6.1.

Standard Test
Guaranteed number of insertions/extractions = 5,000 minimum a. Paragraph 3.2.4.3.2.
b. Paragraph 3.2.4.5.6.
3.2.4.3.3 Total Insertion Force

Standard Test
6.6 lb. (3.0 kg) maximum Insertion speed: 2.54 cm/minute
3.2.4.3.4 Total Withdrawal Force

Standard Test
0.5 kg minimum 7 position to 7 position Extraction speed:
2.54Êcm/minute
0.3 kg minimum all others
3.2.4.3.5 Single Contact Forces

Standard Test
Using a gauge pin as shown below: Insert and extract gauge pin at a
speed of 2.54 cm/minute.
100 grams maximum insertion force.
Perform on 2 contacts per each
15 grams maximum extraction force.
card and cable/plug connector,
per test groups. Contacts to be
non-adjacent.
0.50 ± 0.05
1.40 ± 0.10
R 2.00 ± 0.05
Tool steel gauge pin (surface finish .406mm max., chamfer all sharp edges).
3.2.4.3.6 Single Contact Retention Forces

Standard Test
Contact shall not be displaced from insulator when a 0.5 kg minimum force is Apply a minimum force of 0.5 kg
applied to the contact in the axis of retention. to the contact in both directions
along the axis of retention while
holding the insulator rigid
PHYSICAL GUIDELINES
3.2.4.3.7 Vibration
Standard Test
a. No mechanical defects shall occur on the parts. MIL-STD-202F, Method 204D,
Test condition B (15G peak), 10
b. No current interruption greater than 100 ns.
Hz to 2000 Hz.
c. Contact resistance per 3.2.4.4.1
3.2.4.3.8 Shock
Standard Test
a. No mechanical damage shall occur on the parts. MIL-STD-202F, Method 213B,
Acceleration 50G, Standard
b. No current interruption greater than 100 ns.
holding time 6 msec., Half-sine
wave.
3.2.4.3.9 Inverse Mating

Standard Test
Connector shells (polarization) must remain intact and functional to this Connector system must not
requirement after durability testing. mate when cable plug connector
is mis-mated upside down to
7 position mated to 7 position @ 6 kg
card I/O connector, for 1 minute.
3 or 4 position mated to 7 position @ 3 kg Repeat 5 times.
4 position mated to 4 position @ 3 kg
Note: Connectors shall pass if 3 or 4 position shells yield when mated to 7
position, provided that 7 position connector is not affected.
3.2.4.3.10 Connector Plug Torque and Flex

Standard Test
a. No mechanical damage shall occur on the parts. 1. Clamp PC Card at I/O
connector end, within 5 cm of the
b. No current interruption greater than 100 nsec.
card edge. I/O connector pair
shall be mated per Table 3.
2. Apply clockwise torque of 0.23
N to the cabled end of the
connector, hold at extreme for 5
minutes. Repeat test in counter-
A clockwise direction. Repeat 5
times in each direction.
B C
3. Apply upward torque of 0.23 N
to the cable end of the connector.
Hold for 5 minutes. Repeat in the
downward, left and right
PC Card
directions. Repeat 5 times in all
4 directions.
4. Apply upward torque of 0.23 N
I/O Connector B A l to the cable end of the connector.
C
Hold for 3 seconds. Repeat in the
downward, left and right
directions. Repeat 1,000 times in
Torque Requirements: all 4 directions.
Mated 7 position pair @ 0.23 N.

Mated 3 or 4 position to 7 position or mated 4 position pair @ 0.11 N
GUIDELINES
3.2.4.3.11 Strain Relief

Standard Test
The strain relief shall be capable of retaining the attached cable with no Clamp connector housing.
separation or damage to conductor(s), shielding (if applicable), or insulation. Apply force to cable outward
Connector shall be terminated with strain relief in manner used for standard from connector housing.
production
Force shall be 6.4 kg for 5
minutes.
3.2.4.4 Electrical Performance Criteria

Electrical criteria, for testing per Table 3-14: Test Sequence, are as follows:
3.2.4.4.1 Contact Resistance (low level)

Standard Test
a. Initial...40 mW maximum. MIL-STD-1344A, Method 3002.1,
Open voltage 20 mV. Test
b. After Test...45 mW maximum.
current: 1 mA.
c. Contact resistance increase shall not exceed 20 mW total.
a. Measure and record the initial
resistance (R1) of the connector
system (from attachment of
male connector to the PCB, to
the wire of the cable plug
connector).
R1 £40 mW
b. Measure and record

resistance (Rf) of the connector
system after test of the connector
system. Resistance value after
test:
Rf £45 mW
3.2.4.4.2 Dielectric Withstanding Voltage

Standard Test
a. No shorting, breakdown, flash-over or other damage when 600 Vrms ac is MIL-STD-202F, Method 301,
applied for 1 minute. measured between adjacent
contacts.
b. Current leakage 1mA maximum.
3.2.4.4.3 Insulation Resistance

Standard Test
a. Initial......1,000 MW minimum. MIL-STD-202F, Method 302,
measured within 1 minute after
b. After test...100 MW minimum.
applying 250 Vdc.
3.2.4.4.4 Current Capacity

Standard Test
0.5 A per contact. 20 °C maximum Temperature
rise over ambient at rated
current.
PHYSICAL GUIDELINES
3.2.4.4.5 Insulation Material

Standard
UL94V-O rated material in thickness used.
3.2.4.4.6 High Voltage Common Mode Isolation

Standard Test
No arcing, 10 mA AC rms maximum current to 3750 V rms. IEC 950, Section 5.3.2. except
test to 4125 V rms, minimum.
(sea level conditions).
3.2.4.5 Environmental Performance Criteria
3.2.4.5.1 Environmental Conditions

Operating Temperature Range -20oC to +60oC
Storage Temperature Range -20oC to +70oC
Relative Humidity 95% maximum
(non-condensing)
3.2.4.5.2 Moisture Resistance

Standard Test
Contact Resistance: 3.2.4.4.1. MIL-STD-202F, Method 106E
(excluding vibration); 10 cycles
Insulation Resistance: 3.2.4.4.3.
(1 cycle = 24 hours) with
connector system mated.
3.2.4.5.3 Thermal Shock

Standard Test
No physical damage shall occur during testing. MIL-STD-202F, Method 107G,
Test condition A,
Contact resistance: 3.2.4.4.1.
-55oC to +70oC, 5 cycles (1
Insulation resistance: 3.2.4.4.3. cycle = 1 hour) with connector
mated.
3.2.4.5.4 Durability (High Temperature)

Standard Test
Contact resistance: 3.2.4.4.1. MIL-STD-202F, Method 108A,
Test condition B, +70oC, 250
hours minimum, with connector
mated.
GUIDELINES
3.2.4.5.5 Humidity (Normal Condition)

Standard Test
Contact resistance: 3.2.4.4.1. MIL-STD-202F, Method 103B,
Insulation resistance: 3.2.4.4.3. Test condition B, +40oC, 90% to
95 % RH, with connector mated.
3.2.4.5.6 Mixed Flowing Gas

Standard Test
a. No visible corrosion under 3X magnification. EIA-364-65 (TP-65), Class II
environment for 48 hours after
b. Low level contact resistance per 3.2.4.4.1. except maximum increase to be
stabilization. Performed with
20 mW above initial measurements.
50% of test group connectors
mated; rest unmated.
Measurements made on 100% of
contacts (all connectors per
group).
3.2.4.6 Durability Mating Requirements

The I/O interconnect system as specified in Section 3.2.3 shall meet or exceed all durability
requirements of the subsection.
Cycle rate 400-600 cycles per hour

Temperature 15 °C to 35 °C
Relative Humidity (RH) 25% to 85%

The office environment as defined in EIA-364 B as Class 1.1, year round air conditioning
(nonfiltered) with humidity control.
Test Sequence:
Contact resistance per 3.2.4.4.1.

Mate and unmate the connector for a total of 10,000 cycles.
PHYSICAL GUIDELINES

The harsh environment as defined in EIA-364B as Class 1.3, is no air conditioning, no humidity
control with normal heating and ventilation, plus consideration for industrial environment
conditions.
Test Sequence:

Mate and unmate the connector for a total of 1,000 cycles. Total cycles = 1,000 cycles
Humidity per 3.2.4.5.5.
Humidity per 3.2.4.5.5.
Separate Test Sequence:

Mixed Flowing Gas per 3.2.4.5.6.
GUIDELINES
3.2.5 Contact Position Assignment

Contact position assignments shall conform to paragraph 3.2.5.1. Card Jack and Plug connectors
shall be marked to identify contact locations as follows: for 7 position PC Cards: 1, 4, 5 and 7; 4
position PC Cards: 1 and 4: 3 position PC Cards (plug only): 5 and 7. Refer to Section 3.2.7 for
application specific Signal-Contact interconnection assignments.
3.2.5.1 Contact Position Marking

Contact position shall be clearly marked as to be visible to the user.
3.2.5.2 Cable Interconnections

Four basic cable types may be configured based upon the three plug connector types. All physical
wiring interconnections are to be point-to-point. In all cases, the Òcontact position assignmentsÓ shall
be per the applicable Òbasic cablesÓ shown below. Information regarding application parameters are
included in Section 3.2.7.1. Cable types shall be as defined in the following table.
Table 3-15: Cable Type, Point-to-Point Wiring Physical Definition

Cable Type Receptacle (Card side) Plug (Cable side)
TYPE A 1 1
7 pos. plug to 2 2
7 pos. card 3 3
4 4
5 5
6 6
7 7
TYPE B 1 1
4 pos. plug to 2 2
7 pos. card 3 3
4 4
5 NC
6 NC
7 NC
TYPE B.2 1 1
4 pos. plug to 2 2
4 pos. card 3 3
4 4
TYPE C 1 NC
3 pos. plug to 2 NC
7 pos. card 3 NC
4 NC
5 5
6 6
7 7
Note: "NC" indicates "No Connection."
PHYSICAL GUIDELINES
3.2.6 Intermatability
Intermateability between manufacturers shall be confirmed by the use of 50% of connectors from
other manufacturer(s) during testing of Group 2, 5, 7, 8, 10, 14, and 16. This shall involve both card
and cable connectors from all manufacturers. This may be done as part of the manufacturer's
standard qualification tests.
3.2.6.1 Intermateability Assurance

It shall be the responsibility of each manufacturer to confirm intermateability. By reference to this
document, PCMCIA is presenting an "open-system" interface to permit interchangeability of
components between suppliers. Due to the options that may be exercised by various manufacturers,
PCMCIA does not define this interface beyond the limited criteria set forth by this document.
GUIDELINES
3.2.7 PC Card Modem 4 Pin I/O for PSTN Connectivity

This recommendation defines the pinout of a 4 pin I/O connector for use in PC Card modems
equipped with internal DAAs and connecting directly to the Public Switched Telephone Network
(PSTN) and which are intended for approval in the United States and Canada. It assumes the use of
the 4 pin I/O connector defined in Section 3.2.3 of this Standard. PC Card Modems equipped with
this connector require only a cable to attach to the customer premise modular RJ11 Telephone Jack.
It defines the use of a four position connector on the PC Card modem and a Telco cable which
connects pins 2 and 3 of the 4 pin mating plug to pins 3 and 4 of a modular RJ11 plug. Simultaneous
connection of the modem to the teleco and to a local handset can be accomplished by providing a
cable assembly which connects pins 2 and 3 of a 4 pin mating plug to pins 3 and 4 of a modular
RJ11 plug and connects pins 1 and 4 of the same 4 pin mating plug to pins 3 and 4 of a second
modular RJ11 plug. By following this recommendation, it is possible to create unique standard cable
assemblies that provide one or both of the functions listed above.
3.2.7.1 Pinout Configuration for 4 Pin PC Card Modem I/O Connector

The pinout defined for Modem connector is shown in the table below.
Table 3-16: 4 Pin PC Card Modem I/O Connector Pinouts

Pin Signal I/O Function +/-
1 Tip 1 Analog The tip signal to the teleset Balanced
2 T Analog The tip signal normally connecting to pin 3 of the RJ11 Plug Balanced
3 R Analog The ring signal normally connecting to pin 4 of the RJ11 Plug Balanced
4 Ring 1 Analog The ring signal to the teleset Balanced
3.2.8 PC Card Modem 7 Pin I/O with Audio Interface

This recommendation defines the pinout of a 7 pin I/O connector for use in PC Card modems (as
defined in Section 3.7 of this Standard) and includes the definition of an interface appropriate for use
with an audio device. It assumes the use of the 7 pin I/O connector defined in Section 3.3 of this
Standard. PC Card Modems equipped with this connector require only a cable to attach to the
customer premise modular RJ11 Telephone Jack for PSTN connectivity in the manner defined in
Section 3.7 as applied to the 4 pin section of the 7 pin connector. The 3 pin section of the connector is
defined for use with commonly available audio headsets, but could just as well be interfaced to a
non-headset style appliance duplicating the expected audio input and output functions.
This audio interface is defined to support modem-based voice and business audio applications
including hands-free phone, telephone answering machine (TAM), simultaneous or alternating
voice/data (SAVD), voice annotation, and presentation audio applications. Although this interface
is intended primarily for audio headset applications, it is also applicable as an interface to an
externally powered speaker/mic accessory and thus also useable for group applications including
speakerphone and business presentations.
3.2.8.1 Pinout Configuration for 7 Pin PC Card Modem I/O Connector

The pinout defined for Modem with Audio connector is shown in the table below. This pinout
supports having an audio interface in addition to the modemÕs PSTN interface. Regarding the
PHYSICAL GUIDELINES
audio interface portion of the pinout, refer to Section 3.2.8.2 Electrical Characteristics for the Audio
Interface for a definition of the electrical characteristics.
Table 3-17: 7 Pin PC Card Modem I/O Connector Pinouts

Pin Signal I/O Function +/-
1 Tip 1 Analog The tip signal to the teleset Balanced
2 T Analog The tip signal normally connecting to pin 3 of the RJ11 Plug Balanced
3 R Analog The ring signal normally connecting to pin 4 of the RJ11 Plug Balanced
4 Ring 1 Analog The ring signal to the teleset Balanced
5 Audio Out Analog The audio signal to be sent to a speaker +
6 Return Analog Return path for both audio in and out signals Ground
7 Audio In Analog The audio signal to be supplied by a microphone +
3.2.8.2 Electrical Characteristics for the Audio Interface

The following electrical characteristics are defined for each of the audio signals.
Audio Output (speaker): Series Resistance = 10 ohms (minimum, for current limiting);
capable of driving up to 1.0 volt peak-to-peak into a speaker load
of 100 ohms.
Audio Input (microphone): The microphone is anticipated to be electret, therefore the audio
input will require a bias circuit, an example of which is shown in
Figure 3-12: Microphone Input with Bias Supply. The
microphone input should be capable of accepting voltage peak-to-
peak inputs ranging from 10 mv to 1000 mv. The recommended
minimum input frequency range of the preamp is 300 Hz to 3
kHz. To reduce noise, it is strongly recommended that the bias
voltage be decoupled as shown in the example figure.
As microphone input levels will vary with different headsets, it is
recommended that the preamp section for the microphone input
have a method for adjusting the gain to optimize sound levels
over the voltage peak-to-peak range indicated above.
Audio Return: Tied directly to the PC CardÕs signal ground.
GUIDELINES
Vcc
1K
10 µF
5.6 K FOR Vcc = 5V
(3.3 K FOR Vcc = 3.3V)
MIC INPUT TO PREAMP
Figure 3-12: Microphone Input with Bias Supply
PHYSICAL GUIDELINES
3.3 Guideline for Maximum Dimensions for I/O Connectors
3.3.1 Background
Although many kinds of I/O connectors are available on the market, there are no limitations on
I/O connector dimensions, making PC Card slot designs difficult. This guideline describes the
recommendation for Maximum dimensions for an I/O connector. Taking into consideration the
maximum dimensions for an I/O connector helps the design of both PC Card Slot bezels and new
I/O connectors.
3.3.2 Guideline
The following dimensions, A to E for I/O connector are shown in Figure 3-13: Maximum Dimensions
for I/O Connector below.
Note: This Guideline takes into consideration single PC Card Slots only. For
multiple PC Card Slots, you need to consider appropriate numbers for B1,
B2, C and D.
A: PC Card I/O connector length within PC system enclosure area.

B1, B2: PC Card I/O connector height in enclosure area referenced to centerline
of PC Card.
C, D : PC Card I/O connector cabled plug height external to system enclosure
area referenced to centerline of PC Card.
E: Width of PC Card I/O connector within system enclosure area A.
GUIDELINES
Cable
A=6.0 min
I/O CARD (Top side)

C=8.0 max
B1=5.0 max
B2= 2.75 max

D = 5.0 max
I/O CONNECTOR BOTTOM SURFACE
SYSTEM'S ENCLOSURE
CONTACT PORTION
( SLOT BEZEL )
E = 54.1 max
I/O CONNECTOR TOP SURFACE

I/O CARD
CABLE
Unit: mm
I/O CARD SLOT SYSTEM'S ENCLOSURE(SLOT BEZEL)
Figure 3-13: Maximum Dimensions for I/O Connector

Note: This figure defines single slot only.
PHYSICAL GUIDELINES
3.4 Extended PC Card Guideline
3.4.1 Summary
The Type I and II Extended PC Card outlines are identical to the Type I and II PC Card outlines
except for the extended portion. The extended portion extends 10 mm past the standard PC Card
length of 85.6 mm before the height may be increased in the bubble area. It should be noted that in
the extended bubble portion the thickness from the centerline of the connector to the bottom of the
PC Card is the same thickness for the entire length. The centerline of the connector to the top of the
bubble is 8.0 mm recommended. This will allow a thicker bubble.
3.4.2 Background
The Type I and II Extended PC Card outlines were primarily specified so that designers and
manufacturers of I/O PC Cards may encase their electrical and magnetic isolation devices within the
shielded PC Card enclosure. It was noted during the discussion before passage of the Type I and II
Extended PC Card Outline that some connectors (RJ-11 and RJ-45) will not fit within the
recommended thickness. Therefore, PCMCIA's Card Physical Committee specified the thickness
such that the centerline of the connector to the bottom of the PC Card is 2.5 mm max. The height
from the socket centerline to the tip of the bubble is 8.0 mm recommended. This recommended
height will allow the designer to increase the total thickness of the bubble in order to accommodate
the RJ-11 and RJ-45 connectors.
3.4.3 Guideline
The following figures define the recommended outline for Type I or Type II Extended PC Cards.
GUIDELINES
1
T3
T (REF)
E Surface A
F
4x R
SUBSTRATE AREA
3
INTERCONNECT AREA P C
2x S CONNECTOR
2x T
W 6
Surface A
#34 #1
Y #68 #35 X
Surface B
X X
C MIN L ± 0.20 P MIN 3 T 4 6 S MIN W ± 0.10 X ± 0.05

10.0 85.60 10.0 1.65 3.0 54.0 1.00
Y ± 0.05 D MAX E ± 0.20 F MIN R MAX T3 5
1.60 40.0 10.0 5.0 3.0 8.0
1 RECOMMENDED I/O CONNECTORLOCATION.
2. THE PC CARD SHALL BE OPAQUE (NON SEE THRU)
3 POLARIZATION KEY LENGTH.
4 INTERCONNECT AREA TOLERANCE = ± 0.05

SUBSTRATE AREA TOLERANCE = ± 0.10
5 RECOMMENDED MAX DIMENSION.
6 FOR CARDBUS PC CARDS, DIMSENTION T IS INCREASED BY 0.50 ± 0.05 OVER DIMPLES

(REFER TO CARDBUS PC CARD RECOMMENDED CONNECTOR GOUNDING INTERFACE DIMENSIONS
FIGURE IN THE PHYSICAL SPECIFICATION)
Figure 3-14: Type I Extended PC Card Package Dimensions
PHYSICAL GUIDELINES
C
O
N
N
EC
TO
R
PC D
C
AR
Figure 3-15: Type I Extended (3-D)
GUIDELINES
1
T3
T2 (REF)
E Surface A
F
4x R
SUBSTRATE AREA
3
INTERCONNECT AREA P C
2x S CONNECTOR 5
2x T1
W
2x T2
Surface A
#34 #1
Y #68 #35 X
Surface B
X X
C MIN L ± 0.20 P MIN 3 T1 ± 0.05 5 T2 MAX S MIN W ± 0.10

10.0 85.60 10.0 1.65 2.50 3.0 54.0
X ± 0.05 Y ± 0.05 D MAX E ± 0.20 F MIN R MAX T3 4
1.00 1.60 40.0 10.0 5.0 3.0 8.0
1. RECOMMENDED I/O CONNECTOR LOCATION.
2. THE PC CARD SHALL BE OPAQUE (NON SEE THRU)
3. POLARIZATION KEY LENGTH.
4. INTERCONNECT AREA TOLERANCE = ± 0.05

SUBSTRATE AREA TOLERANCE = ± 0.10
5. FOR CARDBUS PC CARDS, DIMENSION T1 IS INCREASED BY 0.50 ± 0.05 OVER DIMPLES

(REFER TO CARDBUS PC CARD RECOMMENDED CONNECTOR GROUNDING INTERFACE DIMENSIONS
FIGURE IN THE PC CARD STANDARD PHYSICAL SPECIFICATION)
Figure 3-16: Type II Extended PC Card Package Dimensions
PHYSICAL GUIDELINES
C
O
N
N
EC
TO
R
PC D
C
AR
Figure 3-17: Type II Extended (3-D)
GUIDELINES
4 . S O F T WA R E G U I D E L I N E S
4.1 Enabler Capabilities and Behavior
4.1.1 Summary
This guideline recommends the capabilities that all enablers should provide and proscribes certain
behavior. Following this guideline minimizes colliding accesses between the enabler and other
clients and between independent enablers thus guaranteeing a minimum level of functionality to
users.
4.1.2 Background
The purpose of an enabler is to allow a single piece of software to configure and unconfigure a PC
Card to prevent the redundancy of every PC Card requiring separate and unique configuration
software.
Enablers recognize PC Cards in one of two ways. First, they may recognize a card specifically from
information in the Card Information Structure (CIS) that is unique to that card. For example, some
enablers use combinations of the manufacturer string and product string from the VERS_1 tuple and
the Manufacturer ID and Function ID tuples. Second, enablers may recognize a PC Card solely from
its Function ID tuple. For most Data/FAX modems, a Function ID that indicates the PC Card has a
serial interface causes the card to be configured as the next available COM port.
Once a card is configured, it may be used by software that is or is not aware that the functionality is
located on a PC Card. If the software is PC Card-aware, it may piggy-back on the efforts of the
enabler and use the cardÕs functionality until the card is removed and the enabler releases the
system resources allocated to the card.
If the software is not PC Card-aware, it must locate the cardÕs resources where the enabler mapped
them into the host systemÕs address space. For most cards this means assuming the PC Card is
placed at the same locations typically used by standard ISA peripherals that perform the same
functions.
Some cards offer functionality that use configuration files to describe where they are located in
system memory. As an example, network adapters have a NET.CFG or PROTOCOL.INI file
describing the IRQ level, I/O address range and memory range used to access the adapter. In this
case, the enabler must place the PC CardÕs resources as indicated in the configuration file.
An enabler which follows this guideline should be able to properly configure any card which
follows the CIS requirements for its card type and contains logically correct and consistent
information within the tuples.
Note that although an Enabler API is not prohibited, such an API is not described by this guideline.
4.1.3 Guideline
It is strongly recommended that PC Card system software implementations provide an enabler. If
such an enabler is present in a system, it should be tested as part of that systemÕs integration test.
Enablers developed for the PC Card environment should obey the following guidelines:
SOFTWARE GUIDELINES
1. Enablers should support 16-bit PC Cards as well as CardBus PC Cards. The use of a single
enabler reduces usage of system resources and simplifies software interactions. This goal cannot
be achieved without building support for both types of cards in the enabler. If it is necessary for
there to be more than one enabler resident in the system in order for the system to support both
types of cards, then rule #3 should be observed.
2. Enablers should be able to configure cards which meet the CIS requirements outlined in the
Metaformat Specification. This ensures that cards designed to the minimum requirements can
be configured by all enablers designed to support that class of card.
3. Enablers should not interfere with the registration and configuration of Card Services clients
which do not use the enabler. It is recommended that enablers honor exclusive requests for a
function. Therefore, there should be a mechanism for not generically enabling a card even
though it could be enabled. Enablers should allow users to designate which cards or which class
of cards it will not configure.
4. Enablers should never cause any client to lose resources unwillingly because resource changes
cannot be handled gracefully (i.e., transparent to the user) without the involvement of the
client.
5. If the system allows the user to query, then enablers should be able to inform users about
resource and logical device configuration. This provides the ability to notify the user of card
configuration status.
6. All system software must be aware of its impact on the system resources. For example, in an x86
type of system, enablers should make as much use as possible of memory above 1 MByte (high
and/or extended memory) to minimize the impact on the first 640 KBytes of system memory
(low memory).
7. Card Services is the owner of all PC Card resource management for clients including the
enabler. If an enabler uses a private API for assigning resources, it should inform Card Services
of the outcome of the arbitration.
8. Enablers which donÕt enable certain classes of cards must not configure or modify the
configuration of that class of cards. For example, an enabler which only manages memory cards
must not configure or modify the configuration of I/O cards.
9. In CardBus PC Cards, memory windows are a fixed size so no standard means exists to reassign
windows. Enablers which also act as 16-bit PC Card memory clients must be able to reassign,
reuse, and resize the same host memory space to accommodate additional memory cards so that
each memory client can use (allocate and deallocate) the same memory address space. For
performance reasons, memory cards will want as much space as is available. However, the
appearance of new clients causes a need to dynamically resize these windows.
GUIDELINES
4.2 CardÐApplication Interaction
4.2.1 Summary
This guideline minimally outlines how PC Card-aware and PC Card-unaware applications should
interact with a PC Card.
4.2.2 Background
The following terms are used in this Guideline:
Application Function Test are the tests that an application tester would normally use
to confirm that an application basically works as
designed. They are not comprehensive tests and do not
necessarily address boundary and error conditions.
Enabler is also referred to as a Ògeneric enabler.Ó This is a Card
Services client which is capable of configuring a variety
of cards. It may or may not have other capabilities such
as the following:
· providing an alternate API to Card Services
· providing the user information about the installed
cards
This type of enabler is not custom designed for
configuring specific cards, but, using the CIS and the
Card Services interface, it can configure many different
cards, or classes/types of cards.
PC Card-Aware Application is an application which has been modified to take into
account the PC Card busÕs more dynamic environment.
This would include having either the application or a
driver the application uses becoming a Card Services
client.
PC Card-Unaware Application is an application which has not been modified as above.
In any given PC Card system, there can be both PC Card-aware and PC Card-unaware applications.
Both of these types of applications may wish to access the PC Card, and could react very differently
to changes in the card status. This guideline attempts to define a minimum standard of good
behavior in several simple, common situations.
SOFTWARE GUIDELINES
4.2.3 Guideline
4.2.3.1 PC Card-Unaware Applications

For PC Card-unaware applications, the PC Card will have to be configured by some PC Card-aware
software, usually an enabler. After the card is configured, the application will behave towards the
card as if it were in a static bus environment. Following are the guidelines for the just described
situation:
1. The PC Card should be able to be used with an appropriate well-known/well-behaved PC
Card-unaware application (e.g., communications software for a modem card). The application
should be able to pass its basic functional test while using the card as long as the card is neither
inserted nor removed during application operation.
2. It is acceptable that the user may have to intervene to appropriately configure the application to
access the PC Card (e.g., tell it which COM port the enabler has chosen for the card).
3. The user may have a need to know about how a particular card has been configured, as in the
COM port example above. The enabler that configured that card must be able to provide that
information on request.
Furthermore:
1. once the card and the application have been configured
2. and provided that the card is not removed during execution
There should be no discernible difference between a PC Card-unaware application on a PC Card
system using a PC Card and a PC Card-unaware application on a non-PC Card system using a static
card.
4.2.3.2 PC Card-Aware Applications

The PC Card-aware application has an interface to Card Services via one of the following pieces of
software, which will configure any PC Card it uses:
· an enabler
· a device driver
· the application itself
Following are the guidelines for the just described situation:
1. The card should be able to be used with an appropriate well-known/well-behaved PC Card-
aware application. The application should be able to pass its basic functional test while using
that card. The application functional test should still pass if the card is inserted or removed
during application operation.
2. A PC Card-aware application exhibits its normal behavior while a PC Card it is using or wants
to use is removed or inserted. In general, it will treat these events in the same way that it would
for floppy removal and insertion. In some cases, this treatment may not be possible; for
example, when a network connection or some similar resource is lost. In this instance, however,
the application should not crash, and then should
a) inform the user of the event
b) allow the user to recover gracefully
GUIDELINES
c) not interfere with the operation of other applications

3. The PC Card should be able to be installed and configured by its designated configuring
software with minimal to no user intervention. The card could be configured by an enabler or
by software specifically designed for the card such as a device driver. It is possible that a card
could be configured by more than one piece of software.
4. Unless exclusive access has been requested, PC Card-aware applications should be able to share
PC Cards. If the application can not share the card, then it should request exclusive access to the
card.
5. Some PC Cards may be able to be configured by more than one Card Services client, including
one or more enablers. For such cards, the user must be allowed to designate which software will
configure and/or manage that card. This choice should be made when the card is inserted the
first time and need not be repeated on successive insertions.
6. As with PC Card-unaware applications the user may have a need to know about how a
particular card has been configured. The software that configured that card must be able to
provide that information on request. This information may be provided in a variety of ways.
The full extent of the information should not be announced every time the card is inserted, in
such a way that the operation of the application that the user is executing is continually
interrupted. Depending on implementation, notification of logical device allocation may be an
exception to this general rule of application non-interruption, as it may be needed immediately
by the user.
7. Many PC Card-aware applications and/or their drivers may only work with specific versions of
PC Card hardware and software, e.g., a Card Services conforming to a given level of the
specification. If a Card Services client is incompatible with any resident hardware or software, it
must immediately report that finding to the user and gracefully stop its continuing execution.
Trying to continue execution with incompatible components is ultimately more distressing to the
user since the cause of the failure, when it happens, will not be as obvious as it would have
been initially.
SOFTWARE GUIDELINES
4.3 CardBus Operational Scenarios
4.3.1 Summary
The client to Card Services interface for CardBus PC Cards is very similar to the interface for 16-bit
PC Cards. The processing done by the PC Card software stack is different for CardBus PC Cards in
order to maintain that common interface. The intent of this guideline is to give an example of how
such processing may be done.
4.3.2 Background
CardBus sockets support both 16-bit PC Cards and CardBus PC Cards. Clients for these cards both
use the same Card Services interface. However, because the on-card programming model is so
different for CardBus PC Cards, the PC Card software stack needs to internally process CardBus
configuration requests differently.
There is no one way to implement CardBus processing. For example, a designer might choose to
apply the minimum configuration power upon card insertion or only after a request is made to read
the CIS. This guideline is meant to be one example of how an implementation might be done.
4.3.3 Guideline
The following scenario describes the recognition and configuration of a CardBus PC Card. Via the
CardBus Socket Services, Card Services knows that a CardBus PC Card has arrived. At this time, it
performs the following actions:
1. Card Services notifies its registered clients that a card has arrived. This notification is sent for
each function on the card, so that each function looks like a separate card to a client.
2. The client requests tuples using the socket and function number it was sent in its insertion
notification.
a) The client requests the first tuple of the function via Card Services.
CardBus clients may be drivers, applications, generic enablers, etc. just like 16-bit PC Card
clients. Additionally, because some of the cards implemented in CardBus may share silicon with
PCI cards, CardBus drivers may also be modified versions of PCI drivers. See the guideline
CardBus/PCI Common Silicon Requirements for some considerations when developing this type of
software.
b) Card Services applies power to the socket in order to read the CIS. For CardBus, all cards are
required to be able to support CIS reads at 70 mA. At this point, if the adapter has not been
previously configured, Card Services will configure the adapter before proceeding.
c) Card Services reads the CIS pointer from configuration space to find the beginning of the first
chain of the CIS. The CIS pointer indicates the card space in which the chain resides:
i. configuration space
ii. one of the six (6) possible memory spaces
iii. the expansion ROM
and an offset into the space where the chain actually starts
GUIDELINES
d) If the indicated chain starts anywhere but configuration space, Card Services maps the
indicated card space into host system address space by writing the appropriate Base Address
Register. Note that this is a temporary mapping only. Mappings become permanent only when
the client requests them as part of the configuration.
e) If the client has requested to see all link-related tuples, then the first tuple will always be a
CISTPL_LINKTARGET tuple.
f) The client requests the next tuple.
g) The client walks through the functionÕs CIS just as a 16-bit PC Card client would. For any
tuples in non-configuration space, the client may read them directly. However, it is strongly
recommended that the client use the Card Services interface and not read the tuples directly.
Note that in order for a client to read the tuples directly it needs to be able to perform the
following tasks which Card Services would normally perform for it:
i. temporarily mapping in the card space in order to read the tuples
ii. interpret the CISTPL_LONGLINK_CB tuple to find additional chains in the card spaces.
3. If the client recognizes the card as one it is interested in, the client then uses
GetConfigurationInfo for that function to see if it has been configured.
4. The client requests resources for the function from Card Services.
5. If the requests are successful, the client obtains the configuration for the function.
For all address space requests (e.g., I/O, memory, expansion ROM), Card Services writes the
appropriate value (a host address) into a Base Address Register. It does not request windows
from Socket Services.
6. After the function is configured the client may now access the function.
In this scenario, clients may operate, as far as configuration is concerned, completely as 16-bit PC
Card clients. This includes using a generic enabler if the client does not wish to do the configuration
requests itself.
Unchanged 16-bit PC Card software continues to work in the expected manner when a 16-bit PC
Card is inserted in a CardBus PC Card socket. In addition to sockets with both CardBus and 16-bit
PC Card capabilities, there may also be 16-bit PC Card-only sockets in the system. From the clientÕs
point of view, whether the 16-bit PC Card is in a 16-bit PC Card-only socket or in a combined 16-bit
PC Card/ CardBus PC Card socket, the Card Services programming interface is the same.
The CardBus PC Card Socket Services knows that the card which has just been inserted is a 16-bit
PC Card by reading the adapter. After that point, Card Services continues its normal processing just
as if the card were in a 16-bit PC Card-only socket. The only difference is the actual hardware
interface, which is isolated to Socket Services. This processing consists of:
1. Card Services notifies its registered clients that a card has arrived.
2. The client walks the CIS via calls to Card Services.
3. If it recognizes the card, the client has the card configured by requesting resources such as
memory windows from Card Services.
4. After the card is configured, the client may manipulate the card.
SOFTWARE GUIDELINES
4.4 Fax/Modem CIS Design
4.4.1 Summary
This guideline describes the design of CIS for a single function 9600/2400 BPS Fax/Modem I/O 16-
bit PC Card (not CardBus). The functional information required for a well defined CIS for a similar
function on a multiple function PC Card or CardBus PC Card would be the same. However, the
requirements for control tuples and device information tuples, etc. vary among these card types.
Only the single function 16-bit PC Card is given in this example. How to use the tuple structure and
what are appropriate values for field values are included in the examples.
4.4.2 Background
The purpose of the Card Information Structure is to provide a mechanism for software to be able to
identify the function, origin, and capabilities of a PC Card. The idea is that when a card is inserted
(or the machine is turned on with the card installed), an intelligent piece of code, which might be in
the BIOS or run as a TSR or a device driver, would parse the CIS and perform the needed
operations for card and system configuration. Being able to configure the card either at boot or after
insertion is desirable since the host computer does not need to tie up resources before they are
needed. It also allows the system to Ògracefully rejectÓ any card that it is not capable of using.
The discussion that follows is focused on a 9600/2400 Fax/Modem, but can be used for any type of
I/O card. A Fax/Modem was selected because the extension tuples for this type of card were the
first to be added to the PC Card Standard. Using these function extension tuples along with the
Rev 2.0 configuration tuples, a full descriptive guideline can be given. The 9600/2400 speed was
selected for this guideline because it has become the generic minimum for Fax/Modems.
Some of the 9600/2400 Fax/Modem specific features that are documented in this guideline are:
9600 Fax speed
2400 Modem speed
16450 UART
All character, stop, and start bit possible configurations
Support for the US
V.22bis, Bell 212A, V.22A&B, V.21, Bell 103
V.29, MNP1-5, V.42, V.42bis, V.27ter
GUIDELINES
4.4.3 Guideline
The tuples covered in this example are enumerated in Table 4-1: Tuple Codes for Fax/Modem Card
Example, below. A discussion of each tuple and some of its values follows.
Table 4-1: Tuple Codes for Fax/Modem Card Example
Data Code Tuple Name Description

01H CISTPL_DEVICE Device Information
15H CISTPL_VERS_1 Level 1 Ver / Product Info
20H CISTPL_MANFID Manufacturer ID
21H CISTPL_FUNCID Function ID
22H CISTPL_FUNCE Function ID Extensions
1AH CISTPL_CONF Configurable Card
1BH CISTPL_CE Configuration Entry
14H CISTPL_NO_LINK No Link
FFH CISTPL_END End of Chain
4.4.3.1 The Device Information Tuple (01H)

The PC Card Standard implies that this tuple must be the first tuple located in Attribute memory
address space. Besides being the first tuple, the Device ID tuple is also the most confusing of the
required tuples for I/O cards. This is because it originated from the PCMCIA 1.0/JEIDA 4.0
publications which assumed that there was some type of device in common memory.
Table 4-2: Device Information Tuple

01H CISTPL_DEVICE Device Information Tuple
03H TPL_LINK Link to Next Tuple
00H DEVICE INFO1 No Device in Common Memory
(00 = DTYPE_NULL)
00H Empty Block of 512 bytes
FFH End of Device Info Field
As shown in Table 4-2: Device Information Tuple, the device information tuple contains a minimum
of 5 bytes. The first two bytes contain the tuple code and the link to the next tuple in the list. The
link is calculated starting with the next byte of the tuple after the link and ending at the last byte of
the tuple. So for this example, the value placed in the TPL_LINK field is 03H.
The next two bytes contain the common memory device information for the first device. In the
fax/modem card there is just one device, the Fax/Modem, but in future products, multi-function
cards will exist and consequently additional DEVICE INFO fields will be required. Each of the
functions requires 2 bytes of device information. The two bytes contain the device type code,
whether a Write Protect Switch is included, what speed the device is, and how much address space
it needs. A value of 00 H is placed in the first device ID byte because there is no device in common
memory (in this Fax/Modem example), so a null device type is selected.
The device size which is the second byte of the device information field is a 00H because that is the
smallest amount allowed. With the value of 00H a window of 1 block of 512 bytes is defined.
SOFTWARE GUIDELINES
Unfortunately, the byte does not allow for no memory, so you should specify the smallest one
possible. The last byte is an FFH which marks the end of the device information tuple.
4.4.3.2 Level 1 Version/Product Information Tuple (15H)

The level 1 version/product information tuple is used to indicate the level of the card and also the
cardÕs manufacturer. The PC Card Standard describes two version levels, however, this tuple is
used for Level 1 tuples only.
Table 4-3: Version Product Information Tuple

15H CISTPL_VERS_1 Level 1 Version / Product Information
Tuple
1EH TPL_LINK Link to Next Tuple
04H TPLLV1_MAJOR Major Revision Number
01H TPLLV1_MINOR Minor Revision Number
50H TPLLV1_INFO P
43H C
4DH M
43H C
49H I
41H A
00H Terminator
46H F
61H a
78H x
20H space
43H C
61H a
78H r
64H d
00H Terminator
46H F
58H X
33H 3
32H 2
31H 1
30H 0
00H Terminator
41H A
2DH -
30H 0
00H Terminator
FFH End of List
GUIDELINES
The TPLLV1_MAJOR and _MINOR fields are defined in the PCMCIA 1.0/JEIDA 4.0 publications as
having a value of 05H for _MAJOR and 00H for _MINOR in the PCMCIA 2.0/JEIDA 4.1
publications. This value should only be changed for your configuration if you are conforming to a
later release of the PC Card Standard.
The TPLLV1_INFO field is used to input the manufacturer, the product name and revision number.
The specification is not specific about the exact format for this, however, the example above should
be followed including the use of terminators and including the end of list (FFH) field at the end.
Incidentally, the end of list field is not a requirement for all tuples, but it is required for this one.
The values placed in this field are the ASCII hex values of the letters indicating the product name,
revision number, vendor specific information, and manufacturer (PCMCIA).
4.4.3.3 ManufacturerÕs ID Tuple (20H)

This tuple was added to provide the ability for software to determine the origin and manufacturer of
the PC Card as well as the card type.
Table 4-4: Manufacturers ID Tuple

20H CISTPL_MANFID Manufacturing ID Tuple Device Information Tuple
xxH TPLMID_MANF ManufacturerÕs ID Tuple (LSB)
xxH ManufacturerÕs ID Tuple (MSB)
xxH TPLMID_CARD Company Specific Info
xxH Company Specific Info
The TPLMID_MANF field is the unique ID code that is developed from the JEDEC Device ID code
indicating the manufacturer. If a manufacturer has a JEDEC code, then the 16 bit PCMCIA ID has a
00H in the upper byte, and the code in the lower byte. If a manufacturer does not have a JEDEC
code, PCMCIA can assign a company specific ManufacturerÕs ID Tuple.
The TPLMID_CARD field designates the card type. These two bytes are manufacturer specific
identifiers. Each manufacturer will develop its own coding scheme for its card family.
4.4.3.4 Function ID Tuple (21H)

The purpose of this tuple is to provide information regarding the function of the card and system
initialization information.
Table 4-5: Function ID Tuple

21H CISTPL_FUNCID Function ID Tuple
02H TPLDFID_FUNCTION Serial I/O Fax/Modem
01H TPLFID_SYSINIT Configure at Post
The TPLDFID_FUNCTION field specifies the function, or multiple functions the card can perform.
The example Fax/Modem card performs as a serial device for both modem and fax functions and
SOFTWARE GUIDELINES
thus has the value of 02H. A value of 0H indicates a multiple function card and this requires
additional bytes to specify the individual functions. Currently the following values are:
0 Vendor Specific Multiple Function
1 Memory
2 Serial Port (both modem and fax cards)
3 Parallel Port (parallel printer port both uni- and bi-directional)
4 Fixed Disk
5 Video Adapter
6 LAN Adapter
7 AIMS
8 SCSI
9 Security
A Instrument
B-FFH Reserved
The TPLFID_SYSINIT field of the tuple indicates to the host when the card should be initialized.
Only two values are defined today; a 01 H indicates that the card should be initialized during POST,
and a value of 02H indicates that the card contains expansion ROM which should be installed
during system installation. Our example card does not contain ROM and consequently should have
the value of 01H.
4.4.3.5 Modem Function Extension Tuple (22H)

The Modem Function Extension tuples document the capabilities of the fax or modem before the
communications package tries to use it.
GUIDELINES
Table 4-6: Function Extension Tuples

22H CISTPL_FUNCE Serial Port ID
04H TPL_LINK Link To Next Tuple
00H TPLFE_TYPE Serial Port
01H TPLFE_UA 16450 UART
0FH TPLFE_UC All Parity Supported
7FH All Stops and Characters Supported
22H CISTPL_FUNCE Modem Function Extension
01H TPLFE_TYPE Modem as Discrete Device
1FH TPLFE_FC All Flow Control Methods
09H TPLFE_CB 40 Character DCE Command Buffer
C8H TPLFE_EB 200 Character DCE to DCE Buffer, LSB of LSW
00H DCE to DCE Buffer MSB of LSW
00H DCE to DCE LSB of MSW
C8H TPLFE_TB 200 Character DTE to DCE Buffer, LSB of LSW
00H DTE to DCE MSB of LSW
00H DTE to DCE LSB of MSW
22H CISTPL_FUNCE Data Modem Extension
0CH TPL_LINK Link to Next Tuple
02H TPLFE_TYPE Modem
00H TPLFE_UD DTE to UART Max Data Rate MSB
80H DTE to UART Max Data LSB (9600)
3BH TPLFE_MS Modulation V.22bis,Bell 212A, V.22A and B, V.21, Bell 103
00H Not Supported
03H TPLFE_EM Error Correction using MNP 2-4 or V.42/LAPM
03H TPLFE_DC Data Compression using MNP5 or V.42bis
08H TPLFE_CM Command Protocol is MNP AT
07H TPLFE_EX Escape Mechanism is User Defined, +++, Break
00H TPLFE_DY No Data Encryption
00H TPLFE_EF No Caller ID
B5H TPLFE_CD ITU-T(CCITT) Country Code (USA)
22H CISTPL_FUNCE Fax Extension
13H TPLFE_TYPE Fax Class 1
00H TPLFE_UD DTE to UART Max Data Rate MSB
80H DTE to UART Max Data Rate LSB (9600)
06H TPLFE_FM ITU-T(CCITT) Modulation Supported V.29, V.27ter
00H TPLFE_FY Reserved for Future Encryption Definition
22H TPLFE_FS Fax features Polling and T.4
00H Reserved
B5H TPLFE_CF ITU-T(CCITT) Country Code USA
SOFTWARE GUIDELINES
Using these tuples will allow the host and the application software, which is CIS aware, to do away
with the current set of questions that must be asked when configuring the operating environment.
The fax/modem tuple list contains three different function extension tuples. These are used to
describe the three distinct areas of functionality of fax/modem products. The current extension tuple
has been designed to accommodate one more function (not included in this example card) ¾ Voice
Encoding. The tuples start with the simplest function, a UART or Universal Asynchronous Receiver
Transmitter. The serial port ID tuple is a 6 byte tuple. The functions that are included are the
determination of the UART type, the start and stop characters supported, and the parity types.
There are three types of UARTs used for serial communication, they are the 8250, 16450 and the
16550. The fourth and fifth fields deal with the actual UART capabilities. The standard 16450 UART
is capable of handling all data sizes (5, 6, 7, 8), stop characters (1, 1.5, 2) and parity types (even odd,
mark, or space). The 16450 is the UART used in this example.
The Modem Interface tuple, which starts with the second CISTPL_FUNCE code, details the
functionality of the modem . This tuple string describes the modem characteristics. This is a eleven
byte tuple, starting with the standard code and link tuples. The next byte deals with the flow
control methods of the modem. Flow control is the handshaking between two modems and is used
to decide if the connection can support the sending/receiving of new information. A byte value of
1Fh corresponds to the support of all flow control methods including hardware and software flow
control. This tuple also describes the chip set feature of a 40 character DCE Command Buffer, and 2
character buffers. The 40 character command buffer gives the tuple value of 09h because the
formula used for calculation is to take the buffer size, divide by 4, then subtract a 1 (size = n, n/4-1).
On our example card, the two character buffers are 200 character DCE to DCE and DTE to DCE
buffers.
The Data Modem tuple is the third of the five CISTPL_FUNCE code tuples. This tuple describes the
data rates, modulation schemes, error correction and detection, command protocols, and the ITU-
T(CCITT) Country code. This tuple string is 14 bytes long, starting with the standard tuple code and
link. The values for this string of data comes straight off of the modem chip set (internal to the card)
data sheets, consequently, when developing the data for this tuple refer to the appropriate data
sheets.
The Fax tuple is the final function extension tuple in this section. This tuple is a minimum of ten
bytes, but must be replicated for each supported Service class. As with the Data modem tuple, the
features described are the maximum data rate, modulation schemes, and country code.
4.4.3.6 Configuration Tuple (1AH)

The Configuration Tuple, Tuple 1AH, describes the general characteristics of PC Cards, for example,
where the first configuration register is located and how many there are in total.
Table 4-7: Configurable Card Tuple

1AH CISTPL_CONF Configuration Tuple
01H TPCC_SZ Two bytes of Address
23H TPCC_LAST 23H (Com4) is Last entry in Configuration Table
00H TPCC_RADR Configuration Register Base Address LSB
02H TPCC_RADR Configuration Register Base Address MSB
03H TPCC_RMSK Two Configuration Registers
GUIDELINES
The TPCC_SZ field indicates the number of bytes in the configuration registers base address, and
the configuration register presence mask. The values of these registers are detailed in the bytes
following the size field.
The TPCC_LAST field gives the value that corresponds to the final entry in the card configuration
table. For communications cards that are being designed for use with PCs, this value will
correspond to COM4. In this example a 23H corresponds to COM4.
The TPCC_RADR field indicates the address of the configuration registers in Attribute memory
address space. At least one byte of address is required. If more than one byte is needed, the LSB
should be presented first.
The TPCC_RMSK field gives the number of registers that start at the base address in Attribute
memory address space. Each bit in the field corresponds to the presence or absence of a register.
The host would use this information along with the value in the RADR field to determine the
location of the cardÕs configuration register set.
4.4.3.7 Configuration-Entry Tuple (1BH)

The Configuration Entry tuple, Tuple 1BH, defines the default configuration and its description. If
the fax/modem is expected to be used in the PC Market, the Configuration tuple would need to be
repeated for the other three Comm ports of the PC.
SOFTWARE GUIDELINES
Table 4-8: Configuration Entry Tuple

1BH CISTPL_CE Configuration Entry Tuple
E0H TCE_INDX Default: COM1 (20H), Interface Follows
01H TPCE_IF I/O, Wait Supported
9DH TPCE_FS Feature Selection Byte
71H TPCE_PD Power Description
55H V nominal = 5 v
86H I Avg. = 138 mA
26H Extension
86H I Peak = 197 mA
61H Extension
64H I Power Down = 6 mA
FCH TPCE_TD Wait Scale Only
0CH 10 uS Max Wait Time
AAH TPCE_IO 8 Bit I/O 10 Bit I/O Addr
60H 1 Range, I/O Addr = 2 bytes
F8H Start of I/O Addr (LSB)
03H Start of Addr (MSB)
07H Length of Range =8
30H TPCE_IR Level Mode, Mask for INTs
BCH IRQ7, IRQ5, IRQ4, IRQ3, IRQ2
86H IRQ15, IRQ10, IRQ9
28H TPCE_MI Supports Power Down and Audio
As with all tuples, the configuration tuple begins with the tuple code and the link to the next tuple.
After the link is the Table Index Byte. A value of E0H defines that this entry is the default entry,
that a set of interface descriptions follow, and that a value of 20H must be written into the
Configuration register to enable the card.
The Interface Description field, feature selection byte field, and Power Selection byte are straight
forward and describe that the card is an I/O card, that it supports the Wait line of the 68 pin
interface, and details that the following bytes will describe the Voltage, Current, Wait scale, address
port, Power Down features and Audio features of the card.
The most confusing bytes of information in this section are the Power Description Structure
Parameter Definitions. These are not required, but help the system to get a full description of the
card. Since this is confusing, we will step through the description in detail. Table 4-9: Power
Extension Fields for Tuple 1Bh through Table 4-11: Mantissa Values are the tables given in the
specification that detail the power description structure.
Table 4-9: Power Extension Fields for Tuple 1BH
Byte 7 6 5 4 3 2 1 0
0 Ext Mantissa Exponent
1 Ext Extension
GUIDELINES
Table 4-10: Current /Voltage Scales
Exponent The Exponent of the Current and Voltage Values are given below:
Exponent Current Scale Voltage Scale
0 100 nA 10 uV
1 1 uA 100 uV
2 10 uA 1 mV
3 100 uA 10 mV
4 1 mA 100 mV
5 10 mA 1V
6 100 mA 10 V
7 1A 100 V
Table 4-11: Mantissa Values
Mantissa The Mantissa of the value are given below:

0H 1
1H 1.2
2H 1.3
3H 1.5
4H 2
5H 2.5
6H 3
7H 3.5
8H 4
9H 4.5
AH 5
BH 5.5
CH 6
DH 7
EH 8
FH 9
The nominal voltage is an example of a value not needing an extension. Looking at byte 0, the
extension bit will be 0, since no extension is needed because the value can be defined with only one
byte. The mantissa which occupies bits 6-3 will be an AH. This is seen from Table 4-11: Mantissa
Values, where an AH represents the numerical value of 5. The Exponent which occupies bits 2-0 will
be a 5 since the Voltage scale is 1V. Grouping all of the bits together gives a value of 55H.
The Peak Current of 197 mA needs an extension byte, byte 1, because the value to be described has
3 significant digits. As with the voltage, the designer must first look at byte 0. In this case bit 7 will
be a 1, thus signifying that an extension byte follows. The mantissa will be a 0 because the value to
be described is a 1 (see Table 4-11: Mantissa Values). Since we are looking at the 100 mA range, the
Current scale for the exponent is 6. When put together the byte 0 value is 86H . This takes care of
the 100Õs portion of the value. To get the remaining 97 mA defined, the extension byte is used. The
value shown of 61H is the hex value for 97.
SOFTWARE GUIDELINES
4.4.3.8 No Link Tuple (14H)

The NO_LINK tuple is an optional tuple that is used to help speed up tuple processing by
indicating to the software that there will be no long link tuples in this chain. Long links are used
when tuples are located past the 256 Byte limit of the link field. In particular, they are often used to
indicate a tuple chain stored in common, rather than attribute memory.
Table 4-12: No Link Tuple

14H CISTPL_NO_LINK No Link Tuple
4.4.3.9 End of Tuple Chain (FFH)

The End of Tuple Chain is used to indicated the end of the tuple chain and has a value of FFH. This
tuple appears at the end of the CIS.
Table 4-13: End of Tuple Chain

FFH CISTPL_END End of Tuple Chain
GUIDELINES
4.5 Wireless CIS
4.5.1 Summary
The following is the suggested additions to the example Tuple requirements already proposed in
other Guidelines.
4.5.2 Background
This is part of a series of proposed guidelines which describe sample CISs for a variety of cards.
4.5.3 Guideline
4.5.3.1 Wireless Modems

The tuples as defined in the Fax/Modem CIS Design are in general all that is needed for a wireless
modem card. The differences of concern to a host between a conventional modem and wireless
modem could be the maximum or peak power required when the RF unit is transmitting. Since
provision for this information is already in the current modem tuple Guideline, no further definition
is required here. Function extension tuples which define the particular RF technology supported by
the card, i.e., ARDIS, CDPD, Mobitex, etc. could be of interest to applications (clients). If there is
mutual interest in this, further modem extension tuples could be proposed.
4.5.3.2 Wireless LANS

As with the modems, the wireless LAN PC Card would require no additional tuples beyond that
recommended for the non-wireless LAN. The wireless LAN PC Card should include a LAN function
extension tuple for LAN_TECH_CODE with value of 7 specified and the LAN function extension
tuple for LAN_MEDIA_CODE with the appropriate value representing the technology
implemented.
4.5.3.3 Wireless Pagers

Since the wireless pager looks to the host like a serial port, no further tuples beyond that of the basic
serial port are required. Once again, if it would be helpful to applications (clients), function
extension tuples could be proposed that would further define the capabilities of the wireless pagers.
SOFTWARE GUIDELINES
4.6 Sample PC Card ATA Tuple Options
4.6.1 Summary
Following is a summary of 16-bit PC Card ATA CIS considerations with actual samples for PC Card
ATA tuple options. Although much of this information is also pertinent to CardBus PC Cards, the
particular example does not deal with how CardBus PC Card ATA cardÕs CIS should be designed.
4.6.2 Background
This is part of a series of proposed guidelines which describe sample CISs for a variety of cards.
4.6.3 Guideline
Following is the recommended minimum set of tuples for PC Card ATA cards. The tuples are listed
in the order in which they would generally be encountered while scanning the CIS on the card. The
tuples are defined in the Metaformat Specification and the PC Card ATA Specification. In some
cases, the tuple is only required if a card has certain characteristics (e.g., memory mapped ATA
registers). In this case, this is noted in the table. If this guideline is found to differ with an explicit
statement in the Metaformat or PC Card ATA Specifications, those specifications shall be the
controlling documents. Examples for the required and some optional configurations are included for
the Configuration Table Entry tuple.
Note:
Shading is used to indicate portions of tuples which are dependent on the
characteristics of a particular implementation of a PC Card ATA card.
GUIDELINES
4.6.3.1 CIS Usage for PC Card ATA Cards

Table 4-14: PC Card ATA Tuple Usage Chart
Mode Tuple Used For
Tuple Tuple Name Tuple Basic 3 PC Memory Non-PC Notes
Code Defined in Card ATA mapped PC Card ATA
I/O Modes Card ATA Functions
Only support
01H Device Info Tuple(Common) PC Card Required Required Required Specifies speed and size of
Standard Null Device Function As needed to Common Memory Areas (e.g.,
Metaformat required if Specific define card PC Card ATA Memory Mapped
no memory Regs memory Registers) at 5 Volts VCC when
space on space WAIT# signal is ignored by
card host. If no common memory
space on card is accessible at 5
Volts VCC it must be
DTYPE_NULL and
DSPEED_NULL.
1CH Other Conditions Device Info PC Card Required Required As needed Characteristics of Memory
(Common) Standard Only if Only if for other Address Spaces under other
Metaformat WAIT# or WAIT# or functions operating conditions as follows
3V VCC used 3V VCC used for Other Conditions Info
on card. on card. Values:
Otherwise, Otherwise, 0: Not Allowed
not present. not present.
1: 5 Volt VCC, Host uses WAIT#
2: 3 Volt VCC, Host ignores
WAIT#
3: 3 Volt VCC, Host uses WAIT#
Others: Reserved
18H JEDEC ID (Common) PC Card None Required As needed Defines the type of device for
Standard DF-01 for other each range of memory space
Metaformat DF-02 functions defined in the Device ID Tuple.
Values: DF-04 PC Card ATA JEDEC IDs:
PC Card DF-08 DF-01: No VPP Required
ATA DF-02: VPP on Write Required
DF-04: VPP for Media Access
DF-08: VPP Always Required
20H ManufacturerÕs ID PC Card Recom- Recom- Recom- Recommended for all cards to
Standard mended mended mended identify the Specific
Metaformat Manufacturer and Product in the
card. Must not be used for
general card recognition. Host
should use Function ID and
Function Extension tuples
instead.
15H Level 1 Version / Product PC Card Recom- Recom- Recom- Recommended for all cards to
Standard mended mended mended display product identification
Metaformat strings in ASCII to end users.
Must not be used by host
software to determine card
function unless standard
methods have failed. Host
should use Function ID and
Function Extension Tuples.
SOFTWARE GUIDELINES
Mode Tuple Used For

Only support
21H Function ID PC Card Required Required As needed Disk Function ID is required.

Standard Disk Disk by function Function Extension following
Metaformat Function Function Disk Function ID further refine
Value = 4. Value = 4. product characteristics. Host
Software must use this tuple
with Function Extension tuples
to determine that card has PC
Card ATA function. Typically
POST bit is set in System
Initialization byte to request
system to initialize card for
possible boot.
22H Function Extension following PC Card Required Required Not used. Tuple defines the PC Card Disk
Disk Function ID tuple: Standard Interface Type is supported on
TPLFE_TYPE = 01H Metaformat, the card.
PC Card
TPLFE_DATA = 01H
ATA Spec
22H Function Extension following PC Card Strongly Strongly Not Used. PC Card ATA Features
Disk Function ID tuple: ATA Spec Recom- Recom- Description for first (or only)
TPLFE_TYPE = 02H mended for mended for drive on card.
TPLFE_DATA = as needed pre-PC pre-PC
by card Card Card
Standard, Standard,
Feb. 1995. Feb. 1995.
Required for Required for
PC Card PC Card
Standard, Standard,
Feb. 1995 Feb. 1995
and Dual and Dual
Drive Card. Drive Card.
22H Function Extension following PC Card Required for Required for Not Used. PC Card ATA Features
Disk Function ID tuple: ATA Spec Dual Drive Dual Drive Description for second drive on
TPLFE_TYPE = 03H Card. Card. card.
TPLFE_DATA = as needed Otherwise, Otherwise,
by card Not Present. Not Present.
1AH Card Configuration PC Card Required Required As needed Specifies location of Card
Standard by other Configuration Option Register
Metaformat functions. and presence of other Card
Configuration Registers. Must
be used by host to determine
location of configuration
registers.
GUIDELINES
Mode Tuple Used For

Only support
1BH Configuration Entry PC Card Not Used Required Additional Defines card operation when
with Configuration Index=UU Standard information card emerges from reset with
(00H as used in example is as needed the memory mapped only
strongly recommended as an by interface active. The Memory
index value for cards concurrent Mapped PC Card ATA mode
supporting Memory Mapped additional should be active in this state if
PC Card ATA mode.) card the mode is supported by the
Specific Index values are at function. card. Card support in this
the discretion of the card configuration for MWAIT on
vendor. Common Memory, Ready, and
Write Protect Switch functions
in memory mode can be
indicated. Power and Memory
Space requirements are defined
here. I/O space and Interrupts
may not be defined because no
I/O exists in the Memory Only
Interface.
1BH Configuration Entry with PC Card Required Not Used Additional Defines card operation when
Configuration Index = VvH Standard for Memory function card is placed in PC Card ATA
(01H in example) Metaformat mode, but Contiguous I/O mode. Card
Required support in this configuration for
for I/O MWAIT on Common Memory,
modes also Ready, and Write Protect
supported on Switch functions in I/O mode
card. can be indicated. Power, I/O
Space (4 address lines decode
only), and Interrupt (any)
requirements are defined here.
1BH Configuration Entry with PC Card Required Not Used May contain Defines card operation when
Configuration Index = XXH. Standard for Memory additional card is placed in PC Card ATA
(02H in example) Metaformat Mode, but information Primary I/O mode. Card
Required as needed support in this configuration for
for I/O by additional MWAIT on Common Memory,
modes also card Ready, and Write Protect
supported on function. Switch functions in I/O mode
Space (10 address lines
decoded, Windows 1F0-1F7
and 3F6-3F7) requirements and
Interrupt (usually IRQ 14 for AT
BIOS compatibility)
recommendations are defined
here.
SOFTWARE GUIDELINES
Mode Tuple Used For

Only support
1BH Configuration Entry with PC Card Required Not Used for May contain Defines card operation when
Configuration Index = YYH. Standard Memory additional card is placed in PC Card ATA
Metaformat Mode, but information Secondary I/O mode. Card
(03H in example)
Required for as needed support in this configuration for
I/O modes by additional MWAIT on Common Memory,
also card Ready, and Write Protect
supported on function. Switch functions in I/O mode
Space (10 address lines
decoded, Windows 170-177 and
376-377) requirements and
Interrupt (usually IRQ 14 for AT
BIOS compatibility)
recommendations are defined
here.
1BH Configuration Entry with PC Card Required for Required for May contain Set of configurations with
Configuration Index = ZZH. Standard each each additional unique Configuration Index
Metaformat additional additional information values are used to alternative
(not shown in example)
config- config- as needed PC Card ATA configurations.
uration uration by additional These configurations may differ
present. present. card from the previous four
function. configurations in requirements
for Power, I/O and Memory
Space decoding,
14H No-Link Control PC Card Strongly Strongly Strongly Prevents tuple processing from
Standard Recom- Recom- Recom- doing an implied long link jump
Metaformat mended. mended. mended. to common memory. Should
not appear if an explicit Long
Link tuple is present.
FFH End of List PC Card Required Required Required Terminates each tuple list on
Standard unless FFh unless FFh unless FFh the card.
Metaformat link used. link used link used
GUIDELINES
4.6.3.2 Sample Tuples for PC Card ATA Cards

Table 4-15: Sample Device Info TupleÐ01H Required on PC Card ATA Cards
Order: Size Data 7 6 5 4 3 2 1 0 Description of Contents CIS Function
1: 1 Byte 01H CISTPL_DEVICE Device Info Tuple Tuple Code
2: 1 Byte ??H TPL_LINK Link to next tuple
3: 0 or more ??H Device ID Structures for Other For Memory Mapped PC Card ATA. When Device ID Structures
Bytes Devices or Null Devices for PC Card ATA registers are not at address
address offset computation. offset 0, Device ID Structures preceding this
byte must have sizes which sum to the offset
address of the PC Card ATA registers.
4: 1 Byte ??H Device Type W Dev Speed Device Type, WPS, Speed
P when WAIT# not supported
DFH DH = Func 1 7 = Extend Func Specific, No WPS, ext speed PC Card ATA Regs
Spec
D9H DH = Func 1 1 = 250 Func Specific, No WPS, speed 250 PC Card ATA Regs
Spec nsec
00H 0H = Null 0 0 = Null No Memory Mapped PC Card ATA No Device
5: 0 or 1 Byte 72H 0 EH = 7.0 Spd Expo 700 nsec no wait Extended Speed (present
42H 0 8H = 3.5 2H = 100 350 nsec if no wait only if speed is extended)
X Spd Mantis nsec
6: 1 Byte ??H Addr Units - 1 Unit Size Device Size Byte for
01H 1 unit of 2 K bytes 2 Kilobyte Address Space PC Card ATA Regs
7: 0 or more Device ID Structures for When other memory devices exist in Device ID Structures
Bytes Common Memory Space used common memory, additional Device ID
by Other Card Functions Structures may occur before the List End
Marker.
8: 1 Byte FFH List End Marker End of Devices End Marker
SOFTWARE GUIDELINES
Table 4-16: Sample Other Conditions Device Info TupleÐ1CH Required only if 3V VCC or
WAIT# signal is supported by card for Common Memory cycles
1: 1 Byte 1CH CISTPL_DEVICE_OC Other Conditions Device Info Tuple Tuple Code
2: 1 Byte ??H TPL_LINK Link to next tuple
3: 1 Byte 0?H E R R R R R 3 M Other Conditions Which Apply: Other Conditions Info Field
MWAIT = 1: WAIT# Signal Used
3VCC = 1: 3 Volt VCC Used
EXT = 1: Extension Bytes Follow
RSVD: Reserved, must be 0
01H 0 0 0 0 0 0 0 1 WAIT# Signal Used, 5 V VCC
02H 0 0 0 0 0 0 1 0 WAIT# Signal Not Used, 3 V VCC
03H 0 0 0 0 0 0 1 1
WAIT# Signal Used, 3 V VCC
all others reserved
4: 0 or more ??H Device ID Structures for Other For Memory Mapped PC Card ATA. Device ID Structures
Bytes Devices or Null Devices for When PC Card ATA registers are not at which apply for WAIT#
address offset computation address offset 0, Device ID Structures used in common memory.
preceding this byte must have sizes which One to one
sum to the offset address of the PC Card correspondence with
ATA registers. Device ID Tuple fields.
5: 1 Byte ??H Device Type W Dev Device Type, WPS, Speed
P Speed when WAIT# is supported.
D9H DH = Func 1 1 = 250 ns Func Specific, No WPS, speed 250 PC Card ATA Regs
Spec
00H 0H = Null 0 0 = Null No Memory Mapped PC Card ATA No Device
6: 1 Byte ??H Addr Units - 1 Unit Size Device Size Byte for
01H 1 unit of 2 K bytes 2 Kilobyte Address Space PC Card ATA Regs
7: 0 or more Device ID Structures for When other memory devices exist in Device ID Structures. One
Bytes Common Memory Space used common memory, additional Device ID to one correspondence
by Other Card Functions Structures may occur before the List End with Device ID Tuple
Marker. fields.
8: 1 Byte FFH List End Marker End of Devices End Marker
GUIDELINES
Table 4-17: Sample JEDEC ID TupleÐ18H

Required for PC Card ATA Cards supporting Memory Mapped PC Card ATA Registers
0: 1 Byte 18H CISTPL_JEDEC_C JEDEC ID Common Mem Tuple Code
1: 1 Byte ??H TPL_LINK Link is 2 bytes for PC ATA Only in Link Length
02H 02H = Length for a single memory at offset 0.
JEDEC ID
2: 0 or more ??H JEDEC ID Codes for Each Entry is 2 bytes long.
Bytes (Even) Device ID Structures
preceding the PC Card
ATA Registers description
in the Device Info Tuple.
3: 1 Byte DFH PCMCIAÕs ManufacturerÕs ManufacturerÕs ID Code Byte 1, JEDEC ID of PC
JEDEC ID code. Card ATA Registers in
DFH = PCMCIA common memory
4: 1 Byte ??H PCMCIA JEDEC Device Second Byte of JEDEC ID. Typically, as Byte 2, JEDEC ID of PC
01H Code in this case, the Device Specific Code for Card ATA registers in
02H 01H = No VPP Used PC a 1 Byte Manufacturer Code. Each of common memory
04H Card ATA these codes specifies PC Card ATA with
08H 02H = VPP on Write PC different VPP protocol.
Card ATA
04H = VPP on Media
Access
08H = VPP Continuous PC
Card ATA
5: 0 or more ??H JEDEC ID Codes for Each Entry is 2 bytes long.
Bytes (Even) Device ID Structures after
the PC Card ATA
Registers description in the
Device Info Tuple.
Table 4-18: Sample ManufacturerÕs ID TupleÐ20H

Optional but recommended, for PC Card ATA Devices
1: 1 Byte 20H CISTPL_MANFID ManufacturerÕs ID Tuple Tuple Code

2: 1 Byte 04H Link is 4 bytes Link Length
3: 1 Byte ??H Request 16 bit Code from Low Byte of ManufacturerÕs ID Code Low Byte of ManufacturerÕs
PCMCIA or use your assigned by PCMCIA ID Code
JEDEC assigned
ManufacturerÕs ID code if
you have one
3: 1 Byte ??H High Byte of ManufacturerÕs ID Code High Byte of ManufacturerÕs
or assigned by PCMCIA ID Code
00H Code of 00 used when
manufacturer uses a 1 Byte
JEDEC assigned
ManufacturerÕs code
4: 1 Byte ??H Low Byte of 16 bit Product ManufacturerÕs code for PC Card ATA card Low Byte of Product Code
Code assigned by of appropriate version
Manufacturer
5: 1 Byte ??H High Byte of 16 bit Product ManufacturerÕs code for PC Card ATA card High Byte of Product Code
Code assigned by of appropriate version.
Manufacturer
SOFTWARE GUIDELINES
Table 4-19: Sample Level 1 Version / Product Info TupleÐ15H

Recommended
Order / Size Data 7 6 5 4 3 2 1 0 Description of Contents CIS Function
1: 1 Byte 15H CISTPL_VER_1 Level 1 version / product info Tuple Code
2: 1 Byte ??H Link to next tuple is ?? bytes Link Length
3: 1 Byte 04H TPPLV1_MAJOR PCMCIA 2.0 /JEIDA 4.1 Major Version
4: 1 Byte 01H TPPLV1_MINOR PCMCIA 2.0 / JEIDA 4.1 Minor Version
5: 1 or more 56H Manufacturer Name String 'V' Info String 1
Bytes (ASCIIZ)
65H 'e'
6EH 'n'
64H 'd'
6FH 'o'
72H 'r'
6: 1 Byte 00H End of Manufacturer Name Null terminator
String
7: 1 or more 50H Product Name String (ASCIIZ) 'P' Info String 2
Bytes
43H 'C'
20H ''
43H ÔCÕ
41H ÔAÕ
52H 'R'
44H ÔDÕ
20H ''
41H ÔAÕ
54H 'T'
41H ÔAÕ
8: 1 Byte 00H End of Product Name String Null terminator
9: 0, 2 or more Optional additional Strings with Vendor Specific Strings
bytes Null Terminator for each one
10: 1 Byte FFH End of List Marker FFH List terminator No More Info Strings
Table 4-20: Function ID Tuple, Disk FunctionÐ21H

Required for PC Card ATA Cards
0: 1 Byte 21H CISTPL_FUNCID Function ID tuple Tuple Code
1: 1 Byte 02H TPL_LINK This tuple has 2 info bytes Link Length
2: 1 Byte 04H TPLFID_FUNCTION = 04H Disk Function Code, May be silicon, May PC Card Function Code
be removable
3: 1 Byte 0?H Reserved = 0 R P ROM Present for BIOS on Card System Initialization Byte
POST Configure card at Power On
00H 0 0 0 RP = 00: No ROM, No POST config.
RP = 01: Card has no BIOS ROM but
should be configured at POST
01H 0 0 1
GUIDELINES
Table 4-21: Disk Function Extension TupleÐInterface Type

Required for PC Card ATA Cards
0: 1 Byte 22H CISTPL_FUNCE Function Extension tuple Tuple Code
1: 1 Byte 02H this tuple has 2 info bytes Link Length
2: 1 Byte 01H Disk Function Disk Interface Type Extension Tuple Type for
Extension Tuple Type Disk
3: 1 Byte 01H Disk Interface Type PC Card ATA Interface Interface Type
Table 4-22: Sample Disk Function ExtensionÐPC Card ATA Parameters Tuple
Strongly Recommended. Required for PC Card Standard Feb. 1995 and Dual Drive PC Card
ATA
0: 1 Byte 22H CISTPL_FUNCE Function Extension tuple Tuple Code
1: 1 Byte 03H this tuple has 3 info bytes Link Length
2: 1 Byte 02H or Disk Function Basic PC Card ATA Features Function Extension Tuple Type for
03H Extension Tuple Type Extension tuple Disk Function
02H 02H Single Drive Features
or Master of Dual Drive Features
03H 03H Slave of Dual Drive Features
3: 1 Byte R R R D U S V V=0: No VPP Required Basic ATA Option

V=1: VPP on Modify Media Parameters Byte 1
V=2: VPP on any operation
V=3: VPP continuous
S=1: Silicon; =0: Rotating
U=1: ID Drive Mfg/SN Unique
R: Reserved, Must Be 0.
D=1: Dual Drives on Card (Pending)
04H 0 0 0 0 1 0 0 Rotating, No VPP, Unique Serial # Sample 1
0CH 0 0 0 0 1 1 0 Silicon, No VPP, Unique Serial # Sample 2
0DH 0 0 0 0 1 1 1 Silicon, VPP to Write, Unique Serial
Sample 3
4: 1 Byte ??H R I E N P P P P P0 Sleep Mode Supported Basic ATA Options
3 2 1 0 P1 Standby Mode Supported Parameters Byte 2
P2 Idle Mode Supported
P3 Drive Auto Power Control
N Some Config Excludes 3X7
E Index Bit is Emulated
I Twin IOIS16# Data Reg Only
R: Reserved, Must Be 0
0FH 0 0 0 0 1 1 1 1 All power modes supported but power
commands are not needed to minimize
power. No Configs exclude I/O port
3F7H/377H, Index bit is not emulated, Twin
Card not implemented, IOIS16# handling is
not specified.
SOFTWARE GUIDELINES
Table 4-23: Sample Configuration Tuple

Required for all PC Card ATA cards.
1: 1 Byte 1AH CISTPL_CONF Configuration Tuple Tuple Code
2: 1 Byte ??H Link Length is N bytes Link to next tuple
3: 1 Byte ??H RFS RMS RAS RFS Bytes in Reserved Field Size of fields byte
RMS Bytes in Reg Mask - 1 (TPCC_SZ)
RAS Bytes in Base Addr - 1
01H 0 0 1 No Reserved Field, 1 Byte Register Mask,
2 byte Config Base Address
4: 1 Byte ??H TPCC_LAST Entry with Config Index of ?? is final entry last entry of configuration
in table table
5: 1-4 Bytes 00H TPCC_RADR (lsb) Configuration Registers are Location of Config
02H TPCC-RADR (msb) located at 200H in Reg Space Registers
6: 1 Byte ??H R R R E S P C I I Configuration Index TPCC_RMSK
(when more Required for All PC Card ATA Cards.
1 1
configuration C Configuration and Status
Registers are Required only if power-down, audio, or
defined, this field Signal on Change is supported.
may be longer
P Pin Replacement
Required only if Ready, Write Protect, or
BVDs supported in I/O mode.
S Socket and Copy
Required only for cards supporting Twin
Card option.
R Reserved for future use.
07H 0 0 0 0 0 1 1 1 First 3 Configuration Registers present
(No Socket and Copy)
0FH 0 0 0 0 1 1 1 1 First 4 Configuration Registers present
GUIDELINES
Configuration
Required if Memory Mapped ATA Registers Supported
1: 1 Byte 1BH CISTPL_CFTABLE_ENTRY Configuration Table Entry Tuple Tuple Code
2: 1 Byte ??H Link to next tuple is N bytes. Also limits Link to next tuple
size of this tuple to N+2 bytes.
3: 1 Byte ??H I D Configuration Index I=1: Interface Byte Follows TPCE_INDX
D=1: Independent ÒDefaultÓ Entry
Card Configuration Index for Entry
C0H 1 1 0 Interface Byte Follows, Default Entry, PC Card ATA Memory
Configuration Index = 0 Mapped I/O
Configuration.
4: 1 Byte C0H W R P B Interface Type WAIT=1: Wait Used on Mem Cycles TPCE_IF
READY=1: Ready Active
WP=1: Write Prot Switch Active
BVD=1: BVD1 and BVD2 Active
IF Type=0: Memory Only I/F
IF Type=1: I/O and Memory I/F
IF Type=2-3,8-F: Reserved
IF Type=4-7: Custom Interface
C0H 1 1 0 0 0 Mem Interface (0); BvdÕs and wProt not TPCE_IF
used; Ready active and Wait used for
memory cycles.
5: 1 Byte M MS IR IO T P P Power info type TPCE_FS
T Timing info present
IO I/O port info present
IR Interrupt info present
MS Mem space info type
M Misc info byte(s) present
A1H 1 1H 0 0 0 1H Has VCC, Mem Space and Misc Info VCC Only Card
A2H 1 1H 0 0 0 2H Has VCC, VPP, Mem Space and Misc Info VCC, VPP Card
present
6: 1 Byte 01H R D PI AI SI H LV N Nominal Voltage Only Follows Power Parameters for VCC
I V V NV Nominal Voltage Info present
LV Minimum Voltage Info present
HV Maximum Voltage Info present
SI Static Current Info present
AI Average Current Info present
PI Peak Current Info present
DI Power Down Current Info present
R Reserved, must be 0.
01H 0 0 0 0 0 0 0 1 Nominal Voltage Only Follows
11H 0 0 0 1 0 0 0 1 Nom Voltage, Average Current
SOFTWARE GUIDELINES
Configuration (Continued)
Required if Memory Mapped ATA Registers Supported
7: 1 or more X Mantissa Exponent VCC Nominal is 5 Volts VCC Nominal Value
bytes present 55H 0 AH= 5.0 5H= 1 V
only if NV=1
8: 1 or more X Mantissa Exponent Icc Average Value

bytes present 4EH Icc Average is 450 mA
0 9H= 4.5 6H=
only if AI=1 1EH 100mA Icc Average is 150 mA
0 3H= 1.5
6H=
100mA
9: 1 Byte. ??H R D P A S H L N See Above Power Parameters for VPP
I I I I V V V
Present only if
TPCE_FS
Power = 2.
10: 1 Byte. 0EH X Mantissa Exponent

Present only if 0 1H = 1.2 6H = 10 V VPP Nominal is 12 Volts VPP Nominal Value
TPCE_FS
Power = 2.
11: 2 Bytes 08H Length in 256 bytes pages (lsb) Length of Mem Space is 2 KB TPCE_MS
Length
00H Length in 256 byte pages (msb) Starts at 0 on card
12: 1 Byte 20H X R P R A T Twin Cards Allowed TPCE_MI
O Audio Supported
Read Only Mode
Power Down Supported
Reserved
X More Misc Fields Bytes
09AH 20H 0 0 1 0 0 0 Power-Down, but no Twin Card. TPCE_MI
0 0 0 0 0 1 Twin Card: 2 Cards as Master/Slave
GUIDELINES
Required for PC Card ATA Devices
3: 1 Byte ??H I D Configuration Index I = 1: Interface Byte Follows TPCE_INDX
D = 1: Default Table Entry
Conf Index: Index Value written to Card
Config Option to select this entry
??H 1 1 ??H Default Entry, Interface specified in next I/O Mapped Contiguous
byte 16 registers
Configuration.
Card Configuration 1
C1H 01H
4: 1 Byte W R P B Interface Type See Mem Mapped Sample Tuple TPCE_IF
41H 0 1 0 0 1 I/O Interface (); BvdÕs and wProt not used;
READY active and WAIT# not used for
memory cycles.
5: 1 Byte M MS IR IO T P See Mem Mapped Sample Tuple TPCE_FS
99H 1 0H 1 1 0 1H Has VCC, I/O, IRQ and Misc Info VCC Only Card
9AH 1 0H 1 1 0 2H Has VCC, VPP, I/O, IRQ and Misc Info VCC, VPP Card
present
6: 1 Byte ??H R D PI AI SI H LV N See Mem Mapped Sample Tuple Power Parameters for VCC
I V V
11H 0 0 0 1 0 0 0 1 Nom Voltage, Average Current
7: 1 or more X Mantissa Exponent VCC Nominal is 5 Volts VCC Nominal Value
bytes present 55H 0 AH= 5.0 5H= 1 V
only if NV=1
8: 1 or more X Mantissa Exponent Icc Average Value

bytes present 4EH Icc Average is 450 mA
0 9H= 4.5 6H=
only if AI=1 1EH 100mA Icc Average is 150 mA
0 3H= 1.5
6H=
100mA
9: 1 Byte. ??H R D PI AI SI H LV N See Mem Mapped Sample Tuple Power Parameters for VPP
I V V
Present only if
TPCE_FS
Power = 2
10: 1 Byte. 0EH X Mantissa Exponent

Present only if 0 1H = 1.2 6H = 10 V VPP Nominal is 12 Volts VPP Nominal Value
TPCE_FS
Power = 2
SOFTWARE GUIDELINES
Required for PC Card ATA Devices (Continued)
11: 1 Byte R S E IO AddrLines IO AddrLines: #lines decoded TPCE_IO
Eight bit only hosts supported
Sixteen bit hosts supported
Range (I/O) follows
64H 0 1 1 4 Supports both 8 and 16 bit I/O hosts. 4
Address lines and no range so 16 registers
and host must do all selection decoding.
12: 3 Bytes S P L M Level or Mask Share (IRQ) Logic Active TPCE_IR
0 IRQ Level Pulse Mode IRQ Supported TPCE_IR
1 V B I N Level Mode IRQ Supported
M: Bit Mask of IRQs Present
IRQ Level (single)
Vendor Unique IRQ
Bus Error IRQ
IO Check IRQ
Non-Maskable IRQ
F0H 1 1 1 1 0 0 0 0 IRQ Sharing Logic Active in Card Control
& Status Register, Pulse and Level Mode
Interrupts supported, Recommended IRQÕs
any of 0 through 15 (F)
FFH 1 1 1 1 1 1 1 1 IRQ Levels to be routed 0 - 15 TPCE_IR

recommended. Mask Extension Byte 1
Bit 0 = IRQ0
FFH 1 1 1 1 1 1 1 1 Recommended routing to any Ònormal, TPCE_ IR
maskableÓ IRQ. Mask Extension Byte 2
Bit 0 = IRQ8
13: 1 Byte ??H X R P R A T See Mem Mapped Sample Tuple TPCE_MI
O
20H 0 0 1 0 0 0 Power-Down, but no Twin Card. TPCE_MI
0 0 0 0 0 1 Twin Card: 2 Cards as Master/Slave
without Power Down
GUIDELINES
Table 4-26: Sample ATA Primary I/O Mapped Configuration Entry Tuple
3: 1 Byte I D Configuration Index I = 1: Interface Byte Follows TPCE_INDX
??H ? 0 ??H Non Default Entry: Dependent on Previous ATA Primary Address
Default Entry (Contiguous I/O). All 1F0-1F7, 1F6-3F7
unspecified fields taken from specified in Configuration.
next byte
1 0 Sample Configuration Index = 2
82H 02H
4: 1 Byte W R P B Interface Type See Mem Mapped Sample Tuple TPCE_IF
memory cycles.
18H 0 0H 1 1 0 0H Has Power, Timing, Mem Space and Misc

Info taken from contiguous configuration.
I/O and IRQ Info specified here.
6: 1 Byte E4H R S E IO AddrLines See Contiguous I/O Sample Tuple TPCE_IO
EAH 1 1 1 0aH Supports both 8 and 16 bit I/O hosts. 10
Address lines and with range(s)
7: 1 Bytes ??H LS AS N Ranges N Ranges: Number of Address Ranges
following minus 1
AS: Size of Addresses
0: No Addresses Present
1: 1 Byte (8 bit) Addresses
LS: Size of Lengths
0: No Lengths Present
1: 1 Byte (8 bit) Lengths
61H 1 2 1 2 Address Ranges with 2 byte addresses
and 1 byte lengths
8: 2 Bytes F0H 1F0 (LSB) = F0H First I/O Base Address (LSB) First I/O Range Addr
01H 1F0 (MSB) = 01H First I/O Base Address (MSB) First I/O Range Addr
9: 1 Byte 07H 8 Byte Length - 1 = 07H First I/O Length minus 1 First I/O Range Len
SOFTWARE GUIDELINES
Table 4-26: Sample ATA Primary I/O Mapped Configuration Entry Tuple
Required for PC Card ATA Devices (Continued)
10: 2 Bytes F6H 3F6 (LSB) = F6H Second I/O Base Address (LSB) 2nd I/O Range Addr
03H 3F6 (MSB) = 03H Second I/O Base Address (MSB) 2nd I/O Range Addr
11: 1 Byte 01H 2 Byte Length - 1 = 01H Second I/O Length minus 1 2nd I/O Range Len
12: 1 Bytes ??H S P L M IRQ Level See Contiguous I/O Sample Tuple TPCE_IR
EEH 1 1 1 0 EH IRQ Sharing Logic Active in Card Control
Interrupts supported, recommended IRQÕs
IRQ14 for ATA Compatibility
GUIDELINES
Table 4-27: Sample ATA Secondary I/O Mapped Configuration Entry Tuple
3: 1 Byte ??H I D Configuration Index I = 1: Interface Byte Follows TPCE_INDX
??H ? 0 ??H Non Default Entry: Dependent on Previous ATA Secondary Address
Default Entry (Contiguous I/O). All 170-177, 176-377
unspecified fields taken from specified in Configuration.
next byte
Sample Configuration Index = 2
83H 1 0 03H
4: 1 Byte 41H W R P B Interface Type See Mem Mapped Sample Tuple TPCE_IF
memory cycles.
18H 0 0H 1 1 0 0H Has Power, Timing, Mem Space and Misc
Info taken from contiguous configuration.
I/O and IRQ Info specified here.
6: 1 Byte E4H R S E IO AddrLines See Contiguous I/O Sample Tuple TPCE_IO
EAH 1 1 1 0AH Supports both 8 and 16 bit I/O hosts. 10
Address lines and with range(s)
7: 1 Bytes ??H LS AS N Ranges See ATA Primary I/O Tuple Sample
61H 1 2 1 2 Address Ranges with 2 byte addresses
and 1 byte lengths
8: 2 Bytes 70H 170 (LSB) = 70H First I/O Base Address (LSB) First I/O Range Addr
01H 170 (MSB) = 01H First I/O Base Address (MSB) First I/O Range Addr
9: 1 Byte 07H 8 Byte Length - 1 = 07H First I/O Length minus 1 First I/O Range Len
10: 2 Bytes 76H 376 (LSB) = 76H Second I/O Base Address (LSB) 2nd I/O Range Addr
03H 376 (MSB) = 03H Second I/O Base Address (MSB) 2nd I/O Range Addr
11: 1 Byte 01H 2 Byte Length - 1 = 01H Second I/O Length minus 1 2nd I/O Range Len
12: 1 Bytes ??H S P L M IRQ Level See Contiguous I/O Sample Tuple TPCE_IR
EEH 1 1 1 0 EH IRQ Sharing Logic Active in Card Control
Interrupts supported, recommended IRQÕs
IRQ14 for ATA Compatibility.
SOFTWARE GUIDELINES
Table 4-28: Sample No Link Tuple: 14H

Optional but recommended, for PC Card ATA Devices
1: 1 Byte 14H CISTPL_NO_LINK No Link Control Tuple Tuple Code
2: 1 Byte 00H Link is 0 bytes Link Length
This tuple prevents the CIS parser from attempting the implied long link to address 0 in common
memory after parsing the first tuple chain on the card.
Table 4-29: Sample End of Tuple Chain: FFH

Required for PC Card ATA Devices as the last tuple on each chain which is not terminated
with a link value of FFH.
1: 1 Byte FFH CISTPL_END End of List Tuple Tuple Code
GUIDELINES
4.7 Guideline for CIS Tuples for 3.3 or 3.3/5 volt Operation
4.7.1 Introduction
4.7.1.1 Purpose
This document is designed to provide implementation examples and further explanations of the PC
Card standards in order to:
· enhance the interoperability of PC Card components, including card hardware and software,
system hardware and software, and applications.
· facilitate the development of PC Card hardware and software by increasing the understanding
of the standard by PC Card implementation community.
These guidelines are not requirements made by the PCMCIA/JEIDA standards organizations.
Rather, they are implementation examples, suggestions and hints.
4.7.1.2 Scope
This document presents CIS examples for three distinct PC Card implementation options. Section
4.7.2 CIS for a PC Card with 3.3 volt Only Operation, provides a CIS example for a 16-bit PC Card
that operates at 3.3 volts VCC only. Section 3 provides a CIS example for a 16-bit PC Card that can
operate at either 3.3 or 5 volts. Section 4 provides a CIS example for a CardBus PC Card.
The CIS examples shown in this document are intended to describe only the tuples and tuple fields
effected by the 3.3 or 3.3/5 volt operation characteristics of the card. The implementor should refer
to the guideline for the specific card being implemented, for example, MODEM, ATA, or CardBus,
for the general CIS guideline for the card and consider this guideline additional material dealing
with 3.3 or 3.3/5 volt operation that may add tuples or define certain tuple fields.
This guidelines section is meant to be an illustration of how the PC Card Standard is used and not
an additional source of such standards.
SOFTWARE GUIDELINES
4.7.2 CIS for a PC Card with 3.3 volt Only Operation
4.7.2.1 CISTPL_DEVICE_OC
In this guideline, the CISTPL_DEVICE_OC has the VCC field set to one (1) in the Other Conditions
Information Field and provides Device Info fields describing operation at 3.3 volts. If a
CISTPL_DEVICE_A tuple exists, CISTPL_DEVICE_OA tuple shall also be present to describe the 3.3
volt operation of attribute memory.
Byte Data 7 6 5 4 3 2 1 0 Notes

01 1CH CISTPL_DEVICE_OC
12 03H Link
23 02H Ext Rsvd (0) VCC(01) MWA Other conditions information
IT field. In this example there is no
(0)
extension and VCC is set to one
(1)
indicating 3.3 volt operation.
34 D9H Device Type WPS Device Speed Device Info field. In this example
the device type is function
(DH) (1) (1H)
specific (DH), WPS indicates the
device is always writeable, and
the device speed is shown as
250 ns.
45 FFH End of device info
GUIDELINES
4.7.2.2 CISTPL_CONFIG
A CISTPL_CONFIG may exist to describe interface, power, timing, window, interrupt, and other
information for 3.3 volt operation. This shall be followed by CISTPL_CFTABLE_ENTRY tuples for
each configuration supported by the PC Card. In this example, two configuration entries are shown
describing two different interface alternatives, both at 3.3 volts.

01 1AH CISTPL_CONFIG
12 05H Link
23 01H TPCC_RFS TPCC_RMSZ TPCC_RAS Size of fields. In this example, 1
Z Z mask is defined and the
(0)
configuration register address is
(0) (1)
2 byte in length.
34 01H RFU (0) Last Index (1) Configuration Table Last Entry
Number. In this example, the last
configuration index is 1.
45 00H Low order address Bytes 5 and 6 provide the
Configuration Option Register
address. In this example that
address is 200H.
56 02H High order address
67 07H Config reg presence mask Configuration register presence
mask. In this example, three
registers are declared:
Configration Option,
Configuration and Status, and Pin
Replacement.
4.7.2.3 CISTPL_CFTABLE_ENTRY
A CISTPL_CFTABLE_ENTRY for each different configuration supported by the PC Card follows the
CISTPL_CONFIG tuple. Following the example above, two configurations are described.
SOFTWARE GUIDELINES
4.7.2.3.1 First CISTPL_CFTABLE_ENTRY

The first configuration describes a memory interface at 3.3 volts VCC.

01 1BH CISTPL_CFTABLE_ENTRY
12 0DH Link
23 C0H Int Def Conf Index Configuration Index byte. In this
example, the configuration index
(1) (1) (0)
number is 0, the interface flag
indicates that the interface will
be described, and the default flag
is set indicating that defined
values replace any previously
defined values but may be used
in following entries.
34 COH Wt R WP BVD Int Type Interface description field. In this
example the byte states that
(1) (1) (0) (0) (0)
WAIT# and READY are active,
Write Protect and BVD's are not
used, and the interface type is
memory.
45 21H Mis Mem IRQ IO Tim Pwr Feature selection field. In this
example VCC power, and a
(0) (01) (0) (0) (0) (01)
single 2-byte length memory
space are described.
56 37H RFU Prdn Peak Avg Stat Max Min Nom Power description parameter
selection field. In this example
(0) I I I I V (1) V V
Nominal V, Minimum V,
(0) (1) (1) (0) (1) (1) Maximum V, Average I, and
Peak I will be described.
67 B5H Ext Mantissa (0110) Exponent (101) Bytes 7 and 8 describe that the
nominal VCC is 3.3 volts.
(1)
78 1EH Ext Extension (1EH/ 30B)
(0)
89 35H Ext Mantissa (0110) Exponent (101) Describes the minimum VCC as
3.0 volts.
(0)
maximum VCC is 3.6 volts.
(1)
1011 3CH Ext Extension (3CH/ 60B)
(0)
1112 1EH Ext Mantissa (0011) Exponent (110) Describes average current as
150ma.
(0)
1213 46H Ext Mantissa (1000) Exponent (110) Describes peak current as
400ma.
(0)
1314 08H Bytes 14 and 15 describe a 2K
(8x256 bytes) memory window
starting at address 0000.
1415 00H
GUIDELINES
4.7.2.3.2 Second CISTPL_CFTABLE_ENTRY

The second configuration describes an I/O interface at 3.3 volts VCC.

12 0CH Link
(1) (1) (1)
34 41H Wt R WP BVD Int Type Interface description field. In this
(0) (1) (0) (0) (1)
READY is active, WAIT#, Write
Protect and BVD's are not used,
and the interface type is I/O.
example VCC power, and I/O
(0) (00) (0) (1) (0) (01)
(0) I I I I V (1) V V
(1)
(0)
3.0 volts.
(0)
(1)
(0)
150ma.
(0)
400ma.
(0)
1314 64H Rng 16B 8B IO address lines Describes an I/O window
containing 16 contiguous
(0) (1) (1) (00100)
registers accessable in either 8
or 16 bit accesses.
Note: Since the first table entry described only a memory window and the second only an I/O window, Default
had to be set in the second entry to eliminate the memory window described in the first entry. If both entries
had been memory windows or both entries had been I/O windows, the Default bit could have been negated in
the second entry and the power description not repeated.

SOFTWARE GUIDELINES
4.7.3 CIS for a PC Card with 3.3 or 5 volt Operation
4.7.3.1 CISTPL_DEVICE
As noted previous, the CISTPL_DEVICE tuple is required to be the first tuple in the CIS. The
CISTPL_DEVICE tuple indicates characteristics for 5 volt operation and a CISTPL_DEVICE_OC tuple
shall exist to indicate 3.3 volt operation and characteristics.

01 01H CISTPL_DEVICE
12 02H Link
23 DAH Device Type WPS Device Speed Device Info field. In this
example the device type is
(DH) (1) (2H)
function specific (DH), WPS
indicates the device is always
writable, and the device speed
is shown as 200ns.
34 08H Number of address units - 1 (01H) Size Code (0H) Device Size (Two 512 byte
units or 1 K byte)
A CISTPL_DEVICE_A tuple may also be present in the CIS. The CISTPL_DEVICE_A tuple also
describes 5 volt operation and requires a CISTPL_DEVICE_OA tuple be present to describe 3.3 volt
operation.
In this example, the CISTPL_DEVICE_OC has the VCC field set to one (1) in the Other Conditions
Information Field and provides Device Info fields describing operation at 3.3 volts.

12 03H Link
23 02H Ext Rsvd (0) VCC MWA Other conditions information
IT (1) field. In this example there is no
(0) (01)
extension, VCC is set to one
34 D9H Device Type WPS Device Speed Device Info field. In this example
(DH) (1) (1H)
device is always writable, and
the device speed is shown as
250ns.
If a CISTPL_DEVICE_A tuple exists, a CISTPL_DEVICE_OA tuple shall also be present describing

3.3 volt operation of attribute memory.
GUIDELINES
Note: When the Device Info field in both the CISTPL_DEVICE and
CISTPL_DEVICE_OC tuples is non-zero the host is made aware that the card
is capable of operating at either 3.3 or 5 volts. In addition, the host knows
that the common memory cycle time is 200ns when operating at 5 volts and
250ns when operating at 3.3 volts.

SOFTWARE GUIDELINES
4.7.3.3 CISTPL_CONFIG
A CISTPL_CONFIG tuple may exist to describe the interface, power, window, and other information
for 3.3 and 5 volt operation. The CISTPL_CONFIG tuple is followed by CISTPL_CFTABLE_ENTRY
tuples for each configuration supported by the PC Card. In this example, four configuration entries
are described, one for each of two interface alternatives at each of the two voltage alternatives.

01 1AH CISTPL_CONFIG
12 05H Link
23 01H TPCC_RFSZ TPCC_RMSZ TPCC_RASZ Size of fields. In this example 1
mask is defined and the
(0) (0) (1)
configuration register address is 2
byte in length.
34 11H RFU (0) Last Index (11H) Configuration Table Last Entry
Number. In this example the last
configuration index is 11H.
45 00H Low order address Bytes 5 and 6 provide the
Configuration Option Register
address. In this example that
address is 200H.
56 02H High order address
67 07H Config reg presence mask Configuration register presence
mask. In this example three
registers are declared:,
Configuration Option, Configuration
and Status, and Pin Replacement.
4.7.3.4 CISTPL_CFTABLE_ENTRY
A CISTPL_CFTABLE_ENTRY tuple for each configuration supported by the PC Card follows the
CISTPL_CONFIG tuple. Following the example above, four configurations are described.
GUIDELINES
4.7.3.4.1 First CISTPL_CFTABLE_ENTRY

The first configuration describes a Memory interface at 3.3 volts VCC.

12 0DH Link
(1) (1) (0)
(1) (1) (0) (0) (0)
memory.
(0) (01) (0) (0) (0) (01)
(0) I I I I V V V
(0) (1) (1) (0) (1) (1) (1) Maximum V, Average I, and
(1)
(0)
3.0 volts.
(0)
(1)
(0)
150ma.
(0)
400ma.
(0)
memory window starting at
address 0000.
1415 00H

SOFTWARE GUIDELINES
4.7.3.4.2 Second CISTPL_CFTABLE_ENTRY

The second configuration describes an I/O interface at 3.3 volts VCC.

12 0CH Link
(1) (1) (1)
(0) (1) (0) (0) (1)
(0) (00) (0) (1) (0) (01)
(0) I I I I V (1) V V
(1)
(0)
3.0 volts.
(0)
(1)
(0)
150ma.
(0)
400ma.
(0)
(0) (1) (1) (00100)
or 16 bit accesses.
GUIDELINES
4.7.3.4.3 Third CISTPL_CFTABLE_ENTRY

The third configuration describes a memory interface at 5 volt VCC.

12 0DH Link
(1) (1) (10H)
number is 10H, the interface flag
(1) (1) (0) (0) (0)
memory.
(0) (01) (0) (0) (0) (01)
(0) I I I I V (1) V V
67 55H Ext Mantissa (1010) Exponent (101) Describes that the nominal VCC
is 5 volts.
(0)
78 C5H Ext Mantissa (1000) Exponent (101) Bytes 8 and 9 describe the
minimum VCC as 4.75 volts.
(1)
89 4BH Ext Extension (4BH/ 75B)
(0)
910 D5H Ext Mantissa (1010) Exponent (101) Bytes 10 and 11 describe that the
(1)
1011 19H Ext Extension (19H/ 25B)
(0)
120ma.
(0)
1213 3EH Ext Mantissa (0111) Exponent (110) Describes peak current as
350ma.
(0)
memory window starting at
address 0000.
1415 00H

SOFTWARE GUIDELINES
4.7.3.4.4 Fourth CISTPL_CFTABLE_ENTRY

An I/O interface at 5 volts VCC.

12 0CH Link
(1) (1) (11H)
number is 11H, the interface flag
(0) (1) (0) (0) (1)
(0) (00) (0) (1) (0) (01)
(0) I I I I V (1) V V
67 55H Ext Mantissa (1010) Exponent (101) Describes that the nominal VCC
is 5 volts.
(0)
78 C5H Ext Mantissa (1000) Exponent (101) Bytes 8 and 9 describe the
minimum VCC as 4.75 volts.
(1)
89 4BH Ext Extension (4BH/ 75B)
(0)
910 D5H Ext Mantissa (1010) Exponent (101) Bytes 10 and 11 describe that the
(1)
1011 19H Ext Extension (19H/ 25B)
(0)
120ma.
(0)
1213 3EH Ext Mantissa (0111) Exponent (110) Describes peak current as
350ma.
(0)
(0) (1) (1) (00100)
or 16 bit accesses.
Note: By having two entries for each window, one at each VCC level, a host
capable of operating the card at either 3.3 or 5 volts can choose the better
power consumption alternative, 495 milliwatts average at 3.3 volts vs 600
milliwatts average at 5 volts, or the better performance alternative, 200ns
cycle time at 5 volts vs 250 ns cycle time at 3.3 volts.
GUIDELINES
4.7.4 CIS for a CardBus PC Card

Since a CardBus PC Card only operates at 3.3 volts VCC, a CISTPL_DEVICE tuple is not required. If
memory space is used, a CISTPL_DEVICE_OC tuple is required. A CISTPL_CONFIG_CB tuple and
a CISTPL_CFTABLE_ENTRY_CB tuple are required for each function on the card.
The CISTPL_DEVICE_OC has the VCC field set to one (1) in the Other Conditions Information Field
and provides Device Info fields describing operation at 3.3 volts.

12 03H Link
23 02H Ext Rsvd (0) VCC MWA Other conditions information
IT(0) field. In this example there is no
(0) (01)
extension, VCC is set to one
34 D8H Device Type WPS Address Space Indicator Device Info field. In this example
(DH) (1) (1H)
device is always writable.
4.7.4.2 CISTPL_CONFIG_CB
A CISTPL_CONFIG_CB descibes the interface, power, timing, window, interrupt, and other
information for 3.3 volt operation. The CISTPL_CONFIG_CB tuple shall be followed by
CISTPL_CFTABLE_ENTRY_CB tuples for each configuration supported by the PC Card. In this
example, one configuration entry is shown describing operation at 3.3 volts.

01 04H CISTPL_CONFIG_CB
12 06H Link
23 03H TPCC_RFSZ Reserved, must be zero TPCC_ADDR Size of fields. For CardBus PC
(0) (3) Cards the four status registers
are always present.
34 00H RFU (0) Last Index (0) Configuration Table Last Entry
Number. In this example the last
configuration index is 0.
45 01H Address Space Offset LSB (0) Rsvd Address Space Register Address. Reside in
(0) Indicator(1) Base Memory Area 1 at offset
100H.
56 01H Address Space Offset 2 (01H)
67 00H Address Space Offset 3 (00H)
78 00H Address Space Offset MSB (00H)

SOFTWARE GUIDELINES
4.7.4.3 CISTPL_CFTABLE_ENTRY_CB
Following the CISTPL_CONFIG_CB will be a CISTPL_CFTABLE_ENTRY_CB for each different
configuration alternative that the function can provide. Following the example from above, one
configuration is described.

01 05H CISTPL_CFTABLE_ENTRY_C
B
12 0CH Link
23 40H RFU Def Conf Index Configuration Index byte. In this
(0) example, the configuration index
(1) (0)
number is 0, and the default flag
34 21H Mis RFU Mem IRQ IO RFU Pwr Feature selection field. In this
(0) example VCC power, and a
(0) (0) (0) (0) (01)
Memory Space descriptor are
(1)
present.
(0) I I I I V (1) V V
(1)
(0)
3.0 volts.
(0)
(1)
(0)
150ma.
(0)
(0) 400ma.
1213 04H Memory Base Address Register (04H) RFU Base Address Register 4
(0) describes the memory.

PC Card Standard 7.0

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PC Card Standard 7.0

Enviado por

Direitos autorais:

Formatos disponíveis

P C C A R D S TA N D A R D

Document No. 0299-01-2000

2. Definitions and Terminology ____________________________9

Ó 1999 PCMCIA/JEIDA iii

4.11.1.1 Auto-Indexing Mass Storage (AIMS).............................................................................................................2 3

1.1 PC Card Standard Overview

1.2.1 History of the PC Card Standard

1.2.2 PCMCIA Standard Release 1.0/JEIDA 4.0 (June 1990)

1.2.3 PCMCIA Standard Release 2.0/JEIDA 4.1 (September 1991)

1.2.4 PCMCIA Standard Release 2.01 (November 1992)

1.2.5 PCMCIA Standard Release 2.1/JEIDA 4.2 (July 1993)

1.2.6 PC Card Standard February 1995 (Release 5.0)

1.2.6.1 PC Card Standard March 1995 Update

1.2.6.2 PC Card Standard May 1995 Update

1.2.6.3 PC Card Standard November 1995 Update

1.2.6.4 PC Card Standard March 1996 Update

1.2.7 PC Card Standard March 1997 (Release 6.0)

1.2.8 PC Card Standard 6.1 Update (April 1998)

· Small PC Card Form Factor

1.2.9 PC Card Standard Release 7.0 (February 1999)

1.4 Future Trends

1.5 The PC Card Standard ¾ A PCMCIA and JEIDA Joint

2. DE F IN IT ION S AN D TE R MIN OL OGY

4.1 Electrical Specification

4.2 Physical Specification

4.3 Metaformat Specification

4.4 Card Services Specification

4.5 Socket Services Specification

4.6 Media Storage Formats Specification

4.7 PC Card ATA Specification

4.8 XIP (eXecute In Place) Specification

4.10 Host System Specification

4.11 Specific Extensions

4.11.1 PCMCIA Specific Extensions

4.11.1.1 Auto-Indexing Mass Storage (AIMS)

4.11.1.2 15 Position Shielded Latching I/O Connector

4.11.1.3 Modem I/O Connector for Open Systems

4.11.1.4 Recommended Extensions

4.11.2 JEIDA Specific Extensions

4.11.2.1 Small Block FLASH Format

4.11.2.3 DRAM Card Specifications

Combined Terms and Abbreviations

Host Bus I/F

Primary Bus I/F

RREADY bit for detailed information about this signal.

Document No. 0299-02-2000

1.2 Conventions .........................................................................................................................3

2. Common Pin Description ________________________________5

2.2 Interface Configuration Pins ...............................................................................................6

3. Card Type Detection Mechanism _________________________7

4. 16-bit PC Card Electrical Interface _______________________11

4.2 Pin Assignments................................................................................................................11

© 1999 PCMCIA/JEIDA iii

4.3.1 Memory Address Space........................................................................................................................................................1 4

4.4 Signal Description..............................................................................................................17

4.5 DMA Signals Replacing I/O Interface Signals.................................................................26

4.6 Memory Function...............................................................................................................27

4.6.1.1 Common Memory Read Function for PC Cards ...........................................................................................2 7

4.7 Timing Functions...............................................................................................................30

4.8 DMA Function...................................................................................................................35

4.9 Electrical Interface .............................................................................................................39

4.10 Card Detect......................................................................................................................43

4.13 I/O Function....................................................................................................................46