Ardent Tool of Capitalism

Loadable ABIOS

Source: Personal Systems Magazine, Jan 1993. 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 directly.

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

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 (S04G-3283).

Resident ABIOS

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

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.

Loadable ABIOS

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

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

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

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

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

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

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

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.

Compaction

Header.02h = CL    ; new 512-byte block count
Header.12h = AX    ; new length without fill
Header.l0h = 0     ; support determination routine disabled

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

The check must be performed to ensure that the header includes the target field.

Implementation

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

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

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

The interface specification for the ABIOS signature byte interface is shown in Figure 6.

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

Installation

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

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

Developer Considerations

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.

User Considerations

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

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

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.