EXHIBIT 1017
`IPR Petition for U.S. Patent No. 6,249,825
`
`

`

`M&T Books
`A Division of MIS:Press, Inc.
`A Subsidiary of Henry Holt and Company, Inc.
`115. West 18th Street
`New York, New York 10011
`
`© 1995 by M& T Books
`
`Printed in the United States of America
`
`All rights reserved. No part of this book may be reproduced or transmitted in
`any form or by any means, electronic or mechanical, including
`photocopying, recording, or by any information storage and retrieval system,
`without prior written permission from the Publisher. Contact the Publisher
`for information on foreign rights.
`
`Limits of Liability and Disclaimer of Warranty
`The Author and Publisher of this book have used their best efforts in
`preparing the book and the pr_ograms contained in it. These efforts include
`the development, research, and testing of the theories and programs to
`determine their effectiveness.
`
`The Author and Publisher make no warranty of any kind, expressed or
`implied, with regard to these programs or the documentation contained in
`this book. The Author and Publisher shall not be liable in any event for
`incidental or consequential damages in connection with, or arising out of, the
`furnishing, performance, or use of these programs.
`
`All products, names and services are trademarks or registered trademarks of
`their respective companies.
`
`Library of Congress Cataloging-in-Publication Data
`
`Levine, Larry
`PCMCIA primer I Larry Levine.
`p. em.
`Includes index.
`ISBN 1-55828-437-0
`1. PCMCIA cards Microcomputers
`TK7895.P38L48
`1995
`004.6'4dc20
`
`I. Title.
`
`Associate Publisher: Paul Farrell
`Managing Editor: Cary Sullivan
`Acquisitions Editor: Jono Hardjowirogo
`Copy Edit Manager: Shari Chappell
`Development Editor: Michael Sprague
`Production Editor: Joe McPartland
`Copy Editor: Greg Robertson
`Technical Editor: Christine Nevin
`
`95-24177
`CIP
`
`

`

`CHAPTER 5~
`
`SEQUENCE OF EVENTS
`
`By now, you should have a pretty good understanding of how each of the
`components within the PCMCIA architecture function-independently
`of one another. The architecture was presented in a bottom-up fashion to
`enable you to see how each of the services and functions within the
`PCMCIA architecture is abstracted. In getting such a detailed explanation
`of the services at each level, however, you may have lost sight of the for(cid:173)
`est for the trees. This chapter gives you a walk-through of what happens
`when various types of PC Cards are inserted into the system's PCMCIA
`slots. We will walk through the initialization, recognition, configuration,
`and use of an 1/0 PC Card and a memory PC Card. The exact same set of
`events occurs for all PC Cards within each class. The things that change
`with different types of PC Cards, however, are the clients that actually
`provide the recognition and configuration serviqes as well as the resources
`actually needed by the PC Cards. This walk-through of a PC Card inser(cid:173)
`tion summarizes the resulting events for all types of PC Cards and clients.
`
`

`

`PCMCIA Primer
`
`NOTE
`
`For the remainder of this chapter, I describe a series of events and further process(cid:173)
`ing that might and, in my opinion, should occur. This chapter does not attempt to
`describe any one or multiple implementations of PCMCIA 2.1, but rather an inter(cid:173)
`pretation of the PCMCIA 2.1 specifications. In particular, this is my interpretation
`and theoretical implementation. Different vendors have their own, different inter(cid:173)
`pretations and implementations.
`
`Initialization
`
`Before anything can happen with the PC Cards, the PCMCIA handlers
`must be loaded and initialized. This is accomplished differently on different
`PCs with different PCMCIA handler implementations. In all likelihood,
`they are loaded as device drivers within the DOS CONFIG.SYS file.
`Socket Services is the first to be loaded. Quite simply, it recognizes
`the PCMCIA controller, resets the controller's configuration, installs a
`Card Status Change (CSC) interrupt handler, and installs itself as an INT
`1 AH handler.
`Card Services is loaded next; it initializes its resource and client data(cid:173)
`bases. It looks for Socket Services in memory, installs its own Card Status
`Change interrupt service routine replacing the one installed by Socket
`Services, and installs its own INT tAH handler, again replacing the one
`installed by Socket Services. Lastly, it gathers the Memory, I/0, and IRQ
`resources into its database of available resources for allocation to PC Cards.
`Finally, a set of Card Services clients registers with Card Services to
`provide recognition and configuration services to memory and I/0 cards.
`This set of clients varies greatly depending on vendor implementation and
`user configuration.
`After all the PCMCIA handlers and Card Services clients are loaded,
`the system is ready for insertion of PC Cards.
`
`In fact, PC Cards can be recognized and configured before all the PCMCIA handlers
`and clients are running. To provide any more insight at this point as to how or why
`this is possible would only confuse you. I will provide more insight into this in the
`"Troubleshooting" appendix.
`
`NOTE
`
`

`

`CHAPTER 5-Sequence of Events
`
`Insertion, Recognition, and Configuration
`Processing
`
`The first few steps of PC Card insertion processing (which all usually
`occur in less than 1 second) are identical for all types of PC Cards.
`Therefore, there will be only one discussion of the first few steps, in the
`"Insertion Processing" section. The recognition and configuration of 1/0
`PC Cards and memory PC Cards tend to differ slightly. For this reason,
`the recognition and configuration of these cards are broken out into their
`own, appropriately named, "1/0 PC Card Recognition and
`Configuration" and "Memory PC Card Recognition and Configuration"
`sections.
`
`Insertion Processing
`
`1. The first thing that happens, of course is that the PC Card is inserted
`into the PCMCIA slot (see Figure 5.1). Slowing this down, you can
`see how it makes sense that the power signals (Vpp and Vee) are con(cid:173)
`nected first through the longest pins. Next, the data, address, and var(cid:173)
`ious control signals make contact via the medium-length pins. Finally,
`the Card Detect (CD) pin makes contact. The connection of the
`Card Detect pin with a PC Card causes a Card Status Change inter(cid:173)
`rupt to occur.
`2. Having installed a Card Status Change interrupt service routine, Card
`Services is ready to handle the Card Status Change interrupt that just
`occurred when the Card Detect pins made contact with the PC Card.
`Card Services issues an Acknowledgeinterrupt() Socket Services call and
`will usually queue this event for later processing (possibly after an
`internal timer expires). It does this so that the Card Status Change
`interrupt can be returned as quickly as possible to avoid the possibil(cid:173)
`ity of the system missing lower-priority interrupts (Card Services is a
`good citizen here) and to debounce the Card Status Change signal in
`software as it is not done in hardware.
`
`

`

`PCMCIA Primer
`
`Software
`
`Hardware t
`
`..,_ _____ System Bus (!SA, PCI, etc.)
`
`PCMCIABus
`
`Figure 5.1. PC Card insertion.
`
`DEFINITION
`
`When a mechanical or elec.trical switch opens or closes, the contact actually
`bounces opened and closed many times before settling. This opening and closing can
`occur for many milliseconds, possibly causing higher-level software or subsequent
`circuitry to needlessly (and possibly wrongly) execute. Switches can be debounced in
`hardware with additional logic. Less efficiently, but effectively, the bounce can be
`ignored with an appropriate delay in subsequent circuitry or software.
`
`

`

`CHAPTER 5-Sequence of Events I
`
`3. Once Card Se-rvices has delayed and debounced the Card Detect sig(cid:173)
`nal, Card Services queries the exact status of the PCMCIA slot via the
`Socket Services call GetStatus(). If Card Services determines that the
`state of the PCMCIA socket has changed, further processing occurs.
`The status changes most likely to occur are PC Card insertions and
`removals.
`
`For the remainder of this walk-through, we will assume that a PC Card
`was just inserted into the PCMCIA slot. It is easy to assess what might hap(cid:173)
`pen if this change was a PC Card removal instead.
`Because Card Services has determined that a PC Card was just
`inserted into the PCMCIA slot, it must generate CARD_INSERTION
`events, via callbacks, to each Card Services client in its client databases.
`
`1/0 PC Card Recognition and Configuration
`
`5.
`
`4. Card Services issues callbacks with a CARD_INSERTION event to
`the 110 clients first. See Figure 5.2.
`In turn, each 110 client, upon receiving the CARD_INSERTION call(cid:173)
`back, issues a GetConfigurationlnfo() Card Services function call, and fur(cid:173)
`ther reads the PC Card's CIS.
`If the PC Card is already configured or if the 110 client does not rec(cid:173)
`ognize the PC Card, it will simply return the callback to Card
`Services.
`If the 1/0 client (possibly a Super client) does recognize the PC Card,
`it further reads the CISTPL_CFTABLE_ENTRY tuples within the PC
`Card's CIS, checking for possible configurations through additional
`calls to Card Services.
`This 1/0 client uses the configuration information gathered from
`these CISTPL_CFTABLE_ENTRY tuples to build RequestiO() and
`RequestiRQ() Card Services function calls (and possibly even
`RequestWindow() function calls in the case of needed memory windows
`to use as shared memory for some LAN and other PC Cards). In turn,
`Card Services checks its internal database of resources and marks the
`
`

`

`PCMCIA Primer
`
`resources as reserved for this 110 client. Card Services does not issue
`any Socket Services calls at this point, as no changes are being made
`to the configuration of the controller. Card Services also assumes that
`it is the only user of Socket Services (remember?).
`After reserving the resources the 1/0 client requested, the 1/0 client
`issues a RequestConfiguration() Card Services function call to cause the
`PCMCIA controller to configure the PC Card.
`
`I ATA
`
`Suppor
`
`Software f
`Hardwau·e t
`
`,-h
`I PC
`L:~~.l
`
`i
`
`Figure 5.2. 1/0 PC Card recognition and configuration.
`
`

`

`CHAPTER 5-Sequence of Events
`
`6.
`
`In turn, Card Services issues a series of SetAdapter(), SetSocket(), and
`SetWindow() Socket Services calls to effect these changes at the PCM(cid:173)
`CIA controller.
`After all of this is complete and the 110 client is satisfied that the PC
`Card is properly configured, it will then finally return the
`CARD_INSERTION event callback to Card Services.
`7. At this point, the PC Card has been configured, but Card Services
`still has to complete its job. It continues to call back each of the
`remaining clients in its database that is interested in CARD_INSER(cid:173)
`TION events. Once all 110 clients are called back, Card Services calls
`back each of the MTD clients.
`Upon receiving the callback, each MTD client issues a
`GetConfigurationinfo() Card Services call to see if the PC Card has
`already been configured by another client. The return code from the
`call tells the MTD handler that the PC Card has already been config(cid:173)
`ured. The MTD handler simply returns the callback to Card Services.
`8. Even though the PC Card has been configured long ago, Card
`Services must push on and call all of its clients. Perhaps a memory
`client wants to display a cute little window telling the user that some(cid:173)
`thing happened in the PCMCIA slot.
`Eventually, Card Services completes the traversing of its database of
`clients. Card Services may simply settle back and await another call(cid:173)
`back or user request, or it may first decide to issue some visible or
`audible notification to the human sitting in front of the PC that the
`PC Card was configured. Depending on the implementation, this may
`be a decision partially made by the human and partially made by the
`PCMCIA handler and PC manufacturer.. The PCMCIA specifications
`do not specify this procedure.
`
`At this point, the 1/0 PC Card has been completely configured. Its
`resources have been mapped into the system and are ready for use by
`standard (and custom) applications and operating system utilities. You
`may skip on to the "Use it or Lose it!" section or read through the
`"Memory PC Card Recognition and Configuration" section to see how a
`memory PC Card is recognized and configured.
`
`

`

`PCMCIA Primer
`
`Memory PC Card Recognition and Configuration
`
`9. Again, Card Services first issues CARD_INSERTION callbacks to
`each of the 110 clients in its client database (see figure 5.3).
`Each 110 client issues GetConfigurationlnfo() or GetFirstTuple(),
`GetNextTuple(J and GetTupleData() Card Services function calls to see
`whether the PC Card has been configured or whether the PC Card
`can be recognized. Because this is a memory PC Card, the 110 clients
`attempts to recognize the PC Card fail. All callbacks to the 110 clients
`return to Card Services with no further configuration requests.
`10. Card Services then issues CARD_INSERTION callbacks to each of
`the MTD clients. Upon receiving the callback, each MTD client
`issues a GetConfigurationlnfo() Card Services call to see whether the PC
`Card has already been configured by another client. The return code
`from the call tells the MTD handler that the PC Card has not been
`configured. The MTD handler then issues further Card Services calls
`in an attempt to recognize the PC Card. The MTD handler soon
`determines that the PC Card is a memory PC Card. If the regions
`defined by tuples within the CIS are not those that the MTD handler
`recognizes, the callback will be returned to Card Services.
`If, instead, they are recognized by the MTD handler, the MTD han(cid:173)
`dler will issue RegisterMTD() Card Services function calls to inform
`Card Services that the MTD handler is standing by to service mem(cid:173)
`ory requests for the inserted PC Card.
`The callback is then returned to'Card Services.
`11. All memory clients are also called back next. The memory client
`responsible for File Services requests may recognize that a. (set of)
`region(s) has been defined on the PC Card. It then informs the asso(cid:173)
`ciated file system handlers (FTL and/or FFS) to inspect the PC Card
`to look for their respective file system structures (format).
`
`This mechanism is not entirely accurate. For the most part, the memory c_lient
`responsible to the file system may be an operating system driver different from that
`of the filing system handlers. If this is the case, the memory client will communicate
`to the file system handlers through a set of interfaces beyond the scope of what the
`PCMCIA specifications define.
`
`

`

`CHAPTER 5-Sequence of Events
`
`Software 1
`Hardware f
`
`.. .- PCMCIA Bus
`
`.... t---···1 ~ ~~=~ ->-
`I
`__ ::~:..J
`
`PC
`
`Figure 5.3. Memory PC Card recognition and configuration.
`
`The file system handler that recognizes its own format on the PC
`Card makes note that it will be servicing file system requests through
`its interface for this PC Card and socket.
`
`This Memory client then returns the callback to Card Services.
`12. Card Services continues processing callbacks for all remaining mem(cid:173)
`ory clients. A memory client may be loaded that displays a pretty
`
`

`

`PCMCIA Primer
`
`window to the user informing him or her of the type of the inserted
`PC Card.
`Card Services may also be designed and configured to make some vis(cid:173)
`ible or audible indication to the user of the PC Card type and other
`pertinent information.
`At this point, the memory PC Card has been completely recognized.
`Memory and/or file system handlers are standing by ready to service
`and handle requests for the PC Card.
`
`In both of these examples, there may have been hundreds of Card
`Services calls (i.e., to read tuples on the PC Card, check the configuration
`of the PC Card, and request various resources for the PC Card), all of
`which occur within a span of 1 or 2 seconds.
`
`Use It or Lose It!
`
`After the PC Card has been inserted, recognized, and configured, it is
`ready for use by the user and the system software. Whether or not further
`PCMCIA handler servicing is necessary depends mainly on whether the
`PC Card is an I/0 or memory PC Card.
`
`1/0 PC Card Use
`
`Using PC Cards such as ATA and fax/modems is easy (see Figure 5.4)!
`
`1. After they are configured, ATA PC Cards are usable without any fur(cid:173)
`ther interaction with Card Services. If you remember from a previous
`section, ATA stands for AT Attachment. As such, ATA PC Cards support
`the AT Attachment interface for hard disk drives in AT-class computer
`systems. Because DOS does not have a device driver for the Block
`Device Drive associated with the ATA PC Card, another piece of
`code (that is possibly embedded within the I/0 client that configured
`the ATA PC Card) allocates and directly supports a Block Device
`Drive letter associated with the ATA PC Card.
`
`

`

`CHAPTER 5-Sequence of Events
`
`r - - - - -
`1 Memory
`i Clients
`
`Software t
`Hardware t
`
`--i---·l
`
`PC
`Card
`
`PC
`Card
`
`Figure 5.4. Use of 110 PC Cards.
`
`2. Requests for disk sector reads and writes come directly into this ATA
`handler as an IOCTL request for 1/0 ports 170H-177H (defined in
`Table 2.1). This ATA handler then makes direct requests to these 110
`addresses at which the ATA PC Card is configured (as if it were just
`another local hard disk drive). Because the PCMCIA controller is
`configured to support these 110 addresses, all requests for the ATA PC
`
`

`

`PCMCIA Primer
`
`Card are captured by the PCMCIA controller and redirected to the
`ATA PC Card.
`
`IOCTL stands for 1/0 Control. An IOCTL is simply an 1/0 request to a piece of
`software instead of to a piece of hardware.
`
`DEFINITION
`
`Fax/modem PC Cards are even easier. They, too, are configured to behave
`like another device built into the system. Almost any (well-written) com(cid:173)
`munications application is capable of using fax/modem PC Cards, as they
`are mapped directly to the standard PC communications addresses (as
`defined in Table 2.1 ).
`Other 110 PC Cards such as SCSI and LAN PC Cards are almost as
`lucky. Although they are mapped directly into the system with no further
`need for PCMCIA interaction, the support for these types of devices is
`typically not delivered with DOS. It is usually necessary to load additional
`software, provided by the PC Card manufacturer, to use them. This soft(cid:173)
`ware is typically responsible for ODI, NDIS, and/or NetWare support, or it
`may be responsible for SCSI services. These terms are all particular to
`LAN and SCSI technology and each deserves its own book. If you are
`interested in these subjects, please feel free to take a trip to your local
`computer bookstore.
`
`Memory PC Card Use
`
`Memory PC Cards are not as lucky. They cannot stand alone without sup(cid:173)
`port from the PCMCIA handlers. As discussed earlier, there are three
`main reasons for this.
`
`1 . The entire memory PC Card address range is being mapped through a
`window that is slid around by the PCMCIA software.
`2. Support to read and write the memory on a Flash PC Card is typically
`provided in only the MTD handler clients.
`
`

`

`CHAPTER 5-Sequence of Events
`
`3. Due to the nature of Flash technology, the intelligence to recognize,
`read, write, and wear-level the file system on Flash PC Cards is pro(cid:173)
`vided by other PCMCIA handlers.
`
`As discussed, the memory PC Card is probably supporting an image of a
`file system-probably that of FTL or FFS (see Figure 5.5). As such, the PC
`Card will be directly supported by the FFS or FTL Block Device Drivers.
`
`Software f
`Hardware t
`
`___.. I'CMCIABus
`
`~--
`
`1- PCCarcl-1
`I
`I
`
`Socl<e<S
`
`---t - I
`
`I
`
`I
`
`PC
`Card
`
`I
`
`Figure 5.5. Use of memory PC Cards.
`
`

`

`PCMCIA Primer
`
`4.
`
`1 . When a request for one of these devices is initiated by operating sys(cid:173)
`tem or application software, the device driver associated with that
`device (FTL or FFS) gains control.
`2. This driver then puts together a request (through the File System
`Memory Client-if applicable) to Card Services.
`3. These requests are redirected by Card Services to the MTD handler
`supporting the memory technology in the PCMCIA slot being ser(cid:173)
`viced.
`In turn, the MTD handler carries out the specific read or write request
`directly to the PC Card through memory windows, possibly making
`further requests of Card Services through the Card Services MTD
`Helper functions.
`5. The request is then returned by the MTD handler to Card Services.
`6. Card Services returns the request to the File System Memory client,
`which then returns the request to the File System Block Device
`Driver.
`7. Finally, the request is returned to the operating system or application
`software.
`
`As you might guess, this process is quite tedious, is executed by many
`pieces of system software, and may be quite slow as a result (when com(cid:173)
`pared to native file services). As a result, it is also more prone to bugs than
`are 1/0 PC Cards. Think about it-many more handlers to run through,
`many more lines of code, many more interfaces, more chances for things
`to go wrong. This is not a warning to scare you away from the technol(cid:173)
`ogy. It is rather advice to you to back up your memory PC Card data reg(cid:173)
`ularly and to track the PC Card and PCMCIA handler manufacturer's
`improvements in software. Some problems may not be obvious to you.
`Heed your manufacturer's advice and upgrade as advised. PCMCIA is still
`a rather young technology.
`
`