Author: Dan Rollins
Source: PC Tech Journal, vol 6, no 4, April 1988, pages 75-83

Say goodbye to DIP switches and jumpers—POS has arrived. Programmable option select, a feature of IBM’s Micro Channel architecture, configures add—in boards entirely through software.

Since the first IBM PC hit the shelves, DIP switches and jumpers have been the bane of PC professionals. With 16 switches on the system board and 16 or so on the adapter, there are billions of ways to go wrong. For example, if two serial adapters are both set to handle COM1, neither one will work. Any error in the settings can cause one card to conflict with other cards, and the problem can mean hours of poring over the documentation for the two adapters.

Refinements in technology have made it practical to use programmable registers to replace DIP switches and jumpers. In fact, when the difficulties in documentation and the necessary end user support are considered, it is probably cheaper to make the card programmable. On the PC/XT or PC/AT, a card with program—selectable switches must contain additional hardware, such as an EEPROM ‘or a battery-powered CMOS memory, to retain its settings.

With the introduction of the Personal System/2 models with the Micro Channel architecture and the programmable option select (POS) feature, IBM has made all of this switch-handling a thing of the past. Briefly stated, feature settings on each Micro Channel card must be fully programmable. When a new card is installed into a slot, users can be sure it will not interfere with other cards. When a conflict exists (for example, two cards that are programmed to use COM1), one card is disabled until the user can change its ”switches," which is done easily through a configuration program.

Furthermore, the card does not need to keep track of its own settings. The configuration program saves the user’s “switch settings” in a bank of battery-powered CMOS RAM on the PS/2 system board. The power-on sequence reads these data and uses them to program each card. Up to 4 bytes— the equivalent of 32 DIP switches—are sent to the card before any other access of the card.

It is up to the card manufacturer to decide the meanings of the POS bytes, but typical uses include the following: selecting the addresses of I/O ports; changing the addresses of any on-board ROM; and setting interrupt levels (IRQ), RAM addresses and options, direct memory access (DMA) arbitration type and level, and DMA burst length. In short, any option that used to be set by DIP switches and jumpers (in a painful session of manual labor) can now be selected through software.

POWER-ON SEQUENCE

The power—on sequence of the PS/2 is a superset of the sequence used in the PC/XT/AT class of machines. When the 80286 processor powers up, it starts executing instructions at absolute address FFFF0H. This address in the system ROM contains a jump to the power-on self test (POST) procedure elsewhere in ROM. First the POST thoroughly checks the CPU, interrupt controllers, and other devices. Next, it checks the CMOS RAM. If the battery is determined to be bad or the CMOS configuration data do not match the Cyclic redundancy check (CRC) validity check value, the PS/2 assumes a minimum configuration.

If the CMOS memory passes the tests, the POS sequence begins. Starting at slot 1, the POST program reads the ID of the adapter in that slot and compares it with the first of the list of IDs in the CMOS RAM. If the ID matches, the program switches the card into set-up mode, transfers up to four bytes from CMOS to the POS ports, and reenables the card for normal operation. It then moves to the next slot and continues until all adapters have been programmed. If the ID read from a slot is different than the ID recorded for that slot in CMOS, the system beeps twice, displays an error code on the screen, and writes the error code to the CMOS for subsequent use.

Power—on processing continues with the familiar ROM—scan sequence. Addresses between C800:0000H and D000:FFFFH are checked in increments of 2KB for the ROM signature of AA55H. If the signature is found, the block of ROM code is checked for a correct checksum and control is passed to the ROM to allow the adapter to further configure itself. For example, in the case of a hard disk adapter, further configuration might include hooking interrupt 15H and sending a reset command to the controller. Next, the memory and I/O ports are checked, and then the equipment list word that is returned by interrupt 11H and the configuration record for interrupt 15H are set accordingly.

If no configuration errors were recorded in CMOS RAM, the POST attempts to boot. The program first tries to boot from diskette drive A:—if unsuccessful, it tries the hard disk; finally, if still unsuccessful, the POST displays a diagram that prompts the user to insert a diskette and press F1.

If an error is found in CMOS RAM, the system will boot only if the reference diskette is in drive A:. Otherwise, the system just stops and waits for the user to press F1, without displaying any prompt other than the numeric error code. If it finds the reference diskette, the system boots up into a program that displays a screen that explains the possible causes of the error and gives you the choice of running the configuration program.

THE CONFIGURATION UTILITY

The Micro Channel hardware does not contain something that magically prevents conflicts in addressing I/O ports, memory, or interrupt levels. Instead, IBM created a clever piece of software, the System Configuration utility (SC.EXE on the PS/2 reference diskette) and established a set of rules that, if followed by card manufacturers and system integrators, can avert these conflicts.

The SC utility performs the initial “setting of switches” on each adapter, either automatically or in response to user input. It can detect and prevent option conflicts because it operates on the adapters while they are installed in the system; all settings on all boards are known. It also provides a user~friendly face on rather complex activities, such as helping a naive user select an IRQ or a DMA arbitration level. For users who have wrestled with the AT’s primitive SETUP program, the PS/2’s SC is a real joy, offering pop-up windows, menu—driven screens, and on—line help.

SC presents available options and provides help at each step. Any potential conflicts are flagged, and clear instructions and explanations are provided. As is explained later, the automatic configuration option resolves most conflicts without the user having to make any decisions.

If IBM had tailored the SC utility for installing only IBM cards, the company would have done a disservice to its users. Instead, IBM provided a well defined, well-documented method for letting third—party card manufacturers take advantage of the POS capabilities. Each adapter can have an adapter description file (ADF). This is a text file containing information that SC needs about the adapter, including its name, its adapter ID, all of its programmable options—interrupts, I/O ports, ROM and RAM addressing, DMA arbitration level—and the bit patterns that select each option.

The ADF has two purposes. First, it specifies a list of resource options; the user (or the SC program, in autoconfigure mode) can choose options from the list to avoid collisions with other adapters. Second, it provides a user friendly interface for changing configuration options. Each ADF can contain as much or as little hand—holding as required, including context-sensitive help screens that are displayed when the user presses F1. For example, the ADF for the IBM Multi—Protocol Communications Adapter contains more than 2KB of information. After being processed with SC, however, this entire text file is boiled down to four (or fewer) bytes of POS data that will be saved in CMOS memory and sent to the card during power—on.

ADFs are named @xxxxADF; the W is replaced by the adapter ID‘s four hexadecimal digits. The SC program reads and processes these files when it finds an adapter with a corresponding ID number. The ADF text has a rigid format, a sort of interpretive language understood by SC. This language contains key words and string and numeric data elements. Tabs, spaces, and new—line characters are treated as delimiters, except in quoted strings. ADFs can be one long line or a set of lines, indented and easy to read. The ADF example in Figure 1 illustrates the most important aspects of ADF syntax. This ADF contains configuration data for the mythical Gizmo Adapter.

Figure 1: An ADF Example

Any line beginning with a semicolon, like the first one in the example, is a comment and is ignored by the ADF interpreter. The second line contains the required key word, AdapterID, followed by the four-digit adapter identifier. Key words can be written in any combination of upper- and lowercase letters; numeric values can be written in decimal or hexadecimal (hexadecimal values in ADFs must include an H or h after the value itself).

The next line contains the key word, AdapterName, followed by a quoted string of text. This text is informational only; SC displays it in the Change Configuration window next to the slot number in which the adapter was found. The NumBytes key word in the next line indicates how many bytes of POS data will be sent during POS programming. The FixedResources key word specifies those resources (addresses, I/O ports) whose locations cannot be changed. Resource key words are 10, MEM, INT, and ARB.

IO specifies one or more ranges of I/O port addresses. MEM indicates one or more ranges of memory addresses for either ROM or RAM. INT specifies one or more hardware interrupts used by the card. ARB selects a DMA arbitration level. DMA arbitration is a Micro Channel feature that helps hardware avoid DMA overruns and collisions. The card does not need to support DMA arbitration, but if it does, the configuration program should know so that it can ensure that only one card uses a particular setting.

Each programmable feature of the adapter has a NamedItem section consisting of a prompt that names the option and one or more choice values through which the user can scroll by pressing F5 and F6 together. Each choice has a name (a quote-enclosed string), a bitmap indicating the pattern of “switches” that implement that choice, and a list of resources. As the user scrolls through the choices, the SC program compares the resources used by each choice with those for all other choices in the system; if any conflict exists, it displays an asterisk (*).

The FixedResources section and each choice line require a pos key word that specifies settings in one of the four configuration bytes (numbered pos [0] through pos [5] ). Each POS byte can be thought of as a bank of eight DIP switches. A 1 means turn that “switch” on, 0 means turn it off, and X means leave it unchanged.

The first NamedItem in the listing has four choices: COM1, COM2, COM3, and Disabled. Here, bits 1 and 2 of POS byte 0 select the I/O port used by the adapter. Thus, each choice has a different setting for these two bits, and all other bits are marked with Xs. Other options modify the other bits of this byte; the result is cumulative.

Bit 0 of the pos [0] byte is always an X. Because this bit is used to enable and disable a card, it cannot be used to select adapter features.

Finally, each NamedItem must have an associated help message. The help key word is followed by a quoted string displayed when the user presses F1 while the cursor is within the NamedItem. The SC program ignores carriage returns and performs word wrap to make the message fit in the help window. If the message is large, the arrow keys and PgDn and PgUp can be used to scroll through the text.

To help nontechnical users, the SC program has an automatic configuration mode that selects from the choices for each adapter without requiring any user interaction. In this mode, SC scans the expansion slots in numeric order. For each NamedItem, it attempts to pick the first choice; if that choice causes a resource collision with a card in a lower-numbered slot, automatic configuration tries each subsequent choice. If a nonconflicting choice is not found, SC disables the adapter.

The automatic configuration algorithm is relatively simple; if it cannot resolve a conflict, it does not attempt to backtrack and look for alternative ways to configure other cards. For example, if slot 0 holds an adapter that has a choice of I/O ports 3F8H or 2F8H (in that order), SC takes the first choice and sets the adapter for I/O address 3F8H. If slot 1 holds an adapter that has a fixed requirement for I/O port 3F8H, that adapter will be disabled, because its resources are unavailable. SC does not go back to reconfigure slot 0 for port 2F8H.

The result of automatic configuration depends on the order of choices in the ADF and the order of the adapters in the slots. The conflict described above would not occur if the ADF for the adapter in slot 0 listed the choices in reverse order, or if the two adapters were switched so that the one with the fixed resource requirements were configured first. Although users would not ordinarily change the order of choices in an ADF, they could resolve many conflicts simply by swapping the positions of the two cards. The most configurable adapters should be placed in the higher-numbered slots. At the end of configuration, whether manual or automatic, SC writes the selected choices to the CMOS RAM, but not to the adapter. Then it reboots the system, and the power-on sequence writes the configuration data to the adapter.

POS DETAILS

Table 1: I/OPorts in POS Programming

During the POS process, the POST routines communicate with the adapter by means of the I/O ports listed in Table 1.

Table 2: Adapter Set-up  

The program selects a slot by writing a value to port 96H as shown in Table 2. The slot number is encoded in three bits, meaning that the Micro Channel is limited to eight expansion slots. Once the slot is selected, the program can read the adapter’s identification number from ports 100H and 101H. To conform to the Micro Channel standard, the adapter card must provide its identification number in these ports when the card is selected via port 96H. To minimize hardware on the adapters, the system board provides logic to set all undriven bits of these ports to 1. The ID read from an empty slot has the value FFFFH. Adapters need only supply logic to drive the 0 bits of the ID numbers Not surprisingly, because IBM invented the game and sets the rules, it has reserved for itself the high—numbered adapter IDs.

On each card, ports 102H—107H should contain the latches that are programmed by the POS code. Port 102H receives the bit settings specified in the ADF for pos [0], 103H the bits for pos[1] and so on. Note that the numbering of POS ports Within the ADF differs from that used in the PS/2 Technical Reference (see Table 1), in which POS register 0 refers to port 100H.

The number and usage of the configuration bits are up to the manufacturer of the adapter. Only one bit is actually required: bit 0 of the pos [0] byte (port 102H), which is a master enable switch. If this bit is set to 0, the card must logically remove itself from the bus. When disabled, the card must remove any RAM and ROM from the system address space; it must not raise any hardware interrupts, perform DMA or other memory operations, nor respond to any I/O activity (except for accepting POS programming). In other words, the card must behave as if it were not installed. Thus, the Micro Channel integrity is a cooperative effort; if a card manufacturer chooses to ignore the built-in safeguards, it can easily cause the same problems that occur with PC/XT/AT adapters.

Bits 6 and 7 of the pos [3] byte (port 105H) have a predefined significance, but their use is optional. In a memory failure or other significant error, a card may assert a signal that forces a nonmaskable interrupt (NMI). This was also true on the PC and AT bus, but the computer could not tell which card forced the NMI.

On the Micro Channel, the NMI handler can query each slot position and examine bits 6 and 7 of port 105H. A card can use bits 6 and 7 to identify itself as the source of the interrupt and to indicate whether or not additional diagnostic information is available at ports 106H and 107H. Because the PS/2 Technical Reference does not document what the standard channel—check NMI handler does, it is reasonable to assume that a card manufacturer must provide a custom NMI handler, possibly in an on—board ROM.

The other POS data can be in any format. Just as each PC and AT card manufacturer uses its own set of switches and jumpers, the bits of the bytes sent to ports 102H—105H can be  assigned to mean anything and can be programmed in any order. If a card has few options, it can simply ignore any data sent to unneeded ports.

Ports 106H and 107H, called the subaddress extension ports, provide a means of writing more than four bytes of data to the adapter. The POS programming that takes place during power up does not send data to these ports; however, a software device driver or initialization code in ROM can use them to communicate with an adapter. For example, the IBM PS/2 Memory Expansion Option uses these ports to write up to 1,024 bytes of data into its translator RAM to specify the starting address of each 16KB block of memory. Like the other POS ports, 106H and 107H are decoded by a card only when its slot has been selected for set-up via port 96H.

Figure 2: System Board Enable/Set-up

The PS/2 system board I/O devices can be programmed via the POS ports in a similar manner. Instead of using port 96H to select a slot, an OUT to 94H selects either the VGA or the other system board devices for POS set—up, as shown in Figure 2. These devices are controlled by setting bits in port 102H (see figure 2). Note that this port does double duty, programming either adapters in expansion slots or devices on the system board, depending on the bit settings in port 94H and 96H.

Each of the system-board devices (VGA, serial port, parallel port, diskette drive controller) can be disabled, which allows their functions to be performed by adapters in expansion slots. In addition, the serial port can be configured as COM1 or COM2, and the parallel port can be configured as LPT1 through LPT3 and as either output—only or bidirectional.

POS PROGRAMMING

The PS/2 Technical Reference sternly warns against setting POS options outside the configuration program, threatening that damage to system hardware may result. It further recommends that application software not examine adapter ID numbers as a way to identify system hardware. The same documentation then goes on to supply detailed instructions for doing both.

In reality, there is little reason to manipulate the POS settings. Once configured, a card might not expect to be reconfigured (imagine flipping DIP switches with the computer on). Of course, reprogramming RAM or ROM addresses or changing I/O port usage without a subsequent reboot might result in an unstable system. However, it might be desirable to reprogram an adapter on the fly. A fault—tolerant system may have two identical adapters, one of which is disabled. If the active adapter fails, it could be disabled and the backup could be enabled.

POS programming of adapter cards

For programmers who might like to experiment with POS programming of adapter cards, the steps for doing so are as follows:

1. Disable interrupts (CLI).

2. Do an OUT to port 96H, selecting the desired slot.

3. Read the adapter ID from ports 100H and 101H.

4. If this is the adapter of interest, place it into setup mode by writing a 0 to bit 0 of port 102H.

5. Write POS data to ports 103H to 105H in any order.

6. Write port 102H as the final POS byte. Bit 0 of this byte must be a 1 to reenable the card.

7. Turn off the set-up mode by writing a 0 to port 96H.

8. Enable interrupts (STI).

Although the POS registers are sequential, making them candidates for 16-bit I/O operations, the documentation warns specifically that they work with 8-bit I/O only.

Figure 3: The Set-up Register

POS programming of system board

Programming the system board options is simpler than programming adapter card options. The steps for doing so are listed below:

1. Disable interrupts.

2. Write to port 94H with bit 5 = 0 (VGA set-up) or bit 7 = 0 (other system board device set—up). Set all other bits of the output byte to 1.

3. Write one byte of data to port 102H to configure the devices as specified in Figure 3.

4. Turn off setup mode and reenable all system board features by sending FFH to port 94H.

5. Enable interrupts.

It is possible to read as well as write to the POS bytes for the system board and all adapter cards. In programming the system board features, it is a good practice to read the current state and then modify only those bits that should be affected. To read the configuration of an adapter card, put the card into set—up mode by sending its slot value to port 96H, then perform the IN operations from ports 100H—107H, and get out of set—up mode by sending a 0 to port 96H.

Although IBM warns against reading card IDs indiscriminately, some system-level programs must know which adapter is present to work correctly. For example, an installable device driver may need to know if a certain adapter is installed and if it has been configured in a specific way.

For an example of reading the POS ports, see Listing 1 (POS_READ.C). This program checks each slot, looking for an IBM Multi-Protocol Communications Adapter/A (with the adapter ID DEFFH). For each such card it finds, the program then checks the POS bytes to see if the card is enabled for bisynchronous communications and, if so, which ports it uses. Note that the programs main loop checks all eight slots. On a four—slot Model 50, slots 5—8 appear the same as empty slots, the adapter ID is FFFFH, and all POS bytes are read as FFH.

Listing 1: POS_READ.C 

POS_READ.C simply displays messages about What it finds. A real bisynchronous communications tool could use these data to make decisions; if the adapter is not present or is configured improperly, the program could abort, displaying instructions on how to configure the card correctly.

It is easy to see why IBM warns against card—specific activity. To obtain usable information from the POS settings, the program must know the exact meaning of each POS bit. A functionally equivalent card also could have a different card ID or, even worse, a third-party card could have a particular ID but a slightly different POS-byte bitmap (this has already happened with third party Micro Channel memory cards). A program should test for functional compatibility without relying on specific card IDs or POS settings.

CMOS MEMORY USAGE

Like the AT’s system board, the PS/2’s board contains a battery-powered, real time clock and 64 bytes of CMOS memory. This RT/CMOS memory contains current time of day, hard-disk type, amount of memory on the system, and other configuration data.

On the Models 60 and 80, an additional 2KB of CMOS memory holds the POS set—up information. The data needed by the power—on POS activity consist of 6 bytes per slot—a 2—byte adapter ID and 4 bytes of configuration data. These computers have eight slots, requiring a total of 48 bytes of POS data. Layout of the extra CMOS space is not documented.

The Model 50, on the other hand, has only four slots, so it needs only 24 bytes of POS data for the slots. The AT—style 64-byte CMOS has just barely enough reserved space to hold the POS data and the keyboard password without causing any major rearrangement of other fields.

Table 3: RT/CMOS Usage on the PS/2 Model 50

Table 3 shows the layout for the CMOS RAM for the Model 50. The major changes from the layout for the AT include those listed below:

* The diagnostics byte includes information that is specific to the PS/2, including errors occurring during POS programming.

* A full byte identifies each hard disks drive type. The AT used one nibble and a convoluted technique for recording disk types higher than 14. The PS/2 ROM BIOS supports 32 hard-disk types.

* The diskette drive—type field defines 720KB and 1.44MB drives.

* The hardware configuration record is extended to include 10H through 51H, and the checksum validity check is replaced with a CRC. The CRC value is stored at 32H and 33H.

* The 25 bytes between 19H and 31H are still marked in the documentation as reserved, but they are part of the POS system for the PS/2 Model 50. The first 24 are the six bytes for each of the four slots. Address 31H contains the configuration information for the system board.

* Addresses 38H—3FH contain the keyboard scan codes of the power-on password. These addresses are peculiar, because they are always read as FFH, having been ”locked” mysteriously during the POST. It is possible to outsmart IBM and read the password by adding 40H to each address, that is, reading from addresses 78H through 7FH. The moral is: Do not think of the keyboard password as a high—security measure for preventing unauthorized system access.

To read or write to the RT/CMOS, send the desired address to port 70H and do an IN or OUT to port 71H. If any configuration bytes (10H—31H) are modified, the invalid CRC will cause problems in the next boot-up, requiring the user to run configuration utilities from the reference diskette.

If a program needs to modify the configuration record bytes, it must calculate the CRC and place it in CMOS addresses 32H (high byte) and 33H (low byte). A CRC is far more reliable than a simple checksum; compensating errors, such as swapping the positions of two bytes, are flagged as errors. IBM’s CRC generation technique is not documented, but was discovered after a little investigation. A Turbo C version of the CRC generation routine used in the configuration utilities is reproduced in listing 2 (CMOS.C).

Listing 2 CMOS.C

AN APPEALING PS/2 FEATURE

Programmable option select is just one of many ingenious and convenient features of the new PS/2 architecture, appealing to both the average user who installs a new card once a year and the PC professional whose system unit is laid bare more often than it is closed. For the former, it virtually eliminates the process of finding and deciphering installation manuals; for the latter, it saves time and ensures functionality. As users become more familiar with PS/2s, using such features as POS, they undoubtedly will feel an increasing respect and admiration for IBM’s work on these new machines.

Dan Rollins is a freelance technical writer. He is the author of the "Help!” series, published by Flambeaux Software. His most recent work, the Norton Online Guide to OS/2, was published in January 1988 by Peter Norton Computing Inc.