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.
|