How Windows 98 Managed PCMCIA Card States

Microsoft Windows 98 managed PCMCIA (PC Card and CardBus) peripheral states through a tightly integrated combination of physical pin sensing, interrupt-driven hardware controllers, and its native Plug and Play (PnP) subsystem. By coordinating between the socket controller hardware, the operating system's PCMCIA bus driver, and the Configuration Manager, Windows 98 could detect insertions and removals in real time, dynamically allocate system resources, and load or unload the appropriate device drivers without requiring a system reboot.

Physical Detection via Card Detect Pins

The physical detection of a PCMCIA card relied on specialized pin layouts defined by the PCMCIA standard. Each card interface featured two Card Detect pins (CD1# and CD2#) that were shorter than the power and ground pins. When a user inserted a card, the longer power pins made contact first to safely ground and power the card before the shorter detect pins seated. Once both detect pins were fully engaged and pulled to ground, the host socket controller recognized that a card was securely present. Conversely, upon removal, the shorter pins disconnected first, giving the controller immediate warning that an ejection had begun.

Controller Interrupts and Card Services

Upon sensing a state change via the detect pins, the PCMCIA host controller (typically a controller chip from vendors like Texas Instruments, Cirrus Logic, or Ricoh) generated a hardware interrupt. Windows 98 handled this through its PCMCIA bus driver (PCMCIA.SYS) working alongside Card Services.

The bus driver acted as the intermediary between the hardware socket and the Windows 98 Plug and Play subsystem. When the interrupt fired, the driver queried the controller's socket status register to determine the exact nature of the event: insertion, removal, or a ready-status transition.

Reading the Card Information Structure (CIS)

Once an insertion was verified, the bus driver read the Card Information Structure (CIS)—also known as the card's "tuples"—stored in the non-volatile memory of the card. The CIS contained critical metadata about the peripheral, including:

  • Manufacturer and device identifiers.
  • Supported operating voltages (e.g., 5V vs. 3.3V).
  • Required system resources, including memory windows, I/O ranges, and interrupt requests (IRQs).
  • Functional specifications (such as network adapter, modem, or SCSI host).

Dynamic Resource Allocation via Configuration Manager

After parsing the CIS, the PCMCIA driver passed the device information to the Windows 98 Configuration Manager. The Configuration Manager evaluated the peripheral's resource requirements against currently assigned system resources.

Because Windows 98 utilized an enhanced 32-bit Configuration Manager, it could dynamically assign free I/O ports, memory addresses, and IRQs to the PCMCIA socket. If resource conflicts arose, the operating system could reassign resources from other flexible devices. Once resources were reserved, Windows 98 matched the hardware identifier to an installation script (.INF file), loaded the corresponding Virtual Device Driver (VxD) or Windows Driver Model (WDM) driver into memory, and marked the peripheral state as active.

State Transitions During Removal

Windows 98 supported two methods of peripheral removal: controlled ejection and surprise removal.

  1. Controlled Removal: A user clicked the PC Card icon in the system tray to stop the device. The Configuration Manager notified the active driver to flush pending write buffers, cease active I/O transactions, and release the hardware. Windows 98 then notified the user that the card could be safely extracted.
  2. Surprise Removal: If a card was physically yanked from the slot while active, the disconnection of the CD1# and CD2# pins caused the controller to trigger an immediate interrupt. PCMCIA.SYS immediately signaled the Configuration Manager to tear down the device stack. The operating system terminated active communications, unmapped the memory ranges and I/O ports, unloaded the driver, and returned the reclaimed hardware resources to the system pool for future allocation.