PC Card Developer's Q & A

Answer:
Processors that cannot generate I/O cycles to access PC Cards use interface logic that converts memory cycles to I/O cycles. Generally the processor memory map is divided into areas that when accessed either generates PC Card memory accesses or I/O accesses.

Question:
I am designing a CardBus board with 80 Mbytes/sec input data, small logic and an interface to CardBus. Are there any general purpose CardBus interface chips I could use?

Answer:
I'm not aware of any general purpose CardBus chips. You could start off with a PCI implementation from an FPGA vendor and add the CardBus additons. You can find CardBus information in PCMCIA's PC Card Standard.

Question:
We have the PC Card Standard Release 7.0. I have not been able to ascertain the conditions under which a PC Card (PC Card only -- not CardBus) may be inserted and removed. Most who are familiar with PCMCIA in general believe that PC Cards are "hot pluggable" -- they may be inserted into a system in which power is applied. I cannot find a verification or description that this is acceptable. Nor can I find specifications of how this is accomplished to guarantee that a PC Card is not damaged by hot plugging. Is this specified in Release 7?

Answer:
PC Cards are "hot swappable" meaning they can be swapped (inserted and removed) when the system is powered on and running. The PC Card Specification states that the host system must detect that a card has been removed and power-down the socket (referred to as a "cold" socket). When a card is inserted into the socket, its present is detected and the voltage sense pins (VS1# and VS2#) examined (the voltage sense pins determine the power-on voltage of the card). If the card's power-on voltage is supported, the socket is powered-up and the interface enabled. Host software would then read the card's Card Information Structure (CIS) to determine the type of card and what device drivers need to be loaded to support it.
The key to proper operation is the PC Card is never plugged into a socket already powered or one when where the interface pins (data and address lines) at active. Only after proper detection is the socket power and the interface enabled.

Question:
I am developing a device driver for our proprietary 16bit PC Card, which sits on a PCI board with PCMCIA socket. The PCI board is designed without ISA interrupt. I understand from MSDN that Windows requires 16bit PCCard to use ISA interrupt and Cardbus to use PCI interrupt. When using Windows default driver for the PCMCIA bridge controller, Windows Card and Socket Services did not return my PC Card driver with allocated configuration resources. I suppose it is waiting for an interrupt from the ISA slot. Why does Windows have this requirement of using an ISA interrupt for 16bit cards? What can I do to inform Card Services to allocate my PC Card with PCI interrupt from the PCI board, without modifying Windows Card and Socket Services? I can write to Ricoh BridgeControl Register to route the interrupt to PCI INTA# pin in my PC Card driver.

Answer:
There are a number of reasons why Windows does not return the resources requested. I assume you are writing a VxD device driver and Windows is failing to grant your resources. The handling of ISA or PCI-type interrupts in the device driver are generally transparent to device driver. You will need to troubleshoot the reason for Windows not granting the resources by trying different configurations (or multiple configurations) that don't include a request for IRQ. A common cause of failing to grant a IRQ under Windows is a lack of ISA interrupt numbers available.

Question:
I have a PCMCIA to SCSI adapter connected to a SCSI removable media drive. The computer is running Windows 98. I am trying to use Norton Ghost to copy my hard drive to the removable media drive, however, Ghost is a DOS utility. I have the DOS driver for the removable media drive, but of course I can't get there without the computer first recognizing PCMCIA cards. Can you help, or should I give up?

Answer:
The DOS utility may be expecting to see Card and Socket Services -- a software stack that was around before Windows 95/98. Windows 95/98 use a "protected mode" interface that cannot be seen by the DOS program. There are two possible solutions:

1) Try installing the SRAM/Flash PC Card device drivers in Windows 98 (go to the Windows Help program and search for SRAM). In Windows 95 this created a DOS-mode interface to the Card Services interface. I'm not sure if Windows 98 exposes this interface too, but it's worth a try and may allow your DOS utility to function.

2) The other solution is to install a 3rd-party software for handling PC Cards. One solution is a PC Card utility from SystemSoft Corp. This program (and others) handle more cards/device drivers than Windows and may be useful.

Question:
1) I am using PCMCIA ATA compatible hard disks in our system. When I decoded the CIS, System Initialization Byte of Function Identification Tuple (CISTPL_FUNCE-0x22) is different for different hard disks. Sometimes it is 0x01 and some times it is 0x00. Can you tell me what it means and what care needs to be taken if it is 01 or 00?

2) Although I am successfully working with hard disks between 32MB and 360MB, higher capacity disks like 540MB and 1GB PCMCIA hard disks are not working at all. I am getting status failures, Time outs, hardware failures, etc. I am using DOS format and pHILE component of pSOS OS for handling the file system. Can you please throw some light on this?

Answer:
The Initialization byte of the CISTPL_FUNCE tuple indicates if the card needs to be initialized during POST (Power On Self Test). A value of '01' means it should be initialized and '00' means it's not required. Since PC Cards were designed to act like built-in resources of the host computer, some devices would need to be initialized at power-on time (generally by the system BIOS) in order to be used during the boot process. ATA PC Cards would fit this category but software generally ignores the contents of this initialization byte.
The other problem you are having with ATA cards could be caused by a number of items (bad PC Cards; host PC Card hardware problems; host software drivers problems, etc.). Most likely the cause is problems with the host PC Card controller hardware.

Question:
I've been tasked to build a circuit board to interface with a simulated weapon. This weapon has a control unit with a Type I SRAM PCMCIA card installed. It writes events to the card when the weapon has fired, or been hit by another player. My question is concerning the BVD1 and BVD2 status lines. Other than them being some sort of battery detect, I'm not sure how they're used. I'm seeing a +5V level on them some times, and other times a +4V level. I know the single battery in the PC Card is a +3V lithium. Why are there 2 battery detects?
Why are they at a +5V level? I know that the PCMCIA Vcc is a +5V level. Is the battery simply used as a "keep-alive" voltage for the SRAM when the PCMCIA Vcc is not present? The reason I'm asking this is because I'm seeing considerable noise on the BVD lines. I believe the weapon runs a self-test which includes checking the card's battery detect. I see an error stating "low card battery" due to the negative noise spikes on the BVD lines. Is is possible to get some sort of a block diagram or more detailed for the BVD circuits?

Answer:
The battery on the SRAM cards is used to the preserve the contents of the memory while the card is out the PC Card socket. The BVD1 and BVD2 are status pins used to indicate the state of the internal battery (Good, weak, battery dead). These signals are generally logic levels that only have to meet PC Card logic levels requirements. Any noise that you are seeing on these signals may be caused by the host system inducing noise.

Question:
We are developing a 3.3v 16-bit PC Card and we have some problems with the voltage applied by laptops. To configure the card to operate only on 3.3v, we use a low voltage connector, ground the VS1 pin and leave VS2 open. After card insertion, the host applies the right voltage but after reading the CIS and installing the card, it changes it: One laptop applies 5v and another cuts the power. We have tried with the following different configurations in the CIS (CISTPL_CFTABLE_ENTRY):

- without Power-description structure
- with Vcc Power-description structure
- with only Nom V 3,3v :01h,b5h,15h
- with only Max(3,5v) & Min V(3v)
- with Nom V,Max& Min
and we get the same result.

We use a Plug-and-Play driver which runs correctly (used with a similar 16-bit PC Card 5v). We know that the CIS is also being read since card name is right and the laptop gives resources required for the PC Card. We don't understand why.

Answer:
You need to include the CISTPL_DEVICE_OC tuple and set the bit showing the card is a 3.3v device. Without this tuple the host powers up at 3.3v but thinks the card operates at 5v.

Question:
I have a few questions that cannot be cleared up with the PC Card Standard Release 7.

1) I have noticed that in PC Card Standard Release 7 under the "Electrical Specification" section 4.2 that it says that the CE[2::1]# signal is an OUTPUT from the 16-bit PC Card. However looking at Table 4-2 it says that it is an INPUT. Which is correct? (for the following questions, I shall assume that CE[2::1]# are actually inputs to the 16-bit PC-Card)
2) Assuming CE[2::1]# is an input to the 16-bit PC-Card and that the card is in Memory and I/O mode, then if the PCMCIA master is a word device, does it matter if both Chip Enables to the PC-Card become asserted even if IOIS16# is negated?
3) If during an I/O access, if IOIS16# remains negated and the master performs a word read or write cycle, does CE2# need to be gated by IOIS16# or can it be asserted for the whole of the cycle but it is ignored by the 16-bit PC Card?
4) If during an I/O access, if IOIS16# remains negated and the master performs a word read or write cycle, do we need to execute two 8 bit cycles where IORD# or IOWR# are strobed low while the CE[2::1]# remains asserted and the address bit A0 is 0 in the first IORD/IOWR strobe and 1 in the second IORD/IOWR strobe with the 8 bit data on the lower 8 bits of the 16 bit data bus?
5) Unfortunately, there are no timing diagrams in the spec to illustrate what happens if the I/O device indicates that it is 8 bits wide when a 16 bit cycle is executed.

Answer:
1) Section 4.2 does not state that CE[2::]# are output signals -- they are inputs as shown in Table 2-1 and 2-2. You may have been confused by the wording in Section 4.2: "These signals that are outputs from the card ..."
2) Some I/O cards have a mix of 8 and 16-bit registers. IOIS16# is used to indicate which registers are 16 bits to the host system (our term for the PCMCIA master). If you do a 16-bit access (both Chip Enables active) to a I/O register that is only 8-bits, you will only get 8-bits of valid data.
3) Generally the card will ignore CE2# if the addressed register is only 8 bits.
4) Yes, you are correct. The ability to break up a word cycle into two 8-bit cycles is mainly a Intel X86 PC access method. Most non-PC systems (i.e., Windows CE) processors don't use IOIS16# signal and write their software so they know what I/O registers (port addresses) are 8 bit and what are 16 bits. If you know the I/O device that you are programming and have the ability to perform 8 and 16-bit I/O accesses, you don't need to use the IOIS16# signal from PC Card.
5) This functionally is not defined by the PC Card Standard. It is something that was defined into the Intel PCIC (82365) controller chip that was defined for the PC.

Question:
Is there any way to redirect a serial call from a Program to PC Card Socket hardware? My application is for a Smart Card reader, the software only supports serial readers and I have a PC Card Reader.

Answer:
There are a number of ways to redirect serial calls from a program, but the answer depends on the OS you are using. You will have the best results if you are using a Serial Port PC Card that uses a COM port supported by your program. If you have another type of PC Card hardware, programming may be required.

Question:
We are the manufacturer of mobile PC. We have an IDE hard drive and PC Card slot. Some of our custommers would like to have the choice of booting from IDE or the PCMCIA hard drive. What exists (rom extension...?) and how can it be done?

Answer:
Booting from a PC Card can be done but requires code in the ROM BIOS to support this feature. I would check with the manufacturer of your BIOS program to see what support they can offer. Adding this feature yourself may be possible, but requires extensive programming and hardware knowledge.

Question:
We are very interested in knowing how to enable a PC Card socket in a Windows95 based Laptop to read SRAM cards as a floppy disk (FAT12 format).

Answer:
To enable SRAM cards under Windows 95 you need to load the memory device drivers. Use the Windows Help program (from the Start menu) and search for SRAM. This will provide the steps to enable SRAM drivers.

Question:
I am specifying a PC Card slot capability for an embedded system. The primary intent is to use the PC Card to store files from our system and/or a personal computer and be able to access the files on either system.
Non-ATA file system drivers are readily available for embedded systems but this would mean using only PC Cards with linear flash. Would such a card be readable by typical personal computers?
Is this an appropriate choice or should I instead specify ATA card capabilities for our embedded system?

Answer:
Linear flash PC Cards for file storage are fine as long as you have drivers available for your embedded system. If you need to read/write these files on a PC system, you need to make sure drivers are available for PC Card/file system you use (you cannot rely on the fact that Windows will support the file system you chose, unless it is an ATA card with the FAT file system).
If you need have full access to your PC Cards under Windows or in PC systems, your best bet is to use ATA-compatible PC Cards and implent the FAT file system in your embedded system. Embedded drivers are available to support these cards and file system.

Question:
What is the logical throughput of a PC Card?

Answer:
The theoretical maximums I quote are: CardBus (32 bit burst mode) -- Byte mode: 33 Mbytes/sec -- Word mode: 66 Mbytes/sec -- DWord mode: 132 Mbytes/sec 16-bit Memory Transfers (100 ns Minimum cycle) -- Byte mode: 10 Mbytes/sec -- Word mode: 20 Mbytes/sec 16-bit I/O Transfers (255 ns Minimum cycle) -- Byte mode: 3.92 Mbytes/sec -- Word mode: 7.84 Mbytes/sec

Question:
I'm debugging software on laptops. I need to generate some sort of non-maskable interrupt to break into the debugger when interrupts are disabled. Is there a way to do that using the PCMCIA-bus (like it could be done with the old ISA bus)?

Answer:
PC Card (PCMCIA) interface does not have any NMI interrupt signals. It has only one interrupt signal that must be enabled (in software) before interrupts are generated.

Question:
I have just designed a PC Card for I/O operations. The CIS is correctly parsed by DTPL.EXE. The PC Card requests 12V on Vpp1 pin for A/D Conversions. When I test the card under MS-DOS with personal software, 5V on Vcc and 12V on Vpp1 are present and the card operates correctly. (Note: VS1 and VS2 are open).
However, under Windows NT, the resources of the PC Card are correctly placed (following the instructions of the DDK for PCMCIA), but only 5V occurs on the Vpp1 pin. The power descriptor in the CIS specifies 12V on Vpp1, but the system under Windows NT ignores this configuration. What can I do to change the Windows NT behavior? Is it possible to activate 12V on Vpp1 with this driver?

Answer:
Most PC Card controllers require Vpp1 and Vpp2 to be the same voltage. Vpp1/Vpp2 = 5 volts is the power-on default voltage. I would suggest changing the CIS to make both Vpp1 and Vpp2 = 12 volts.

Question:
I'm developing a CardBus interface in a FPGA. When the card is inserted to the socket, the power is supplied and the host wants to read the CIS. The FPGA is loading it's code and can't answer the host until it's done.
What happens if it can't read th CIS right away? Can the CSTSCHG pin be used to allert the host to start reading the CIS when it's done loading the code?

Answer:
The CIS is read using the PCI interface protocol. If your card does not have the CIS ready to read, you would need to hold off the PCI Configuration process. In order to use the CSTSCHG signal to told the host to start reading the CIS, it must be supported in the host device driver.

Question:
From the Metaformat Specification: CISTPL_CFTABLE_ENTRY: 16-bit PC Card Configuration Table Entry Tuple; TPCE_FS: Feature Selection Byte; Mem Space field value of 1: "Single 2-byte length specified". What is the correct byte order of the "Single 2-byte length"? LSB first, or MSB first?

Answer:
Little Endian order (LSB followed by MSB)

Question:
Does the PCMCIA implementation in Windows95 support the vendor specific function identifier in CISTPL_FUNCID? I have designed a CIS including all of the required tuples as stated by Microsoft in the DDK, but the PCMCIA enumerator refuses to handle the card. A low-pitched beep is heard upon insertion of the card and no further processing takes place. The CIS has been verified to be correct and a hardware ID can be generated with Microsoft's DTPL.EXE utility. The CIS has been successfully tested on the WindowsNT (with some registry overrides) and the Macintosh platforms.
I have tried to access the card through the Windows95 Card Services interface but I have experienced some trouble setting up the required memory window (the card communicates with the host through a common memory window). Occasionally, the window requested does not appear at the address returned by Card Services.This behavior seems to be more frequent when using a CardBus controller. Any hints?

Answer:
There are many reasons Windows 95/98 will not configure a PC Card. DTPL can help identify problems in the CIS but will not tell you if the tuples and their contents will allow the card to be configured under Windows.
As far as the Vendor Specific function, Windows uses this tuple to determine the type of PC Card. Vendor Specific means that you need a device driver to load and communicate with the Configuration Manager. Windows 95/98 has some implementation issues when dealing with memory-mapped I/O devices (i.e. non-storeage cards).

Question:
1) I am designing a system with a socket for ATA PC Card memory. Based on the PC Card ATA Specification, it appears that I already know which I/O ports are 16-bit and which are 8-bit for any ATA PC Card: all ports are 8-bit, except for the data read and write registers, which are ALWAYS 8 or 16 bit, at the host's option. Therefore, I see no reason to look at IOIS16. Can I just leave it unconnected?
2) The Metaformat Specification seems to give a lot of good info on things that cards CAN include, but I haven't found much info on what certain cards MUST include. As a result, I'm left wondering: are there certain tuples that can be read to figure out for certain whether the card I'm looking at is an ATA card, a linear flash card, or neither? I've found some tuples which seem to be common (for example, it seems that all ATA cards ­ and only ATA cards ­ include a CISTPL_FUNCE with TPLFE_TYPE and TPLFE_DATA= 01, while linear flash cards must include a CISTPL_DEVICEGEO, while ATA cards never will). However, I'm not sure if this distinction in tuples is required by the Standard in all storage PC Cards. If not, what CIS information can I look at to be certain whether a card is ATA, linear flash, or neither?

Answer:
1) IOIS16 is an optional signal. For ATA cards you will not have problems if you use 8-bit read/writes for the Task File registers, and 16-bit read/writes for the Data register.
2) ATA cards will contain Function ID and Function ID Extention tuples indicating an ATA disk drive function. Linear Flash cards will not. Linear Flash cards should also indicate that their memory is Flash type in the Device ID tuple.

Question:
Is it possible to control the CCD1#, CCD2#, CVS1, and CVS2 pins of the card so that it is initially detected as a 16 bit, 3.3 volt PC card and later is detected as a (3.3volt) CardBus card without losing power to the card during the change? I would like to do this so that the CardBus interface FPGA could be configured by the host CPU using the 16 bit interface. This would allow updates to the FPGA to be made in software rather than having to replace a chip.

Answer:
It is possible to do what you want, but you would have to use jumpers/switches for CCD1/CCD2 and CVS1/CVS2 signals. These signals must be left open or connected directly to GND. Using logic or resistors to control the state of these pins may result in false detection by 16-bit and CardBus host adapters.

Question:
I am designing a socket that will switch either 5V or 3.3V to a card based on VS1/2 levels. Section 4.4.16.1 "Socket Vcc for CIS Read" of the Electrical Specification states that VS1 must be re-sensed after power-on, and power must be changed if VS1 is no longer grounded.
1) Does this only apply to sockets that want to be compatible with cards that have a RFSH pin instead of VS1?
2) If the applied voltage must be changed (after re-sensing VS1), is it necessary to first discharge Vcc to Voff for 100 ms, or can Vcc simply be changed directly from the old Vcc to the new?

Answer:
The current PC Card Standard does not require "re-sensing" of the VS1 signal after power on. This was part of the Feb 1995 Standard, but was quickly removed. A few companies thought that it was needed because we changed the direction of the RFSH pin from an output to an input. Some companies were incorrectly using RFSH pin a a manufacturing test pin.
As stated in the Standard, if Vcc voltage must be changed, the voltage must be reduced to 0 volts before switching to the new voltage. VS1# only needs to be sensed after the card is first inserted (before applying power).

Question:
I am designing a dual RS232 port PC Card and I have to setup the 2 port configurations and the clock speed. In the Standard it talks about common and secondary CIS's. The common CIS for common functions and secondary CIS for each FCR function. Does this means 3 CISıs are needed with 3 separate CORs each with separate FCRs?
I am also confused by the configuration of the ports. The Standard states that the address can be specified and the address decoding done the same as ISA. But to be truly PnP the host must be able to setup the uart register anywhere there is space (similar to PCI). Can you tell me if this is possible and how the tuple info is set to do this?

Answer:
Multiple function cards generally contain one CIS. There are multiple CIS chains. The main CIS chain describes the common portion of the card and contains the Multiple Function tuple (LONGLINK_MFC). There is an additional CIS chain for each function on the card. Multiple functions require a separate set of FCRs for each function. Each FCR contains a COR along with a Base and Limit register that is used to indepenently set the I/O address and range for that function.
As mentioned above, the FCR's Base and Limit register is used to set the I/O starting address and I/O range for each function. This allows each function (i.e., RS-232 uarts) to be placed anywhere in the host's I/O space. The Configuration Table Entry tuple specifies the valid configurations (i.e., I/O addresses) allowed for each function. The device driver/configuration manager software must set the function's Base and Limit registers to the proper address. The Metaformat Specification describes the tuples needed for Multiple Function Cards (section 2.3.6).

Question:
We are designing an ASIC for the PC Card interface. Referring to the PC Card Standard, March 1997, page 34 there does not appear to be a data hold time requirement from OE# lo to hi transition to D[15::00] valid for Attribute or Common memory as there is for DMA Write (I/O Read). Typically, data is strobed into a processor on the rising edge of the read signal and typically that is 0 nS. Using address hold from OE# hi spec of 20 nS [(th(A)] and data hold from address of 0 nS [(tv(A)] I get 20 nS. We are using 0nS in our design and everything is perfectly functional. Please clarify the requirements for me.

Answer:
The Data Hold requirement for OE# is not directly specified. As you noted the Address Hold time (thA) is specified as 20 nS. The footnote for this timing indicates that it's for PC Cards that support the WAIT# signal. It implies that if WAIT# is not used, the time is not specified (and you may assume 0 nS).
Assuming the above, we can figure the Data Hold times. Data Hold from address change (tvA) is 0 nS. This means that Data Hold from OE# is 20 nS if WAIT# is asserted and 0 nS if WAIT# is not asserted.

Question:
I'm developing a PC Card with 2KB of 8 Bit Dual Port Memory. The ExCA Specification defines 8 Bit Common Memory and the PCMCIA Host Adapter also supports 8 Bit. But i did not find any way to define 8 bit common memory within the CIS. Is that really so? Under Windows 95 I can specify a CIS override using the.INF file for the PC Card. The value of "02" for the memory attribute Byte specifies attribute memory, the value "08" specifies 16-bit common memory, the undocumented value of "04" specifies 8 bit common memory. But I think it is dangerous to use undocumented features.

Answer:
By definition all PC Card 16 cards must support 8 and 16 bit accesses. Since the card is required to support 16-bit accesses, there is no method to identify it as an 8-bit-only PC Card. PC Card should support 8-bit accesses in order to function with 8-b host systems.
Using the undocumented CIS override code under Windows 95 works, but it may not work in the future. I don't believe Microsoft intended to support Memory Cards under windows.

Question:
I am currently designing a system which includes two pcmcia sockets compatible with Release 2.1. Having studing a few PC Card controllers I notice that they mention two voltage sense pins, 43 and 57. These are mapped to RFSH and RFU according to my copy of the specification, but I can find no mention of this functionality.
I imagine that they have been added to make the design of pc-card systems easier since 3.3v only systems would not need 5v supply to interrogate the card. Please could you supply me details of exactly how these pins are used or where I could get this information from.

Answer:
Pins 43 and 57 are now called VS1# and VS2#. They are used to indicate the power-up voltage of the PC Card needed to read the card's CIS (tuples). VS1# is grounded on PC Cards if they support 3.3 Volts. VS2# is reserved for a yet undefined voltage (x.x Volts).
These pins were defined in the February 1995 PC Card Standard (the first Standard after Release 2.1).

Question:
We manufacture a custom pcmcia card (16-bit) which needs 5V on Vcc to operate. The platform is Windows 95, and the card is plug and play. We request 5V in the tuples (with a 0x55 value specified for nominal Vcc voltage). We also have a CIS override which the win95 driver invokes, which specifies 0x32 =3D 50 for the Vcc.
Under all the desktop PC's in the lab, and under most of the laptops, the card works fine. However, we have found that in newer laptops (e.g. Toshiba Tecra 740CTD and other no-names), the card only gets 3.5V coming over the vcc lines. What might be causing this?

Additional info:
1] When the card is inserted, of course, these newer laptops do send over 5V. It is only when the win95 driver receives its CONFIG_START message, and returns CR_SUCCESS, that the voltage then drops. If my driver returns CR_FAILURE, then the voltage stays at 5V. Does this indicate it is problem with the override?
2] My card also requests 12V on each of the Vpp lines, and does receive it, even on these new laptops.

Answer:
It sounds like the problem is with the override. If the card powers up at 5 Volts, its because the controller sensed it was a 5 Volt card (VS1# line is open). If it goes to 3.3 V when the Configuration Manager configures the card, it's because thats what the CIS or override is indicating.

Question:
Regarding CardBus, will a host that is strictly CardBus support a 16-bit 5V card that is in a 5V key or does is have to be a 3V key?

Answer:
By definition a Cardbus host system must support both 16-bit PC Cards and CardBus cards. Since CardBus cards only operate at 3.3 Volts, the host system is not required to support 5 Volt PC Cards (but most hosts support both 3.3 V and 5 V).

Question:
I am having trouble setting up I/O communication with my memory and I/O PC Card using SystemSoft Card Services 2.1. The RequestIO function returns the correct I/O window size, and a valid base I/O address. A subsequent RequestConfiguration call returns SUCCESS.
When I write to the I/O address of the card, I see the IOWR and address lines have the correct values, but CE1 and CE2 do not go low to enable the card.
What do I have to do to map the card into the host's I/O space? GetConfigurationInfo returns the error UNSUPPORTED_SERVICE, presumably indicating that my version of card services does not support the newer function call.

Answer:
If the I/O window is set, CE1 and/or CE2 should toggle. Most PCMCIA host controllers gate IOWR and IORD with CE1/CE2. Some will assert the I/O strobes for all accesses (even ones not intended for the PC Card).
GetConfigurationInfo function should work. I would look to see why it doesn't. You may have a agrument length error or the command code is not the proper one for the GetConfigurationInfo. Normally, you do a GetConfigurationInfo first. You fill in the blanks and add some extra fields and fire it back as the argument for RequestConfiguration. The RequestConfiguration parameter table needs to be set correctly to enable power, I/Os, IRQ, Configuration Register Base address and value.

Question:
Can one count on using the Vpp pins in a laptop to supply 12Vdc or is it better to generate your own 12Vdc using a converter from 5Vdc?

Answer:
Most laptops supply 12 VDC on Vpp1 and Vpp2 to support the older Flash Memory cards (the newer flash devices only need 5 VDC or lower). The Vpp current generally limited to around 30 mA per pin 60 mA total). Some of newer handhelds that support PC Cards only supply the Vcc voltage (5 V or 3.3 V) on the Vpp pins.

Question:
Section 2.2.4.1.7 of the Host system specification states the minimum current per slot values. I am unclear as to what the difference between Average and Static is in this context.
In a 3.3 volt system, can a card be designed that typically takes 750mA but never exceeds this limit and still meet the PC Card Standard?

Answer:
Typically the definition of Static current is the amount of current used by the PC Card device when it is inactive. An example would be a SCSI controller card that was not actively transferring data between a SCSI device and the host system. In this case the Static and Average current values would be the same. (Note that the device is inactive, not in a powered-down state.)
The Average current is measured over a duration of 1 second. This value would be higher than the Static current if the SCSI controller was in the process of transferring data or commands to a SCSI device (i.e., active state).
If your 3.3 volt PC Card requires 750 mA at all times (active and inactive times), than it would not meet the minimum power requirements supplied by the host system (as defined in section 2.2.4.1.7). The PC Card Standard does not really put a maximum current requirement on PC Cards, except stating that the maximum current per power pin is 500 mA. Since there are two Vcc pins, the maximum per card is 1 A.

Question:
A couple of questions about the PwrDwn bit in the Configuration and Status Register:
If a card and host PC support the extended status register, then if PwrDwn is set to 1 and Req_Attn_Enable is set to 0, then the card should be able to disable its incoming call circuitry since if a wakeup event occurs, the host PC will never know about it (because the host PC will not receive a STSCHG event and it is not allowed to poll the card). Does this make sense?
If the PwrDwn bit is set to 1 by the host, does this say anything at all about whether the extended status register "attn" signal is allowed to cause a STSCHG event to the host PC?

Answer:
The PwrDwn bit was included in the PC Card Standard as a possible way to power down a card. When this bit is set, the card must retain it current configuration (Memory, I/O, etc.), but it only needs to respond to accesses to the Function Configuration Registers. Since the Extended Status Register was added after the PwrDwn bit was defined, there is no mention of how the card or host should operate in this condition. The idea of power management was addressed by a PCMCIA working group a few years ago and the conclusion was power management should be handled by the PC Card function (i.e., modem, ATA, etc.), and not by a single power-down bit. (As an example, the ATA PC Card interface has a set of ATA commands to handle power management.) Power management and the response to PC Card events will be specific to the type of PC Card and the host platform implementation.

Question:
The PCMCIA specifications says that for a 5V card, the card shall not draw more than an average of 100mA. Average is defined as maximum current required averaged over 1 second.
Does this mean that when we power up our card it is possible to draw 450mA for approximately 40ms, and then 50mA for the rest of the time while the CIS registers are being read? (This gives an average of 67mA over 1 second)

Answer:
The intent of limiting the average current to 100 mA is to support portable devices (i.e., PDAs) that have a limited current capacity. The current value was chosen to allow powering the PC Card's interface and Attribute Memory so the card type and operating current could be determined (from the card's tuples). If the card's operating power is higher, it must be switched off until the card has been configured for operation (writing to the Configuration Option Register).
The Standard does not specify the instantanous current requirements. What the system would do with the currents you described is totally dependent on the system's power capacity. In the case of a PDA running on two AA batteries (and near the end of battery life), the above PC Card would most likely cause the PDA to shut down.

Question:
I have a question about the generation of the IOIS16# signal. We built a Card that runs well the last year and a half, but with TIs new CardBus compatible socket controller PCI1131 we have the problem that the IOIS16# signal is not recognized.
We tried to fix the problem but a closer look to the PC Card Standard let me think it is impossible to satisfy the timing requirements. Our Card is a 16-bit I/O card that is used as an interface to an emulator. We use 16 bit access only. The card decodes only the address lines A0 to A2, and decoding of the higher lines is done by the socket controller. If a valid address for my card is present, then the card has to assert the IOIS16# signal. When does the card know about a valid address ? In the past the IOIS16# signal was derivated directly from the CE1# signal and worked well. A look into the specification says to me that the card has to assert the IOIS16# signal before CE# is valid. Time from address valid to IOIS16# max 35ns. Time from address valid to IORD# or IOWR# is 70ns. Setup time CE# to IORD# or IOWR# is 5ns.
How can I satisfy this requirement if the card knows 5ns before the IORD# or IOWR# signal that the address is valid ? That is much too late to assert the IOIS16# signal. Is it possible to tie the IOIS16# signal direct to GND?

Answer:
The IOIS16# is decoded from the address lines -- it does not include the control signals (CE1#/CE2#, REG#, IOR#, IOWR#, etc.). This means that the IOIS16# signal may be asserted by the PC Card for accesses that are not intended for the PC Card. The PCMCIA controller will ignore the IOIS16# signal from the PC Card unless the access is intended for the card. IOIS16# may be asserted too late if the control signals are included in its generation.
If all the I/O ports can be accessed as 16 bits ports, the IOIS16# signal can be grounded on the PC card. (At power-on time this signal is Write Protect [WP], and would indicate that the memory/configuration registers on the card are writeable).

Question:
We are developing a 3.3 V operation, PCMCIA Type II pager card. Can the 16-bit PC card socket provide 3.3 V for my circuitry? Do all Laptop PCs support 3.3V? Does HPCs like Cassiopea, HP and Philips Velo support 3.3 V operation? How should I configure the socket so that my card can operate at 3.3 V?

Answer:
Some 16-bit PC Card sockets support 3.3 volts. Most PC Cards operate on 5 volts and therefore so do most host systems (i.e., HPCs). In order to configure your card to operate on 3.3 V, you ground the VS1 (voltage sense 1) pin on the card and use a low voltage-only connector if the card cannot operate at 5 volts (the low voltage connector on the PC Card will not fit into a older 5 volt socket).

Question:
We are designing an I/O and memory card. It has 16 byte I/O, 1 interrupt and attribute and common memory. We want to use the card under Windows NT using the native PCMCIA.SYS enabler of Microsoft. Can you tell me what tuple we have to set in the CIS to have the PCMCIA.SYS set the Window Data Size bit in the Memory Map Start Address register of the PCMCIA host controller. This bit to 1 means 16 bit datapath to the card.

Answer:
Windows NT 3.51 and 4.0 does not have support for general purpose PC Cards. It supports a few specific types (ATA, modem, network), but others are not supported. The PCMCIA.SYS driver does not support the PCMCIA Card Services inteface. You may need to use third-party software (Award, Phoenix, SystemSoft, etc.) to get support you need for your PC Card.

Question:
I'm developing a VxD under Windows95 to gain access to a PCMCIA card. I'm also writing the CIS for the card. The application program, which someone else is writing, must be able to both read and write to the attribute memory (to store calibration data in EEPROM). But how do I access the attribute memory? Can I map it into the hosts memory space or do I have to use card and socket services (wich I haven't seen any reference to in the DDK)?

Answer:
Under Windows 95 there are two ways to get access to the Attribute Memory space. Since Microsoft goes out of its way to keep the Card Services interface hidden, you can use the Configuration Manager to create the window. The trick is to specify a CIS override using the .INF file for the PC Card. The .INF file can be used to fix a "broken" PC Card CIS or (as in this case), to open an Attribute Memory window which Windows will not create using the CIS alone. Search the DDK for examples on using the .INF file in this manner. Your VxD would then retrieve the Attribute Memory window address (and other configuration resources) from the Configuration Manager.
The second way is using Windows' Card Services interface. The CS API follows PCMCIA's Release 2.1 Card Services interface and are documented in the DDK and C wrappers for the calls are included in Vireo's VToolsD device driver toolkit. Searching the DDK should get you started.
After you have created an Attribute Memory window using your VxD, you will need to map this memory space into the application's program memory space and pass along memory address to the application.

Question:
I have two questions about the operation of the Pin Replacement Register:
1) How are the upper four bits of the Pin Replacement Register reset? The corresponding "delta" bits in the Extended Status Register are reset when the host writes a 1 to the bits. Are the "delta" bits in the PRR reset to 0 when the host writes a 1 or a 0 to the bits?
2) The specification says the lower four bits of the PRR act as mask bits for the upper four bits but the specification also says "When this bit is written as 1 the corresponding XXX bit is also written..." which seems to imply that if the host writes a 1 to one of the lower four bits, the corresponding "delta" bit immediately is set to 1. Is this the intent or is the intent that when one of the lower four bits is 1, the upper bit is merely unmasked?

Answer:
The Pin Replacement Register has two functions. When read, the lower 4 bits (D0 to D3) provide current status of the four signals (WP, READY, BVD2, BVD1). The upper four bits (D4 to D7) indicate if one of the lower status signals have changed state.
The second function allows the upper four "changed" bits (latches) to be written. The upper four changed latches are written when the corresponding "mask" bit (D0 to D3) is a "1." For example, to clear the CWProt bit (D4), the RWProt bit (D0) must be set. The value written to do this is 0x01. To set the CWProt bit, write 0x11. None of three upper change latches are affected by the write since their corresponding mask bits are not set. Writing a 0x0C would clear the CBVD2 and CBVD1 (D6 and D7) changed bits.
The "or" of the upper four "changed" bits is seen as the "Changed" bit in the Configuration and Status Register. This "changed" bit drives the STSCHG# signal if the SigChg bit is set in the same register.
One problem the Pin Replacement Register implementation has that the Extended Status Register doesn't is the ability to select which status signal generates a "changed" interrupt (through STSCHG#).

Question:
1) We are designing a card with at least three seperate I/O functions. Is this possible? The ExCa specification and most host controllers only provide two I/O windows. Is it possible to have two fuctions specify the same I/O range in the CIS, with each function using half the range? Will Card and Socket Services accept such a request.
2) Does Windows 95 support the memory mapped configuration for ATA drives?

Answer:
1) Most PC Card Host controllers only support two separate I/O windows. You may be able to support the three I/O functions by having two of the functions share one of the I/O windows (i.e., function 0 uses the lower 8 bytes of a 16-byte window, and function 1 uses the upper 8 bytes). The third function uses its own I/O window. Card Services would support this setup because there are only two I/O windows. The catch is you would have to provide your own device driver to request this configuration through Card Services. If you are trying to define "standard" device types (modem, ATA, LAN), the typical "generic enabler" programs may not decode the CIS properly for this configuration.
2) I don't know for sure if Windows 95 supports ATA's memory mapped mode, but I would bet against it. The ATA PC Card shares the same device driver as the system IDE drives (which are I/O mapped). The ATA I/O modes support the Primary address (1FXh/3FXh -- which is usually used by the system hard disk); Secondary address (17Xh/37Xh -- which is usually used by the system ATAPI CD-ROM); and Block I/O mode which allows the I/O to be located at any available 16-byte address. This last I/O mode allows the card to be used in most systems. The ATA's memory mode is an optional mode and not support by all ATA PC Cards.

Question:
We manufacture a product where we use PCMCIA flash cards for long term storage of data in our own proprietary format. We use the cards in a "linear memory" format, not a "file" format. We now would like to be able to access the data on the cards using the card slots in standard PCs. Our software people can find Windows function calls for "file" access to PCMCIA cards, but are having problems with "linear memory" or "random sector" type access.

Answer:
Flash PC Cards come in two flavors: Linear flash and ATA flash. ATA flash emulates an IDE hard disk where the memory is accessed like sectors on a disk drive. The cards will work with standard ATA device drivers built into most operating systems, but require a memory controller inside the PC Card to "manage" the flash memory. Linear flash cards are simply flash memory devices connected to the PC Card interface. This allows direct access to any memory location on the flash card. Since you can't do a simple memory write to flash memory, there are special device drivers required to handle the flash memory writes and erases (for each type of flash memory).
This driver is typically tied into a file system (e.g., FTL or FFS) which takes requests reading and writing the flash memory. The typical operating systems interfaces with the flash memory drivers for managing the file system structure on the flash card but don't normally support reading and writing directly to the flash card as you require.
At this point there are three solutions to your problem:
1) Write a Card Services client program that accesses the memory using the Memory Technology Driver interface (Open memory, Write memory, Read memory).
2) Write a program that directly controls the PC Card controller and maps the memory card into host memory space. The program can then directly read and write the flash memory using the proper algorithms for the flash memory being used.
3) Contact the Card Services vendor (Award, Phoenix, Systemsoft, etc.) to see if they have a way to directly write/read flash memory. One example would be a program that could transfer the contents of the flash memory card to/from a disk file.

Answer:
The current PC Card Standard limits the current draw at startup to 100 mA for 5 volt cards and 70 mA for 3.3 volt cards. This requirement is intended to allow low power host systems (i.e., PDAs and small laptops) to be able to read the card's CIS and reject the card (with a message to the operator) if it determines the card WILL consume more current than it can supply or will greatly reduce the operating time from the battery supply.
To answer your question, drawing 200 mA at startup would violate the Standard and may cause some PDAs to not power-up when the card is installed.

CallCardService(OPEN_MEMORY, &handle, NULL, size, &MemInfo)

.
.
.

CallCardService(WRITE_MEMORY, &handle, &buffer, size, &RWInfo)

The call to write memory returns a code of 1Ah indicating that the device is write-protected. What do these services use to detect the write-protect state?

2) Should this code be returned if the card is using the I/O interface (as opposed to the Memory Only Interface)?

3) After card insertion and application of VCC and the RESET signal, what CIS information is used to configure the card to use the I/O interface?

Answer:
1) The PC Card interface contains a WP (write protect) signal that indicates if the memory card is write protected (typically using a switch that the user can activate).
The CIS (tuples) indicate if the WP signal is valid for memory space being accessed. How the WP status is handled depends on the Card Services and/or Memory Device driver. The PC Card Standard provides the ability to access the WP status but does not specify how it should be implemented.

2) When the PC Card is in I/O and Memory mode, the WP signal becomes IOIS16# The WP status is available in the Pin Replacement Register, which can be read by the memory card driver and reported as an error if it determines that the memory portion uses the write protect feature and WP is active. Again this depends on how the Card Services / Memory Device driver is implemented. If you are receiving this error and your card does not implement memory in the I/O mode, the CIS tuples may be incorrect.

3) The Configuration Table Entry Tuple (1Bh) contains information about the I/O interfaces supported. The Function ID tuple is used to determine the type of I/O function(s) supported (i.e., modem, ATA, LAN, SCSI, etc.).

Answer:
Unlike PCI devices CardBus doesn't used IDSEL for configuration because CardBus PC Cards always operate in a point-to-point environment. This means they are always the intended target of the configuration cycles and don't require a pin indicating such. You can find more information about the differences between CardBus and PCI in the PC Card Standard Guidelines (Volume 10).

Answer:
The problem you describe was introduced in Windows 95 B (OSR2) and there seems to be no (automatic) way to get around the problem. The problem is not with the CIS contents but with Windows 95. It looks like Windows loses track of where the .INF file is located after selecting the device from the 2EINF file. You will need to add instructions to your installation manual (or readme file) instructing the user to use the "Browse" button or type the locations of the .INF file ("A:\") when Windows states that it can't locate the .INF file.

Answer:
The PC Card Standard documents the Configuration and Status Registers (CSR), bit 4 as RFU. Intel described a use for this bit back in 1993 (ExCA 1.50 Specification) as the "Event Enable bit" that enables the "event wake up" signal (pin 63, STSCHG#). Bit 6 in the Miscellaneous Features field of the Card Configuration Entry tuple (1Bh) is set (1) if the card supports this feature. The current PC Card Standard defines the Miscellaneous Features bit 6, and CSR bit 4, as RFU, but defines the Extended Status Register to serve the same purpose (except the attention status can be read and cleared from the register).
Microsoft's PC 97 Requirements allow for the Wakeup Event to use the CSR register (not supported by the PC Card Standard, but may be used by older PC Cards), or the Extended Status Register. The Configuration tuple will indicate if the PC Card supports the Extended Status Register. All new PC Card designs supporting the Wakeup Event should use the Extended Status Register.
A copy of the ExCA (Exchangeable Card Architecture) Specification may be available from Intel Corporation.

Answer:
Developing systems that only support 3.3 volt 16-bit PC Cards will limit the number of cards available to run in you PDA. Currently systems support 5 volt PC Cards and some support 3.3 volt cards as well. As more systems move to CardBus (which requires 3.3 volt cards and backward support for 16-bit PC Cards), we may find PC Card developers producing 3.3 volt-only cards. Members of the PCMCIA committee hoped that PC Cards would be able = to handle both 5 volt and 3.3 volt host systems. This turned out to be a tougher problem to solve (in the ASIC), so we still have 5 volt PC Cards and PDA using charge pumps to provide the 5 volt PC Card voltage. You may want to poll PC Card manufacturers of the type expected to run in your PDA to see if they have (or plan to have) 3.3 volt PC Cards.

Details:

           ____      ____      ____      ____      ___
clock    _/    \____/    \____/    \____/    \____/   
                              |                       
         ________             |        _______________
IOWR#            \____________|_______/               
                              |       |               
                              |<-tdr->|               
         _________            |_______|_______________
WAIT#             \___________/       |               
                                      |               
                         |<----tsu--->|<-th->|        
                         |___________________|        
D[15:0]  ----------------<_____new_data______>--------
                                                      
                _______________ ______________________
internal data   ___old_data____X___new_data___________

WAIT# is activated ('0') as soon as possible after IOWR# low (asynchronous). WAIT# is inactivated ('1') synchronized by the rising edge of the clock. At the same time data is clocked into the internal register of the ASIC.

My questions:
- is my assumption correct, can I clock data when I raise wait#?
- does the same apply to memory writes?
- in the PC card standard 2.1 tsu(IOWR) was specified to the falling edge of IOWR, why is this changed?

Remark:
In figure 4-10 tsu WT(IOWR) is shown, this should be tsu(IOWR) as in table 4-25.

Answer:
The assumption you make about I/O Write timing is correct. The February 1995 Electrical Specification for Figure 4-10 is incorrect. The D[15::0] timing should be the same as in Release 2.1. (This was corrected in the March 1995 specification update.) Host write data MUST be valid prior to the leading edge of IOWR#.
As far as Figure 4-10 "tsuWT(IOWR)," this was also corrected in the specification update.

Answer:
The READY signal on the PC Card 16 interface can be used to delay the reading of CIS by the host. The PC Card Standard (May 1996 Update) states that READY must be negated after reset or when VCC becomes stable, if the card requires more than 20 ms for internal initialization (Electrical Specification, section 4.4.6). (The maximum time READY can be negated is 5 seconds.)
In your FPGA design, you should be able to use it to hold the CIS data as long as you can negate READY during the LCA loading.

Answer:
The current PC Card Standard defines multifunction cards as two or more I/O functions on a card. Each I/O function would have its own set of Function Configuration Registers (FCR) so it can be configured independently in the system (see Electrical Specification, section 4.14).
The Metaformat Specification describes the Multiple Function 16-bit PC Card Link Tuple. This tuple points to separate CIS chains that describe each function.
The PC Card hardware is only one aspect of the equation. In order to get multifunctions cards working propertly, the host software (Card and Socket Services, client drivers, etc.) must also support multiple functions.

Answer:
The PC Card Specification doesn't specify the maximum power a card can draw. In the Physical Specification it states the maximum current for each pin on the 68 pin connector, is 0.5 A. Since there are two Vcc pins, this seems to indicate that the true maximum current is 1 A. Typically, 16-bit PC Cards consume from 50ma to 350 ma. There are some cards that require 500 ma and some older cards (e.g., ATA) that required 750 ma.
The Vpp pins also have the same physical current specification. Since the intent of these pins was to provide programming voltage (e.g., 12 V) for flash memory, the current on each pin is typically limited to 20 ma in host systems.
The PC Card Standard does describe start-up currents. It limits the start-up current (power consumed before the card has been configured) to 100 ma for 5 volt cards and 70 ma for 3.3 volt cards. This allows the card's CIS to be read by all types of hosts (from PDAs to desktops) and rejected if the power requirements (as described in the CIS) cannot be meet.

Answer:
12 volts on VPP is common in laptops (at low currents), but may not be very common in PDA, HPC, and other handheld devices.

Answer:
The PC Card Standard implies that all signals from the host be tri-stated (hi-z). This occurs for a period after power-on and reset. There is a page in the Standard that shows the power-on timing. On this page it shows the RESET signal being hi-z for 100 mS after power is applied to the card. The Standard allows the card to have pull-down resistors (for ESD and to limit current draw on CMOS inputs) and pull-up resistors for control signals (e.g, OE#, WE#, IOR#, IOW#, etc.) to negate the signals during power-on and RESET times.