Source: Personal Systems Magazine, January, 1993 (G325-5020-00).
Original HERE (Pages 97-101 physical)
Author: Richard Bealkowski, IBM Corporation Boca Raton, Florida
Converted to HTML by Louis Ohland. Edited by Major Tom.
IBM is changing the way it distributes the Advanced Basic
Input/Output System (ABIOS) on PS/2s. New IBM PS/2s, such as the IBM
PS/2 Model 9557, support the ABIOS that is available on diskette or
factory-loaded on the machine's hard disk. This article introduces the
concept of a loadable ABIOS, explains why the change was made, and
discusses its impact on users.
Applications and the operating system go through Basic Input/Output System
(BIOS) routines to access devices on a personal computer. In most cases, only
the operating system interfaces directly with the BIOS. Most applications call
the operating system to perform these functions, although a few special-purpose
applications bypass the operating system interface and call the BIOS
When OS/2 was introduced, IBM began supplying an ABIOS containing functions
previously not available in the PC BIOS. To maintain compatibility with other
programs, the original PC BIOS - renamed Compatibility Basic Input/Output System
(CBIOS) - is also included with the PS/2. Until recently, ABIOS was part of the
resident PS/2 firmware. Firmware refers to programs that are typically
stored in a nonvolatile memory device, such as Read-Only Memory (ROM). PS/2
firmware includes a Power-On Self Test (POST) in addition to the CBIOS and
Over time, all IBM PS/2s that support ABIOS will use a diskette-based ABIOS
instead of a firmware-based ABIOS, making it easier to maintain and update.
Once loaded, ABIOS is compatible with resident ABIOS. Software that uses ABIOS
directly, however, may require changes in the initial installation procedure.
DOS is not affected because it does not use ABIOS, but DOS applications can
access it. The installation routines of OS/2 2.0 do not support a loadable
ABIOS, but future releases will. In the meantime, PS/2s with a loadable ABIOS
are pre-loaded with OS/2.
ABIOS has a device-level Application Programming Interface (API). ABIOS can
operate in real mode, in protected mode, or in a bimodal environment using both
real and protected modes. ABIOS is described thoroughly in the IBM
Personal System/2 and Personal Computer BIOS Interface Technical Reference
Resident ABIOS comes in three main types: system firmware, adapter firmware,
and RAM extensions. Resident ABIOS occupies a substantial amount of memory in
the adapter (feature) space and in the system firmware space. The adapter
address space is the C000h (hex) and D000h segments. The system firmware address
space is the E000h and F000h segments. Adapter address space and system firmware
address space provide space for firmware, device buffers, and Expanded Memory
Specification (EMS) buffers. The available space within both the system
firmware and adapter address spaces has become very limited. Some systems may
not have any available space. To solve this problem, the resident ABIOS has been
packaged as a separate program. Adapter ABIOSs also can be packaged as separate
Initialization of the resident ABIOS occurs in three phases. Phase one is the
initialization of the system ABIOS. Phase two is the initialization of the
adapter ABIOS. Phase three is the initialization of ABIOS RAM extensions such as
patches. Two CBIOS calls, INT 15h AH=04 ("Build System Parameters Table") and
INT 15h AH=05 ("Build Initialization Table") are needed to initialize ABIOS.
Once an initialization call is invoked, the ABIOS coordinates the initialization
not only of itself, but of the adapter and RAM extension code as well.
The separate ABIOS programs must first be loaded into system RAM by the
operating system or special purpose application before they can be accessed.
These now-separate ABIOS programs are loadable ABIOS. Adapters that store
their ABIOS in 16-bit ROM may perform better when the ABIOS is then run from
32-bit system RAM.
The loadable ABIOS architecture is based on the existing RAM-Extension
Structure described in the IBM Personal System/2 and Personal Computer BIOS
Interface Technical Reference. For example, an ABIOS patch adheres to the
RAM Extension Structure architecture. Before software, such as an operating
system, initializes ABIOS through the CBIOS calls (INT 15h AH=04 and INT 15h
AH=05), it must load all RAM extensions into memory and set the DS register to
point to the beginning of the RAM extensions. Even if no RAM extensions
(patches) are required, DS must still be properly set and must point to a valid,
zero-length ABIOS RAM extension. No changes are required to the runtime portion
of software that adheres to the RAM Extension Structure section of the ABIOS
IBM's loadable ABIOS is shipped with the PS/2 reference programs. Initially,
the reference programs can reside on the Reference Partition of the hard disk or
on the Reference Diskette. If the diskette version is not available, it must be
created because the hard disk version is not available during normal
The Backup feature of the Reference Partition is used to create the Reference
Diskette. This diskette-based version of the reference programs contains the
loadable ABIOS that is used during installation of the operating system or
special-purpose application. For systems that support only a preloaded operating
system, the user may never encounter the requirement for a Reference Diskette.
Systems that are user-installed and require ABIOS, however, will require the
Figure 1: ABIOS RAM Extension Header
Every loadable ABIOS module is required to have a valid RAM extension header,
which is an extension of the existing RAM extension header architecture. Figure
1 shows the fields of the RAM extension header. The last four entries have been
added since the initial release of resident ABIOS.
The new fields in the RAM extension header are as follows:
0Eh Extension Header Length (in bytes). This word value
indicates the number of bytes in the extended header. A value of zero
indicates there is no extension to the header.
10h Support Determination Routine Offset. This routine
returns a zero value when this RAM extension does not apply to
this computer system. When it does apply, this routine returns the
actual ABIOS module length in bytes. This routine should be called
during the loading of RAM extensions. Only RAM extensions that return a
nonzero value should be allowed to remain in memory.
12h Length (in bytes) of this RAM extension without any fill.
This is the actual length of the RAM extension, and does not include any pad
that may have been added to raise the module size to the nearest 512-byte
14h Initialization Routine Offset. This routine is called by the
CBIOS INT 15h AH=04 and INT 15h AH=05 code, and is the ABIOS initialization
Wild Card Values
The model, submodel, and revision level values stored in the ABIOS
RAM extension header can be specific values or wild card values. A wild
card entry is specified by the value zero. Any or all of the model,
submodel, and revision fields can be set to the wild card value. When
comparing the computer system's model, submodel, and revision fields
with those found in the ABIOS module header, a wild card value indicates
an automatic match of that field.
Support Determination Routine
Figure 2: Support Determination Routine Parameters
1All other registers preserved
This real-mode-only routine should be called only if the extended
header length includes the support determination routine entry, and the
entry is nonzero. Figure 2 shows the parameters of the support
The entry parameters of model, submodel, and revision level should be
those of the current system. These values can be obtained from CBIOS
through the INT 15h AH=C0h call.
The support determination routine finds out if particular ABIOS RAM
extensions apply to the computer system. Typically, the RAM extension
header contains wild card entries for model, submodel, and revision
level values. The support determination routine should be called
immediately after the RAM extension has been loaded into memory. If the
support determination routine returns a length of zero, then the RAM
extension does not apply to the current system. If the support
determination routine returns a nonzero length, the RAM extension does
apply to the current system.
The size (length) of an ABIOS RAM extension must be an even multiple
of 512. The ABIOS initialization program uses the length value (in
512-byte blocks) at offset +02h in the RAM extension header to calculate
the beginning address of the next RAM extension header.
When the last RAM extension loaded does not apply to the system, the
RAM extension should be invalidated or otherwise cleared from memory.
This prevents the ABIOS initialization routine from locating and
initializing a RAM extension that is not applicable to the system. One
method to invalidate a RAM extension is to zero out the signature in the
RAM extension header.
Figure 3: Updating the ABIOS RAM Extension Header
The support determination routine is normally required only during
initialization. It may be possible to compact an ABIOS RAM extension
before the next ABIOS RAM extension is loaded. After the support
determination routine is called, the ABIOS RAM extension header can be
updated as shown in Figure 3.
When altering an entry in the extended portion of the RAM extension
header (beyond +0Eh), the extension header length ( +0Eh) must be
The check must be performed to ensure that the header includes the
To use ABIOS, the software should first perform a presence detect
to determine what type (if any) of ABIOS support is provided. ABIOS
presence detect consists of several individual tests performed in a
predetermined sequence. No individual test is definitive. The test
sequence must be performed to determine whether ABIOS is supported, and
if it is, what type of ABIOS is present. The software must support
incorporating the loadable ABIOS files as part of its installation
process. The runtime operation of the software must be consistent with
the established ABIOS architecture.
Build System Parameters Table
Build System Parameters Table is the CBIOS INT 15h AH=04 function call
- one of the two CBIOS calls used to initialize ABIOS. It has been
discovered that certain software may issue this call as a presence test
for ABIOS, only to perform the call later during actual initialization.
If this call is made before loadable ABIOS is loaded, this call will not
succeed, thus giving the impression that ABIOS is not supported.
ABIOS Attribute Field
Figure 4: System Configuration Table
This field is returned as part of the Return System Configuration
Parameters function, INT 15h AH=C0h. All Micro Channel-based PS/2s
support the Return System Configuration Parameters function, but not all
support the bit settings of the ABIOS Attribute Field. The register pair
ES:BX points to a table in memory that has the structure shown in Figure
4. The ABIOS Attribute Field is defined as bits 5-3 of Byte_4 in Figure
Figure 5: ABIOS Type Information
1Values of 100 through 111 are reserved.
The length field must be checked to determine if the table includes
Byte_4. If Byte_4 is a valid table entry, then the contents of bits 5-3
of Byte_4 can be used to determine the status shown in Figure 5.
Loadable ABIOS Signature
The ABIOS signature byte is a loadable ABIOS presence test method that
supports retrofitting loadable ABIOS into existing resident ABIOS
systems. For example, it may be desirable to install a new disk
controller into an existing resident ABIOS system; however, the new disk
controller requires loadable ABIOS. To indicate this to software such as
an operating system, an indicator is stored in system NVRAM location
202h. If a loadable ABIOS is required, this byte is set to A1h. If
loadable ABIOS is not required, the byte is set to something other than
A1h (preferably 00h). An Adapter Description Program (ADP) that ships
with a system or an option that requires loadable ABIOS must program
this byte accordingly. Note that both systems and options (adapters)
must support the loadable ABIOS signature byte.
Loadable ABIOS Signature Interface
A CBIOS function call, INT 15h AH=A0h, can be used to obtain the ABIOS
signature byte. If this call returns successfully, it provides the ABIOS
signature byte. If this call does not complete successfully, NVRAM must
be accessed directly. This call can also be used in systems where NVRAM
does not exist, or in systems where NVRAM location 202h is unavailable,
because the call masks the actual means used to store the ABIOS
Figure 6: ABIOS Signature Byte Interface
The interface specification for the ABIOS signature byte interface is
shown in Figure 6.
Figure 7: Detection Algorithm
Figure 7 shows how to determine the level of ABIOS support present in
a system. In Figure 7, No ABIOS indicates that the system does
not support ABIOS; Resident ABIOS indicates that ABIOS is
supported and that no loadable ABIOS files are required; and Loadable
ABIOS indicates that at least one loadable ABIOS file is required
(and resident ABIOS may also be present).
The Reference Diskette contains one or more loadable ABIOS files, an
ABIOS.SYS file, and one or more Device Driver Profile (.DDP) files.
The loadable ABIOS files have an extension of .BIO. The ABIOS.SYS file
lists all the .BIO files that may be required for the system. The .DDP
file is a list of required .BIO files in the DDP format. The .DDP file
can be used as a control file to drive the installation of loadable
ABIOS. For example, the OS/2 program DDINSTAL.EXE operates using .DDP
The order in which the .BIO files appear in ABIOS.SYS and the .DDP
file is important. The files that contain an initialization routine must
precede all other files in the list. The initialization routine scans
forward in memory for other ABIOS modules, so it must come before any
other .BIO files.
Software (such as an operating system) that is preloaded or
preconfigured on a computer system may not have to involve the user in
the loadable ABIOS installation process. However, during a user-based
installation, software that uses ABIOS must take an additional step to
load ABIOS. If loadable ABIOS is detected, there must be a prompt for
the ABIOS source diskette (the Reference Diskette), and the ABIOS must
The runtime operation of operating system or special-purpose software
should be identical for both loadable and resident ABIOS. There are some
considerations that will help ensure this:
- Support the RAM-Extension Structure architecture.
- Do not assume ABIOS resides at any particular physical address (that is, in
the E000h segment).
- Allow for adequate RAM extension space.
- Allow for more than one RAM extension per system.
Users of PS/2s with loadable ABIOSs must be sure that the version of
OS/2 install supports loadable ABIOS. If it does not, contact your
dealer. Users of custom applications that access ABIOS directly should
also ensure that the install portion of the application supports
Richard Bealkowski is an advisory engineer in Engineering Software,
Entry Systems Technology Laboratory, Boca Raton, Florida. Since joining
IBM in 1982, he has developed firmware for IBM personal computers and PS/2
Richard has achieved the Tenth Level Invention Plateau. He also is the
recipient of an Outstanding Innovation Award and an Entry Systems Division
Excellence Award. At Florida Atlantic University, he earned a BS in mathematics,
MS in computer science, and PhD in computer engineering.