Вы находитесь на странице: 1из 10

PCMKINIT.

COM Users Guide


This document is broken up into the following sections: 1. 2. 3. 4. 5. 6. Introduction to PCMKINIT Advanced Usage FYI: PCMCIA Socket Naming FYI: Compatibility with CardWares Generic Enabler PCMKINIT Revision Notes For Developers Only: The Interface to PCMKINIT

This information supplements that provided with your application software, and with the 1784PCMK or -PCMKS hardware itself. Some of the material here goes into a bit more depth than you might find in our product documentation; some, in fact, is intended strictly for experienced programmers who wish to create software that works with PCMKINIT. We suggest that you consult your product documentation first, then use the material presented here as needed. There are a lot of different PCMCIA software vendors, and no two do things exactly alike. As a result, getting the PCMK to work consistently on a given machine with various combinations of other hardware and drivers can be difficult. The best way to insure success is to read the documentation carefully. If youre on the Internet, you might find the article Making Sense of PCMCIA helpful. To find this article, go to the Rockwell Software Home Page (http://www.software.rockwell.com) and do a search for the article title. If you need more information about how to contact a particular PCMCIA software vendor, or would like to research other PCMCIA topics, probably the best place to start is on the home page of the PCMCIA organization itself: http://www.pc-card.com.

Introduction to PCMKINIT
Allen-Bradley ships the Award CardWare software with the PCMK card. This software provides PCMCIA Socket Services, PCMCIA Card Services, and a generic enabler. There are several drawbacks to using the CardWare software, however: By the time all these drivers are loaded, they consume nearly 100K of conventional DOS memory. Since PCMCIA hardware differs from machine-to-machine, the CardWare software does not work on some platforms, creating compatibility problems. The PCMK is confusing to configure. First, you must set up the CardWare generic enabler, telling it where to address each PCMK card. You must then duplicate these settings (adjusting the dual-port address by 300h) in the application software you are using. There is no way of specifying which PCMK card gets which configuration from the generic enabler if more than one PCMK is present. The cards are configured on a firstcome, first-serve basis. This is a little non-deterministic for an industrial environment. As a solution to these problems, Rockwell Software (formerly ICOM) developed a specific enabler for the 1784-PCMK. The specific enabler offers the following benefits: If the PCMK is the only PCMCIA card in use, it may be loaded as the only enabler in the system (no need to load a generic enabler), saving over 40K of conventional DOS memory.

Theoretically, it will work on any machine which has release 2.10 Socket Services and Card Services installed. This resolves many compatibility problems and allows the PCMK to be used on most PC compatible laptops with PCMCIA support. Allows Card Services to allocate resources to the PCMK so that you dont have to specify a particular dual-port address or IRQ for the PCMK. Provides an interface for applications to allow them to determine how many PCMCIA sockets are in the system, which have PCMK cards, and whether those PCMK cards are in use by other applications. This allows you to configure the PCMK from within the application simply by selecting the socket it is plugged in, without explicitly configuring a dual-port address or IRQ. Depending on the application, the PCMK may even be chosen off a list if there is more than one in the system. Configuration becomes very easy. The application now refers to a specific socket, so there is no question of which PCMK is being used by a particular application. The specific enabler includes code to assign resources to Card Services. This gives it the ability to run with only Socket Services and Card Services, and allows you to get the PCMK up and running without having to know how your PCMCIA system software vendor assigns resources. Memory blocks and IRQs are specified on the command line of the enabler if this functionality is desired.

Advanced Usage
If you have PCMCIA Socket Services and Card Services release 2.10 or greater already installed, all that needs to be done is to install PCMKINIT.COM by running it, either from AUTOEXEC.BAT or the DOS command line. This will stay resident in memory, but will only take about 2K of RAM. At this point applications which take advantage of the specific enabler may be used. Resources (memory ranges, IRQs, and I/O ports) always need to be allocated to Card Services for this to work. If the you have a generic enabler (a.k.a. super client driver) installed for using other PCMCIA cards, this is most likely already done. If not, PCMKINIT.COM version 1.05 and greater has the ability to allocate resources to Card Services itself. With this capability, installation becomes very simple: just load Socket Services, Card Services, and PCMKINIT.COM with the memory blocks and IRQs specified on the command line. Note that the best course of action is to use the resource allocator that came with your Card and Socket services software. In some cases, this is a separate driver. In others, the resource allocation may be built in to the generic enabler software. This is the best course of action because often vendors ship their systems with these resource allocators pre-configured to use acceptable memory ranges and IRQs for your system. The command line resource allocation of PCMKINIT should only be used if (1) you arent using any other cards besides the PCMK, and (2) you cant figure out how to get resources allocated using the software that came with your system. To use a PCMK, at least 8K must have been allocated to Card Services. One 4K block will be needed to access the PCMK's dual-port memory, and the other 4K block will be needed by Card Services to access configuration registers. These blocks do not need to be consecutive, but it is usually easiest just to specify a single block, i.e. D000-D1FF. As with CardWare or anything else, the memory range or ranges must be excluded from memory managers, and within the Windows SYSTEM.INI file using the EmmExclude statement (under the [386Enh] section.) Additional PCMK cards will, of course, require additional 4K blocks of memory.

Using the optional resource allocator in PCMKINIT.COM is simple. For example, you might include the following line in AUTOEXEC.BAT to give Card Services an 8K block at D000 and two interrupts. PCMKINIT M=D000-D1FF I=5,10 If only one IRQ is indicated, Card Services will probably use the interrupt and the PCMK card will not have an interrupt. If you must use INTERCHANGE software, the PCMK card requires an interrupt (youll need to specify two interrupts on the PCMKINIT line like the example above.) Note that Rockwell Softwares A.I. Series programming software and the WINtelligent LINX software do not require interrupts, although performance with LINX is improved if the PCMK uses an interrupt. A flexible, case-insensitive command line syntax reduces the potential for mistakes. For example, all of the following lines are interpreted correctly by the parser: PCMKINIT M=D000-D1FF,D400-D4FF I=3,5-7,10 PCMKINIT m = 0d100-0d200 i = 3,5 m = 0e100-0e200 PCMKINIT /I=3, 5, 10-12 /M=D000-D3FF, D600-D7FF The memory range switch takes the general form "M=", after which one or more commaseparated ranges may be specified. The IRQ switch takes the general form "I=", after which one or more IRQs or IRQ ranges may be specified. Multiple "M=" and "I=" options may be present on the same line. Forward slashes are optional, and spaces may be added without ill effect. To further reduce problems, a few basic checks are made before an attempt is made to allocate resources (for example, the parser will not accept IRQ 0, and a check is made for memory range conflicts with EMS page frames.) Again, if you have other PCMCIA cards, there is a good chance they won't need to give any more resources to Card Services; in this case PCMKINIT.COM may be loaded with no arguments on the command line, since the allocation has already been performed by another piece of the PCMCIA system software. If PCMKINIT.COM is the only enabler loaded, you may find that there is no audible indication of whether or not the PCMK was successfully configured. To cause PCMKINIT.COM to generate tones when the PCMK is inserted or removed, add the "S" option anywhere on the command line. For example: PCMKINIT M=D000-D1FF I=5-7,10 S Some versions of IBM Card Services as shipped on Thinkpad computers have a bug. This bug always reports that Card Services has no resources, even when it does. The result is that PCMKINIT will always refuse to load, and will instead print a message indicating that Card Services doesnt have the resources it needs to support the PCMK. To bypass the IBM bug and force PCMKINIT to load anyway, add the B option anywhere on the command line. We are not aware of this problem with any other Card Services software, so please do not use the B option unless you are using IBM Card Services and encounter this problem. (IBM was informed of this problem in July of 1995, and acknowledged it in November of 1995; we are still waiting for a fix.) Configuring the PCMK within an application which is aware of the specific enabler couldn't be easier: if only a single PCMK is present, it may simply be selected. If several are present, the user may be given a choice based on the socket number.

FYI: PCMCIA Socket Naming

The question arises as to how the user should be prompted to choose a PC Card if two or more identical I/O cards are installed in a system. Rockwell Software's programs currently use the logical socket number to refer to the slots, but this practice is not currently standardized by PCMCIA. When dealing with Card Services, sockets are referred to by a logical socket number beginning at zero. Unfortunately, no standard yet exists for how the user interface should refer to these slots. The Award CardWare software, for example, refers to the slots by default as "Slot 0" and "Slot 1". The SystemSoft software and Windows 95 refers to the first slot in the system as "Slot 1" instead of "Slot 0". This situation creates needless confusion for the end-user and is finally being addressed by PCMCIA. Rockwell Software joined the PCMCIA organization in 1995 and sponsored a proposal to add a socket naming service to Card Services. This proposal was finally accepted into the PCMCIA standard on December 5, 1996. Unfortunately, it will take some time for this new feature to show up in various operating systems; for now, the problem of what to call a particular socket is still very much with us. The end result? DOS programs such as the A.I. Series programming software, PCMKLIST.EXE, and WINtelligent LINX refer to the PCMK by a zero-based socket number (the first socket is number 0). Rockwell Softwares newer products have adopted the Windows 95 convention of one-based numbering to be consistent with Microsofts environment (the first socket is number 1).

FYI: Compatibility with CardWare's Generic Enabler


There are two flaws in the current PCMCIA 2.10 specification which conspire to cause problems for the PCMK specific enabler when loaded at the same time as the CardWare generic enabler (other generic enablers do not conflict, because they won't try to configure the PCMK.) To reduce support calls, it is suggested that applications be prepared to deal with the case where both enablers may be loaded (while it is possible to prevent PCMKINIT.COM from loading if the CardWare generic enabler is already present, the converse is not under Rockwell Software's control.) The first problem was designed as a feature: the last i/o enabler loaded will be the first to receive notifications of card insertions or removals. Supposing that the CardWare generic enabler is loaded first, and PCMKINIT.COM is loaded second, this means that when a PCMK is inserted into a running system that PCMKINIT.COM will get the first crack at enabling the card. Unfortunately, if the PCMK was already inserted in the PCMCIA socket when the system was booted, the CardWare enabler will configure the PCMK before PCMKINIT.COM installs. Since PCMKINIT.COM did not configure the PCMK, it is unable to return information about which dualport address and IRQ are being used by the card. The second problem is an oversight in the interface to Card Services: there is currently no way to determine which memory window(s) are in use by which sockets. If PCMKINIT.COM has enabled the PCMK, it "knows" the dual-port address of the PCMK card and can return that to applications for their use. If the CardWare enabler configured the PCMK, however, there is no standard way to determine the dual-port address from the PCMCIA socket number. It is our understanding that this oversight will be corrected in the next revision of the PCMCIA Card Services specification. Ventura Micro, Inc. (VMI), the original developer of the CardWare enabler shipped by Award and Allen-Bradley, also foresaw the need to be able to retrieve memory window information for a particular socket. Like Rockwell Software, they have a proprietary interface to their enabler which allows this information to be returned (this disclosed on a public CompuServe forum.) It is

recommended that, in addition to interfacing to PCMKINIT.COM, applications implement the interface to the CardWare generic enabler to determine where the PCMK card's memory window and IRQ are mapped. This allows the PCMK card to be selected by socket regardless of who configured it, and presents the user with a simple, consistent configuration screen. When the PCMCIA specification has been fixed so that the card address can be determined no matter which enabler configured the card, the code to retrieve this information from the enablers should no longer be necessary. For further information on the interface to the CardWare enabler, the developer should contact Award Software in Mountain View, California at 415-968-4433. Other PCMCIA information may be found on the World Wide Web at http://www.pc-card.com.

PCMKINIT Revision Notes


Version 2.00 Support for the PCMK Series B and PCMKS Series A cards was added. Previous versions of PCMKINIT do not support these cards. Version 1.14 Added an option to bypass the Card Services resource tests on startup. This option should not be used unless absolutely necessary! Normally when PCMKINIT loads, it checks Card Services to make sure it has adequate resources to support the PCMK card. If it doesnt, it prints an informative error message and aborts loading. IBM Card Services, however, has a bug which causes it to always report that it has no resources, even if it does. This option was added to specifically address the IBM bug, and should probably only be used with IBM Card Services. To bypass the resource tests as described, add the B option to the command line. Version 1.13 Added a workaround for a bug located either in American Megatrends' Socket Services for Vadem chipsets (version 1.00) or in their Card Services 1.21A, as pre-installed on CTX brand laptop computers. This bug would prevent the PCMK from configuring when PCMKINIT was used with American Megatrends PCMCIA software. Note that users can download the latest American Megatrends software from their BBS at 770-246-8780. Version 1.12 Fixed PCMKINIT so that it won't load if CardWare 2.0's PCENABLE is already loaded. Version 1.11 Modified the driver to ignore a false locked configuration report which could occur on an IBM Thinkpad running CardWare. Other minor code cleanup. Version 1.10 Fixed a problem in the lock/unlock PCMK functions which could make a PCMK in socket 1 appear to not be configured after it is used once. If the PCMK was in a socket greater than 1, configuration info for socket 1 or greater would be corrupted. Version 1.09 Added a help screen at the request of Tim Boppre. This screen is displayed when an 'H' or '?' is present on the command line. Version 1.08

Added some more descriptive text to some of the more cryptic error messages. Added a message indicating that tone generation has been activated. Attempting to allocate IRQ 0 is no longer a fatal error; PCMKINIT simply refuses to give IRQ 0 to Card Services and moves on. A help message describing the use of the PCMKINIT command line is now printed if at least 4K of RAM has not been allocated to Card Services. This message describes how to get things running to a user who has everything loaded, but hasn't yet figured out how to allocate resources. Moved some transient data out of the resident data area to shrink the resident program size slightly. Changed the greeting message so that if PCMKINIT is already installed, both the current and installed version numbers are printed. This is for convenience during technical support calls. Version 1.07 Fixed a bug which would crash the system if sound was enabled but the client registration failed. Fixed a bug which would prevent the PCMK from successfully enabling if a free IRQ was not present (the PCMK should configure successfully without one.) This problem was observed with CardTalk, and may not have occurred with other PCMCIA system software. Version 1.06 Added tone generation for PCMK insertion and removal. This option is activated by including an "S" on the command line. Version 1.05 At the request of Allen-Bradley and Rockwell Software management, the name of the enabler has been changed to PCMKINIT. A check for the DOS version was added, since some new code requires a DOS version of at least 3.00. Copyright notice updated for 1995. The enabler is now capable of performing its own resource allocation, based on memory ranges and IRQs specified on the command line. Code was added to check for memory conflicts with EMS page frames. If such a conflict is detected, PCMKINIT will refuse to allocate that memory range to Card Services. Version 1.04 Fixed a bug which could prevent the interrupt on the PCMK from being used. Version 1.03 Fixed a bug which could hang the system if multiple clients were registered with Card Services before ICOMPCMK was loaded. Some additional protective code was also added to prevent the possibility of an infinite loop. Version 1.02 Fixed a stack problem which would cause a system crash if a card other than a PCMK

was removed while the system was running. Copyrights were changed from "ICOM, Inc." to "Rockwell Software Inc.". Version 1.01 Added a check for VMI/Award enabler, PCENABLE. Since this enabler can also configure the PCMK, there is no need to load if it is present. Upon detection, a message is printed and program loading aborts. Version 1.00 Initial release under the name ICOMPCMK.COM.

For Developers Only: The Interface to PCMKINIT


Currently, the specific enabler provides five functions: verify installation, return version and system information; return a list of PCMK cards in the system; lock a PCMK card for exclusive use; unlock a PCMK from exclusive use; return a list of RIO scanner capable cards in the system.

These functions are invoked by a DOS or Windows application through the DOS multiplex interrupt (int 2Fh.) In order to assure that it does not conflict with other TSRs or system drivers, values are placed in the AX, DX, and SI registers which uniquely identify the call as one for PCMKINIT.COM. Function 00H: CmdReturnVersion Applications should always call this function before any others to verify that PCMKINIT.COM is installed and of a sufficient version to support the application. In addition, information about the maximum number of sockets that PCMKINIT.COM is capable of supporting, and how many PCMCIA sockets are reported by Card Services is returned. The number of sockets reported may be used to limit user selections to a valid range of choices. Call with: AX = 0E99EH DX = 'IC' ; DX=4943h: 'I' in DH, 'C' in DL SI = 'OM' ; SI=4F4Dh BX = 0000H ; function number 0 CX = buffer size in bytes ES:DI = ptr to buffer AX = return code other registers preserved

Returns:

Registers AX, DX, and SI provide near-certain assurance that the call is intended for PCMKINIT.COM. Register BX is the function code for CmdReturnVersion. ES:DI should point to a buffer of at least 12 bytes in size, and CX should contain the size of that buffer. On return, if AX is zero, the buffer at ES:DI will be filled in as follows: word byte byte byte byte wVerLen bVerSig1 bVerSig2 bVerSig3 bVerSig4 ; ; ; ; ; length of this structure in bytes ASCII 'I' ASCII 'C' ASCII 'O' ASCII 'M'

word wVerVersion word wVerSockets word wVerCsSockets

; version of PCMKINIT.COM in BCD ; # of skts PCMKINIT.COM supports ; # of PCMCIA sockets in system

These fields will be guaranteed for future revisions of PCMKINIT.COM. If further information is needed to be returned in the future, the above structure will be appended to. AX will be non-zero (failure) if CX is less than 12. Function 01H: CmdReturnWhoPCMK This function is used to return a list of configured PCMK cards. For each card in the list, information is returned on the socket occupied, the segment address of the dual-port RAM, the IRQ assignment (if any), and whether or not another application is using the card exclusively. Call with: AX = 0E99EH DX = 'IC' ; DX=4943h; 'I' in DH, 'C' in DL SI = 'OM' ; SI=4F4Dh BX = 0001H ; function number 1 CX = buffer size in bytes ES:DI = ptr to buffer AX = return code other registers preserved

Returns:

Registers AX, DX, and SI are set up as in CmdReturnVersion. Register BX is the function code for CmdReturnWhoPCMK. ES:DI should point to a buffer at least 5 bytes in size, although to get information on specific cards this buffer should be much larger (currently the returned structure could be as large as 69 bytes; this could be larger in future versions.) CX should contain the size of the buffer passed in ES:DI. If AX is zero (success) on return, the buffer at ES:DI will be filled in with the following structure: word wWhoLen word wWhoSktOft byte bWhoPcmkQty ; length of entire response in bytes ; offset to following socket structure(s) ; number of socket structures to follow, if any

The above fields are guaranteed; future versions of PCMKINIT.COM may append to this structure, however, so wWhoSktOft should be used to determine the starting point of the following socket structures. These structures, beginning at ES:DI + wWhoSktOft, describe the PCMK at each socket, if any (bWhoPcmkQty will be zero if there are no PCMK cards installed in the system.) The number of socket structures to follow is in wWhoPcmkQty, and wWhoLen includes these following structures. Each of these structures is formatted as follows: word word word byte byte wSktLen wSktSocket wSktSegment bSktIrq bSktLock ; ; ; ; ; length of this substructure in bytes socket number this PCMK occupies (0=first) segment address of PCMK's dual-port RAM IRQ assigned to this PCMK card (0FFh=none) non-zero means PCMK is in use by another app

Again, these fields are guaranteed. Applications should be aware, however, that the size of this substructure may change in future revisions, and should use the wSktLen to index to the next substructure, rather than hardcoding its length.

Note that it is possible that a card may have been configured with no interrupt assigned (bSktIrq=0FFh.) This may occur because Card Services has no more IRQs available for assignment to PCMCIA cards. Applications may opt to use the PCMK in a "polled" mode of operation, or take other action as they see fit. This function only returns cards capable of supporting asynchronous communications (DH+, DH-485, and PLC-2 front-port protocols.) It will skip any 1784-PCMKS cards, which are only used for Remote I/O (RIO) scanning. This saves applications which use asynchronous communications from having to distinguish between a 1784-PCMK and a 1784-PCMKS on their own. To obtain a list of RIO scanner cards, see function 04H, CmdReturnWhoScanner. The Plug and Play driver for Windows 95 does not return the PCMK's physical segment address in wSktSegment. Instead, a virtual segment address specific to the caller's virtual machine is returned and may subsequently be used to access the PCMK's dual-port memory. While this does not impact any application code, you should be aware that the segment address returned may not be the PCMK's actual physical address. Function 02H: CmdLockPCMK This function sets a lock byte associated with the PCMK card in the given socket. This serves as an indicator to other applications that the PCMK card is in use. Note that there is no way to enforce this lock; other applications must respect it. If an application calls this function before using a PCMK card, it must call CmdUnlockPCMK when it has finished, or it may prevent other well-behaved applications from using the PCMK. Call with: AX = 0E99EH DX = 'IC' ; DX=4943h; 'I' in DH, 'C' in DL SI = 'OM' ; SI=4F4Dh BX = 0002H ; function number 2 CX = 0 ; no buffer, set length to zero DI = socket # ; socket # of PCMK (0=first socket) AX = return code other registers preserved

Returns:

This function will only fail (AX nonzero) if the socket number passed is invalid. The lock function may be called any number of times; a single CmdUnlockPCMK will unlock the PCMK and make it available for other applications. The CmdLockPCMK function must be called before attempting any memory access to the 1784-PCMK, including memory tests, etc. The Plug and Play driver for Windows 95 uses this function to cause the PCMK's physical memory to be mapped into the caller's virtual machine address space. Function 03H: CmdUnlockPCMK This function clears a lock byte associated with the PCMK in the given socket. After calling this function, applications which respect the lock are free to use the PCMK. A single call to CmdUnlockPCMK will release the lock, regardless of how many times CmdLockPCMK has been called. Note that since PCMKINIT.COM does not track which application asserted the lock, it is possible to unlock a PCMK which was locked by another application, thus creating the potential for conflicts. To avoid this, an application should never call CmdUnlockPCMK unless it has first asserted a lock with CmdLockPCMK. Call with: AX = 0E99EH DX = 'IC' SI = 'OM' ; DX=4943h; 'I' in DH, 'C' in DL ; SI=4F4Dh

Returns:

BX = 0003H ; function number 3 CX = 0 ; no buffer, set length to zero DI = socket # ; socket # of PCMK (0=first socket) AX = return code other registers preserved

This function only fails with AX nonzero if the socket number passed in DI is invalid. This function must be called after an application has made it's final memory access (read or write) to the 1784-PCMK dual-port. The Plug and Play driver for Windows 95 requires this call to make the 1784-PCMK available to other applications. If an application fails to make this call when it is finished, then the virtual machine that application is running in will own the 1784-PCMK until its virtual machine terminates (i.e., until the DOS box is closed.) Unlike PCMKINIT.COM, the Plug and Play driver can and does strictly enforce the locking and unlocking of PCMKs to prevent conflicts between applications. Function 04H: CmdReturnWhoScanner This function is used to return a list of configured Remote I/O (RIO) scanner capable cards, such as the 1784-PCMKS and the 1784-PCMK Series B. For each card in the list, information is returned on the socket occupied, the segment address of the dual-port RAM, the IRQ assignment (if any), and whether or not another application is using the card exclusively. Call with: AX = 0E99EH DX = 'IC' ; DX=4943h; 'I' in DH, 'C' in DL SI = 'OM' ; SI=4F4Dh BX = 0004H ; function number 4 CX = buffer size in bytes ES:DI = ptr to buffer AX = return code other registers preserved

Returns:

Other than the function code in BX and the fact that this function only returns information about RIO scanner cards, it is identical to function 01H, CmdReturnWhoPCMK. See that function for details about the data structures used and other information. This function will not return information about cards that do not support RIO Scanning, such as the 1784-PCMK Series A. This design frees applications using RIO from the task of determining whether or not a particular card supports it. To obtain information about cards supporting asynchronous communications (DH+ and the like), use function 01H, CmdReturnWhoPCMK. Due to the nature of RIO applications and the less-than-realtime response under Windows 3.1 and Windows 95, this function does not report any cards while running under Windows.

Вам также может понравиться