PCMCIA may make dynamic resource management a reality
John Bryan
Without a doubt, the term PCMCIA is one of the most widely misunderstood acronyms in the computer industry today. The usual quip is that it stands for ``people can't remember computer-industry acronyms,'' but in reality it stands for Personal Computer Memory Card International Association, the group responsible for setting the standards for the cards so many of us refer to as PCMCIA devices. The correct name for the technology--for right now, at least--is PC Card.
But further points of confusion exist. The standards aren't just for personal computers; they apply to many other devices as well. The standards support not only flash memory, RAM, and ROM, but also such devices as modems and fax modems, LAN
adapters, cellular communications, and rotating and solid-state storage. As you read this, the association is working to effect changes in both the technology and the products that are referred to as PCMCIA devices, including a change in the name of the standard itself.
Originally conceived and developed to provide memory for the Poquet computer, PCMCIA was the brainchild of Neil Chandra of Poquet (which is now a division of Fujitsu), who brought together diverse industry interests to forge a specification that provides plug-in access to memory resources that are external to a given platform. Chandra sat on the board of directors of the association for many years and is still actively involved in the development of standards.
In short, PCMCIA has grown to encompass much more than access to a memory card. And therein lie the problems. Because PCMCIA is used to access so many types of devices, each with its own electrical and logical interface and timing considerations, conflicts frequently arise
among cards, platforms, operating systems, applications, and driver software.
Although not sanctioned by an official standards body such as the IEEE or ANSI, the PCMCIA specifications nonetheless provide a series of recommended guidelines for the physical specification of cards; the physical and electrical specification of sockets; and the interaction among platforms, system software, and cards. Because so many firms are actively involved in the PCMCIA (the group has between 450 and 500 member companies), its guidelines carry the weight of a standard.
The PCMCIA group defines three types of cards and sockets for device support. All the cards have the same length and width (85.6 by 54 mm, roughly the size of a credit card), and each plugs into the same 68-pin connector. But differences exist in the thickness of the cards, and, correspondingly, the size of the socket openings.
A Type I card can be up to 3.3 mm thick. This form factor is used primarily for RAM and ROM cards, on which all th
e ICs are surface-mounted so that they are nearly flush with the printed circuit board itself. A Type II card can be up to 5.5 mm thick; it is into this category that most modem and fax modem cards, LAN adapters, and other types of purely electronic devices fall. Connectors, generally the RJ-11 phone jacks used for modems and 10Base-T, are usually attached via a flexible connector on the end of the card facing away from the bus interface. Finally, Type III cards, which can be up to 10.5 mm thick, are used mostly for rotating storage and other specialized products.
Socket sizes are also classified by type. Type I sockets support only Type I cards, Type II sockets support Type I and II cards, and Type III sockets support all three card thicknesses. Many of today's better portable systems come with two Type II sockets positioned in a piggyback fashion, so the system can use two Type I cards, a Type I and a Type II card, two Type II cards, or a single Type III card.
Type specifications refer mainly
to the dimensions of the hardware; users also must contend with release specifications, which have implications for both hardware and software and are not related specifically to a type of card. PCMCIA release 1.0 cards, the first-generation products, were for memory only and did not support I/O operations. PCMCIA release 2.x introduced I/O capabilities into the standard, but it didn't modify the hardware in any visible way. Release 1.0 cards work in release 2.x sockets, but the reverse is not true. Fortunately, most systems on the market today include a release 2.x socket. The current release is 2.1.
PCMCIA releases also govern Card and Socket Services, the software elements that determine how the cards themselves operate. Socket Services is a set of BIOS-level drivers that handle the physical operation of the sockets. PCMCIA is a bridge bus technology, which means that it can be run from any of a platform's I/O buses. In the PC world, this is most often the ISA bus, but PCI (Peripheral Component Inte
rconnect), SBus, and NuBus implementations also exist.
While the PCMCIA standard is platform independent, Socket Services is platform specific. It determines the number of sockets available, notifies the hardware drivers when cards are inserted or removed, makes cards accessible to system software drivers, and handles several other functions. But although the Socket Services software is platform-specific, very few vendors write the requisite code entirely on their own. Most rely on a third party to supply some of the software, as well as the other half of the PCMCIA software equation: Card Services.
Besides providing access to cards and sockets, Card Services coordinates system interrupts and memory activities; it also handles power management tasks. When correctly implemented, Card Services prevents direct interaction between a card's drivers and the system or system services. Card Services software is specific to the operating system of the host platform; in fact, it acts as an operating-syste
m extension that deals with a specific bus structure and the peripherals on that bus.
These peripherals are PC Cards. The functions and parameters of a PC Card are contained in data sets (called tuples) in the CIS (Card Information Structure). CIS data is stored in ROM on the PC Card itself, and Card Services queries this data structure for information on the inserted card. These details are passed to the host system, which uses them to interface correctly with the PC Card.
The Problems with PCMCIA
PCMCIA is the original plug-and-play interface. It was designed to provide resources that users could add to and remove from a system at will, ideally without rebooting or turning off the host. In reality, however, PCMCIA did not immediately live up to anyone's expectations (as is often the case with new technologies). Many factors contributed to the disappointing showing of the early implementations of PCMCIA, but the most widespread problem was the failure of card makers to adhere to any kind
of industry standard.
PCMCIA's first standard, release 1.0, was published in September 1990. In the first generation of products, Card and Socket Services did not exist. Instead, vendors supplied their own product-specific drivers, which in turn needed to be verified on each host platform. Platform vendors provided lists of tested, or certified, cards that they knew worked on their systems. However, each revision of the host, the operating system, or the card--no matter how small--stood a significant chance of causing compatibility problems.
The net result was that, for any given system, PC Cards worked neither as often as they should have nor in the way they should have. Changing cards, using two cards at once, and even changing applications frequently caused some sort of system failure. Users were confused by--and dissatisfied with--the technology.
The introduction in September 1991 of release 2.x, with its Card and Socket Services, provided a standard API and should have leveled the pl
aying field. But 2.x also brought I/O into the picture. Although this release opened the door for the products that have made PCMCIA the versatile tool it is today, it also opened a Pandora's box.
For example, an operating system does not see a hard disk or a memory card as being the same type of device as a fax modem. But the vendors of these peripherals, anxious to bring their products to market, often failed to take this into account and provided only the minimum software necessary for a device's operation. As a result, each card had to be tested in a system to ensure that it worked, and users generally had to either install a card before the system was booted or reboot after installation so that the system would recognize it.
To some extent, this problem persists. Today, most PC Cards work in most systems, generally without a reboot, but there are no guarantees. Most of today's operating systems are designed to work with the resources that are present when the operating system is booted; the
dynamic nature of PCMCIA runs against the grain.
The Way We Are
Many vendors of host platforms now offer some form of Card and Socket Services software. But although most host-system vendors supply them, vendors of PC Cards don't assume that Card and Socket Services will be present wherever their cards are installed. Instead, they generally supply some installation software that loads a simple driver or provide the services software themselves.
This leads to another potential problem. If users who already have Card and Socket Services on their systems use their PC Cards' installation software (which you'd expect them to do), that software may overwrite or otherwise corrupt the existing services software. When this happens, users may be left with only one card that works: the one they've just installed.
During the past six months or so, things have taken a distinct turn for the better. Because vendors are finally embracing the services software, many have upgraded their installation
software so that it doesn't overwrite the existing services software during setup. Users who have recently purchased systems, especially those produced in 1994, will find that most of their new cards work perfectly, both on their own and with other cards.
The Promise of Plug and Play
By the time this article sees print, the PCMCIA group should have released its newest version of the PC Card standard. One interesting development on the hardware side of this new standard is a technology called CardBus, which adds many significant features to the current standard but is completely backward-compatible with products that conform to the existing standard. Among CardBus's more significant features are a 32-bit data path, bus-mastering capability, support for multifunction PC cards, and support for low-voltage (i.e., 3.3-V or less) products.
One of nicest features of the CardBus interface is its performance. It supports multiplexed 32-bit data and addresses and runs at speeds as high as 20 MHz. T
his means that the CardBus interface is capable of peak data transfers in the 80-MBps range, approximately 20 times faster than what the current 16-bit interface can achieve. Of course, host systems that attach CardBus to a 16-bit bus structure will realize little or no performance increase, but many vendors plan to release systems with CardBus/PCMCIA bridged off the PCI bus.
CardBus is designed for use in a high-performance environment, and bus-mastering capability is a part of that picture. It enables the central processor to off-load control of the bus and move on to other processes. This provides a significant performance boost, especially in a multitasking environment.
In a CardBus implementation, adapters must support either PCMCIA release 2.x cards or CardBus cards. A detection algorithm uses the adapter to determine which type of card is installed, and this information is passed to Card Services. Card Services then uses Socket Services to determine whether the PC Card is supportable and
to decide which interface protocol to activate. To prevent damage to the card, Vcc is supplied to the card only after its needs are analyzed. If the card requires 3.3 V, for instance, and the system can supply only 5 V Vcc, the system software sends a message, via the user interface, that the card cannot be supported.
All CardBus PC Cards are designed for 3.3-V (or lower) operation; for a host system to be CardBus-compatible, it must be capable of supplying that voltage. CardBus also supports power management functions, such as clock-rate control and remote wake-up. In a CardBus implementation, a socket is turned off until a card is inserted into it.
CardBus also supports multifunction cards; each CardBus card can include as many as eight functions. This means that your LAN adapter might also act as your cellular fax modem, sound card, and digital-encryption processor (see the text box ``PCMCIA Players and Products'' on page 66).
One of the obstacles preventing PC Card and PCMCIA technolo
gy from even more widespread use is the lack of built-in support for it at the operating-system level. Only IBM includes Card Services with its operating systems, and only in OS/2 2.1 and PC-DOS 6.1 and higher. Because today's operating systems are so closely tied to their host platforms (especially in the portable market), to get native support for PCMCIA you need an IBM system.
But this situation will soon change. Microsoft's Chicago has been designed, from the ground up, as the world's first plug-and-play operating system. It will have a superset of all Card and Socket Services functions and will provide the features that PCMCIA needs to achieve its goals: dynamic resource management, dynamic driver loading and unloading, and dynamic event messaging.
Chicago will use Microsoft's Bus Enumerator to access the PCMCIA adapter and handle all the functions that Card Services currently handles (see the figure ``Chicago and PCMCIA''). Under this type of setup, the PCMCIA adapter is just another plug-
and-play device. Configuration of PC Cards and CardBus cards is handled by the Configuration Manager, which allocates resources as needed.
Because of its dynamic resource management, Chicago demands that each device have a unique identifier, which is created by the Bus Enumerator. In addition, each device's unique setup requirements are stored in an INF file, which Chicago's Device Installer accesses when an insertion triggers a request for identification.
After a device is identified and its INF file is created, the information is kept in the operating system's registry, and hot swapping becomes user-transparent. To permit configuration of any device, Chicago still requires the PC Card CIS to contain tuples; however, the coupling of mainstream operating systems, such as Windows, with a requirement for a standard tuple structure should help keep peripheral vendors within standards guidelines.
Chicago has a standard API for the development of plug-and-play DLVxDs (dynamically loadable virt
ual device drivers). All resource management for the device drivers is handled by the Configuration Manager. Actual configuration is handled by the Bus Enumerator through a Card Services interface. Because of this setup, the same device driver could conceivably manage its specific device over an EISA, ISA, PCI, or PCMCIA bus.
Microsoft seems to be treating PCMCIA as a priority. On its Redmond, Washington, site, the company maintains a building dedicated to helping developers port their device drivers and applications to Windows environments and operating systems. A major porting program for Windows' Chicago plug-and-play device drivers for PCMCIA is currently under way.
The Possible Dream
Although up to now the driving force behind PCMCIA has been the portable industry, that's changing. A few vendors have come out with desktop systems that have PCMCIA slots, and more are sure to follow. Most of us work in a relatively dynamic environment; our system needs frequently change, and we don't wa
nt to keep taking our hardware apart to accommodate these changes.
But the simple convenience of being able to add more memory or additional capabilities to a machine isn't the only reason users will want PCMCIA capability in their desktops. Another advantage is the possibility of sharing resources among systems. This is especially important for someone who works with both a portable and a desktop system. Such a user's chances of needing a sound card or a LAN adapter in both machines at the same time are slim. If the sound card and LAN adapter are on the same card as the user's fax modem, so much the better.
PCMCIA also offers a way to improve system security. The use of data-encryption cards and the practice of storing work on a removable disk both offer protection against disaster or dishonesty. And for road warriors returning to their desks, downloading information stored on a PCMCIA hard disk is faster than just about any other data transfer method.
Finally, PCMCIA isn't just about po
rtable and desktop PCs. The proliferation of PDAs (personal digital assistants) is opening up another market for these cards. And the time isn't too far off when we'll all be carrying our medical or credit information--or both--on a credit-card-size printed circuit board equipped with ICs.
But even if information-laden credit cards are a long way down the road, the future of PCMCIA looks bright. As standardization efforts improve and sales of new systems shift ever more toward the portable market, PCMCIA comes closer to reaching its original goals of providing seamless operation, incredible flexibility, and significant market penetration.
Figure: Chicago and PCMCIA
Microsoft's Chicago operating system has integrated support for PCMCIA via its Configuration Manager, which is responsible for all resource allocation and deallocation. This central control eliminates the possibility of conflict between devices.
John Bryan is a freelance technology writer and consultant ba
sed in San Jose, California. You can contact him on the Internet or BIX at
editors@bix.com
.
PCMCIA: Past, Present, and Promise
