Note: The following article originally appeared in the January 1995 issue of the Visual Automation NewsDisk, a hypertext publication for the factory automation industry.
Purchasing a PCMCIA card can be a disappointing experience: gone is the large green circuit board crisscrossed with hundreds of shiny foil traces and centipede-like black chips. In its place is a tiny, sturdy device about the size of a credit card, if a little bit thicker. You have to be careful you don’t accidentally throw the card out with the packing material for the manual. Did you really pay several hundred dollars for this tiny thing?! It just doesn’t seem right!
If you’re unlucky enough to be installing an unusual PCMCIA card in your system — a network card for a proprietary industrial network, for instance — you may have a few more disappointments ahead before you’re up and running.
First, it isn’t unusual for the manual of such a card to be thicker than the manual for the equivalent ISA bus card. If PCMCIA is supposed to be “plug-and-play” technology, then how come you need to read a book to get it running?
Second, there is probably a software disk included with your new card. That’s funny, the ISA card that does the same job doesn’t come with software. Upon reading the manual, you’ll probably find that the disk contains some drivers to get your new card up and running. If you’re already tight on conventional memory, the idea of loading more drivers just to use the card probably isn’t appealing. And what if you already have PCMCIA drivers installed on your system? Will they work with your new card?
In this article, I’ll try to answer some of these questions and give you an introduction to PCMCIA, the little card with the huge standard.
A Brief History Lesson
The acronym PCMCIA represents both the PC Card standard (which specifies both card hardware and system software requirements), and the organization responsible for developing it. Originally, the standard was designed exclusively for memory cards (Release 1.0). These cards were being used in small handheld and laptop systems in lieu of a floppy disk drive and were all 3.3 millimeters thick. These were Type I cards (the “Type” refers only to the physical thickness of a PC Card, nothing more).
Later releases of the PCMCIA standard (Release 2.0 and up) were expanded to include I/O cards, such as modems or network cards. Manufacturers were hard-pressed to make these more demanding cards fit in the 3.3 mm Type I form factor, however, so a Type II card was introduced with a thickness of 5 mm. A Type III card was also defined; these are 10.5 mm in height, and are often used for tiny hard disk drives. Some manufacturers have made still thicker cards for larger capacity drives; although this is often referred to as Type IV, this has not been officially adopted by PCMCIA. While the PCMCIA standard has grown significantly, it has done a pretty fair job of staying backward-compatible with earlier cards (a Type I card can be used in a Type II or III slot, for instance).
It is not uncommon to see advertisements for laptop computers which can accommodate “two Type II cards or one Type III.” This doesn’t usually imply that there are two models of the computer available with two different PCMCIA options; rather, it typically means that there are two Type II slots arranged vertically, so that a single Type III device could fit in the combined openings. Two smaller Type I cards would also fit; a larger slot can always accomodate a smaller card.
The newest version of the standard, code named “Berlin,” was unveiled on October 25th, 1994, and has been named PC Card 95 rather than Release 3. This naming change was perhaps intended to alleviate the common confusion between the PCMCIA release number and the card Type. Amongst the enhancements in this new standard are direct memory access (DMA), a faster (33 MHz) 32-bit interface called CardBus, and greatly improved power management. DMA and CardBus makes it practical to create new, high speed devices such as video adapters or even coprocessors; the power management will extend the battery life of your portable computer.
A key concept of PCMCIA is something called “plug-and-play” or “hot swapping.” The idea is that you should be able to pop out one PC Card and plug in another without having to power down the computer. When the new card is plugged in, a pre-loaded program called an enabler automatically identifies and configures the card. The enabler itself usually relies on a few other memory-resident programs to help it do this. The collection of programs you’ll need to pre-load to make your PC Cards work are often called drivers; DOS machines typically load these in the CONFIG.SYS and AUTOEXEC.BAT files.
PCMCIA Hardware and System Software
Each PCMCIA slot (or socket as it is called in the PCMCIA documentation) is connected to a device inside the computer called a PCMCIA adapter. Each adapter in the computer can control one or more slots, and a computer may have more than one adapter. For example, a computer with four PCMCIA slots might have two adapters, each responsible for controlling two slots.
Most IBM PC compatible computers have serial and parallel ports; the hardware for these devices is similar on all such machines. Programs written for these machines may talk directly to the serial or parallel port hardware and get expected results, since the hardware is compatible between different machines. This is not the case with PCMCIA adapters; there are many different adapters on the market, and they are not compatible with one another. Software written for one adapter will not work with another.
To hide the differences between these adapters, a memory resident driver called Socket Services must be present. Once loaded, Socket Services talks directly to the PCMCIA adapter hardware, and other programs talk to Socket Services to control a PC Card in one of that adapter’s slots. This gives higher-level programs a single, consistent way of dealing with PC Cards, because the interface to Socket Services is defined in the PCMCIA standard. Socket Services is usually a small program which only takes a few thousand bytes of memory. Some computers may even put the Socket Services driver in the BIOS; you’ll need to check with your computer’s documentation to see if you need to load a Socket Services driver.
It is important to remember two things about Socket Services. First, since it must interface directly to the adapter hardware, it is written specifically for a particular adapter. In order to work, you must have the correct Socket Services driver for your computer system; if you don’t have a PCMCIA Socket Services driver, you should contact the vendor of your computer or a PCMCIA system software vendor to see what is available. Second, it is possible to load more than one Socket Services driver if your computer has multiple PCMCIA adapters of different types (such a configuration is relatively rare, however).
Before describing the next software layer, let’s take a moment to consider how PC Cards might be used in a typical computer system. Suppose you have several PC Cards, but only two PCMCIA sockets. Each of these cards might have different resource requirements, such as I/O addresses, interrupt request (IRQ) lines, and memory ranges. How would you configure each card so that no matter which two cards were plugged into the system, there would never be a resource conflict (i.e., two cards trying to use the same interrupt)? If you have many cards, setting each one up so a conflict would never occur could be very difficult.
To solve this problem, the PCMCIA standard describes a software layer called Card Services, which acts as sort of a librarian of system resources. When Card Services is started, system resources (I/O ranges, IRQs, and memory ranges) are given to it; the resources it is given are usually configurable by running a program provided with the PCMCIA system software. The program that does the resource allocation may be a stand-alone program, or it may be built into the generic enabler (which I’ll cover shortly). The resources used may be listed in a file, or might be specified on the command line of the enabler or Card Services; it all depends on the vendor of your system software.
As each PC Card is inserted in the system, Card Services hands out these resources as needed to configure the card; when cards are removed, these resources are returned to Card Services to reuse. This allows any combination of cards to work without conflict, as long as you’ve given Card Services the resources it needs to accomodate any two of them (assuming you have two PCMCIA slots).
There is still some potential for problems which you should be aware of:
- While Card Services can prevent PC Cards from interfering with each other, the resources you allocate to Card Services must not conflict with any other hardware or software in your system. For example, if you have a COM1 port in your system which uses IRQ 4, you will not want to give IRQ 4 to Card Services for its use. Similarly, if you allow Card Services to use a memory range of D000-D7FF for memory mapped PC Cards, be sure you exclude that memory range from any memory managers in your CONFIG.SYS file, and add the line EmmExclude=D000-D7FF to the [386Enh] section of your Windows SYSTEM.INI file.
- Card Services requires at least 4K of memory for its own use. When allocating a memory range for Card Services to use, you should make sure you take this into account.
- Some implementations of Card Services can take 40-50K of conventional memory. If you run large DOS programs, this can be a problem. Loading Card Services high using a memory manager such as EMM386 or QEMM can sometimes help this situation.
- All Socket Services drivers must be loaded before Card Services, because Card Services uses Socket Services to access the adapter hardware.
- Although a system may have many Socket Services drivers, only one Card Services driver can be loaded in a single computer system.
Although PCMCIA does not define any software layers above Socket Services and Card Services, there are usually one or more memory resident programs loaded which actually configure the PC Cards as they are inserted. These drivers are called enablers.
Socket Services provides a consistent interface to the hardware, and Card Services provides resource management, but for all this software your PC Card isn’t even configured yet! Before I describe the software that handles this, it would be a good idea to explain just what I mean by configuration.
There is often more than one step to configuring an I/O card. For example, consider an internal modem card for the ISA bus. After you take the modem out of the box, the first thing you need to do is set jumpers or DIP switches on the card; these set the COM port address the card will occupy (COM1 or COM2, for instance). This is the first level of configuration. The second level of configuration is usually performed by application software such as a communications program for the modem. Baud rate, parity, stop bits, protocol, and so on are configured at this second level, after which the modem is ready to use.
Because of their small size, PCMCIA cards do not have DIP switches or jumpers; instead, the first level of configuration is done by a special piece of software called an enabler. The role of the enabler is to place the card in the system at a particular I/O address, memory address, and/or IRQ. The second level of configuration is still the job of the application software which will use the card.
Perhaps the most common type of enabler is called a generic enabler (some vendors also refer to these as “super client drivers”). Generic enablers are capable of configuring a wide range of the most common card types (such as modems and network adapters). The generic enabler is usually provided with PCMCIA system software, and requires Socket Services and Card Services to be loaded before it can run.
Since it is designed to handle a broad range of cards, it is often a bit of a memory pig; it is not uncommon to see a generic enabler eat up another 40-50K of conventional memory. Along with Socket Services and Card Services, the total memory requirements to run your PCMCIA card are already up to nearly 100K — just to do the equivalent of setting the DIP switches and jumpers on an ISA card! Of course, PCMCIA is far more ambitious than the ISA bus, and has the potential to greatly simplify configuration and use of PC Cards. The technology is still young, and as the PCMCIA organization is fond of pointing out, things will only get better with time.
The memory problem is currently most painful for large DOS applications. If you don’t need to run more than one type of PC Card however — in an industrial terminal application, for instance — you might be able to do away with the generic enabler altogether and load a small, lean specific enabler.
A specific enabler is a program to configure a single type of PC Card, and may be provided by the vendor of the PC Card or by a third party software company. Specific enablers may be much smaller than generic enablers, since they don’t have to cope with a large number of different cards. There are several reasons you might want to load a specific enabler in your system:
- If the memory requirements of a generic enabler are unsatisfactory, and you only use a card type supported by the specific enabler, you can remove the generic enabler from your configuration. This can save up to 40K or so of conventional memory.
- You might have a generic enabler which does not recognize card XYZ. In this case, you’ll load the specific enabler along with the generic enabler. The specific enabler can take care of configuring card XYZ, while the generic enabler can configure the other cards you commonly use.
There is the potential for some problems when both the generic enabler and a specific enabler are loaded, and both recognize and can configure a particular type of I/O card. Because of an oversight in the PCMCIA specification, the first enabler loaded will configure the card if it is installed when the machine is booted; if the card is inserted after the machine is booted, however, the last enabler loaded will configure the card. This can create problems if the two enablers have different ideas about how the card should be configured, or if the application software depends on one enabler or the other to configure the card.
Here are some rules of thumb to determine which enablers you should load, if you have both generic and specific enablers:
- If you have the need for a generic enabler to configure your modem or another device which doesn’t have a specific enabler, load it.
- If the only PCMCIA card you use has a specific enabler, load the specific enabler instead of the generic.
- If you have both cards which are configured by the generic enabler, and card XYZ which has a specific enabler, first see if the generic enabler can handle card XYZ. If the generic enabler can handle it, don’t load the specific enabler; if not, load both.
Yet a third type of enabler is called a point enabler. This is similar to a specific enabler in that it is designed to configure a single type of PC Card. Unlike generic enablers or specific enablers, point enablers do not require Socket Services or Card Services to be loaded. Instead, they talk directly to the PCMCIA adapter hardware. This has both advantages and drawbacks:
- Since Socket Services and Card Services are not necessary, a point enabler can take up far less conventional memory.
- In order to talk directly to the adapter hardware, a point enabler must be designed to work with that hardware. The point enabler may not work on all computer systems.
- A point enabler will bypass Socket Services and Card Services if they are loaded. This can create serious problems if you want to use other cards at the same time as the one the point enabler configures.
Bypassing Socket Services and Card Services is not usually a good idea. In general, you should use a point enabler as a last resort, and only if you don’t use any other PC Cards.
Once the PC Card has been configured by an enabler, it may be used by your programs. While the enabler works with the other software layers to “map” the card into your system at a particular I/O address, memory address, and interrupt, the application usually has little to do with these other layers. Most applications will simply access the PC Card through the resources it has been given.
A modem card, for instance, is configured by the enabler to take up several I/O addresses and an IRQ, the same as any other COM port in your computer. To your terminal software, this new COM port is no different than any other, and can be used even if the terminal software predates PCMCIA.
Some application software which uses special-purpose cards may need to go a little further to keep PC Card configuration simple. This “PCMCIA-aware” software may communicate with the enabler, Card Services, or both, and allow the user to simply select a PC Card by socket. This makes configuration much simpler than if you needed to manually specify which memory address, I/O address, or IRQ your PC Card was using.
ATA is a sort of nested acronym for AT Attachment (the “AT” refers to the IBM AT computer), and is an interface which is electrically identical to a common hard disk interface. ATA mass storage devices, whether mechanical hard disks or solid-state memory cards which appear as disk drives, require another driver to be loaded in the system. ATA drivers must be loaded after Socket Services and Card Services.
Some systems are able to boot off an ATA PCMCIA device. This is possible if the manufacturer of the computer includes an ATA device driver in the system’s BIOS ROM. After the system is booted, this ROM based driver can relinquish control of the slot to allow another ATA driver to be installed on top of Card Services; this allows other devices to be swapped in and out of the slot.
If you are going to use an ATA storage device, you’ll need to load this driver. If you have no such card, however, there is no reason to load it.
Flash Filing Systems
FFS, the obligatory acronym for Flash Filing Systems, refers to drivers which handle flash memory cards. Flash memory cards also appear to the system as disk drives, but have some peculiarities which are handled by an FFS driver. For example, flash memory has a limited write cycle, often on the order of 10,000 writes or so; after that, the card wears out. Erasing and rewriting information on these cards is also a relatively slow procedure. The FFS driver performs wear-balancing to avoid wearing out the media prematurely, and works to hide performance delays in writing to the card.
It is interesting to note that the flash memory used on these cards is often the same as that used on solid-state ATA devices. The difference is that an ATA solid-state disk has intelligence on the card to deal with the characteristics of flash memory, while FFS flash memory cards require the FFS driver to perform this service. Not all Flash Filing Systems are compatible with one another, making an ATA device a better choice if you’ll be using a memory card to transfer data between different systems. ATA solid-state disk cards are generally more expensive, however.
Like ATA, the FFS is a driver which you should only load if you have a card that requires it. An FFS may require another memory card driver to be loaded first, such as the one for SRAM cards described below.
Other Memory Card Drivers
Even regular static RAM (SRAM) cards require a special driver. Unlike flash memory, SRAM requires a small battery to maintain it’s contents, although the battery life is typically measured in months or years. SRAM also does not wear out, and is much faster than flash memory. The inevitable tradeoff is that SRAM is more expensive than flash RAM.
Are We Having Fun Yet?
Is it really necessary to know all of this to get PCMCIA running? Yes and no…
Many computer vendors ship their PCMCIA-capable machines pre-loaded with the drivers needed to handle most cards. Often a common card can be plugged into an off-the-shelf machine and work without any hassles. This is terrific when it works, and seems to suggest that PCMCIA might be on the right track after all.
The knowledge of how it all fits together becomes valuable, though, when adding an unusual card to your system, modifying your system for optimal memory use, or troubleshooting PCMCIA-related problems.
With each passing day, the situation improves: system software vendors make their programs and documentation easier to understand, card vendors improve compatibility, and application software developers add PCMCIA-awareness to their applications. Microsoft Windows 95 will have PCMCIA support built in, using technology from SystemSoft. PCMCIA itself is very aware of compatibility problems; Tony Wutka, the former chairman of PCMCIA, wrote in the PCMCIA Update newsletter “The number one strategic objective…is to make compatibility a non-issue to the end-user.”
The future of PCMCIA looks bright. Until the technology matures, however, harnessing the power of these tiny cards might take more than a little patience.