Source: Under The Hood - The IBM PC BIOS (ABIOS pages only), BYTE, 1993-04.
Original HERE (pages 375-376 physical).
Author: Brett Glass
Converted to HTML by Louis Ohland. Edited by Major Tom.


The IBM PC BIOS is able, in many cases, to isolate programs that run in the "real" mode of the 8086 family of processors from the physical hardware-especially in certain areas such as disk I/O. However, it has few provisions for handling memory sizes greater than 1 megabyte and little support for the protected modes of the 80286 and 80386 processors. Thus, an environment that uses protected mode to multitask or to break the 640K-byte barrier on a standard AT compatible is forced to take one of two approaches: It can switch the processor back to real mode (slowly!) to use the IBM PC BIOS calls, or it can go directly to the hardware in protected mode, sacrificing the hardware independence provided by the BIOS.

To avoid this problem, IBM has come up with a new kind of BIOS: the Advanced BIOS, or ABIOS. (IBM sometimes calls the older, real-mode BIOS by the name CBIOS, or Compatibility BIOS, to distinguish it from the ABIOS.) ABIOS, which is currently implemented only on IBM's PS/2 series and compatibles, can be used by operating systems running in either real mode or protected mode-or by "bimodal" environments, like OS/2, that switch back and forth. ABIOS provides even greater isolation from the physical hardware than the original CBIOS and contains complete support for concurrent device access by many processes in a multitasking system.

Types of ABIOS Requests

ABIOS can support three types of requests made by an operating system or a user program: single-staged, discrete, multistaged, and continuous multistaged. Each type of request is diagrammed in figure 4.

Figure 4. ABIOS request types. A single-staged ABIOS request completes immediately before returning to the caller. A discrete multistaged request is processed in stages with delays between the stages; control is returned to the caller until a hardware interrupt signals that a stage has completed. A continuous multistaged request starts a process-sometimes called a daemon-that loops forever between one or more stages.

In a single-staged request, the ABIOS performs the requested function right away; it's done by the time the program regains control. A discrete multistaged request happens in two or more stages, with delays between the stages; the calling program regains control during the delays so that other processing can be done. A continuous multi staged request starts a staged operation that never ends

Calling ABIOS

The ABIOS calling conventions reflect the needs of protected-mode and bimodal operating systems. ABIOS, unlike CBIOS, is entered by far calls rather than by software interrupts and is completely reentrant even between modes. That is, a real-mode function X can be interrupted and a protected-mode function Y started, even if X is identical to Y.

BytesStack contents
2Common data area pointer (segment/selector only) — required.
4Request block pointer — required.
4Function transfer table pointer — furnished by ABIOS or caller.
4Device block pointer — furnished by ABIOS or caller.
4(Return address.)
Table 3. ABIOS stack frame and calling conventions.

When a program or operating system calls ABIOS, it must pass pointers to two structures: a request block and a common data area (see table 3). The request block specifies the function to be performed- just as the interrupt number, the AH register, and the other CPU registers tell the CBIOS what needs to be done. The common data area, ABIOS's "master switchboard," is a table that contains pointers to all of ABIOS' s other tables and data areas.

The internal data structures linked together by the common data area include function transfer tables-which, like CP/M's jump tables, list the addresses of routines that perform certain functions- and device blocks, which contain public and private information used by devices. The details of these complex structures can be found in IBM's Personal System/2 Seminar Proceedings (see bibliography).

When a program calls ABIOS, it must provide the segment or selector of the common data area and a pointer to a request block. Two other parameters may or may not be furnished by the caller, depending on the convention used. In the ABIOS Transfer Convention, ABIOS accepts just the addresses of the request block and the common data area and finds a function transfer table and a device block to use when handling the request. In the Operating System Transfer Convention, the caller furnishes the locations of these data structures. Note that since the parameters are not removed from the stack upon return to the caller, an operating system can save the function transfer table and device block addresses after they have been furnished by ABIOS during a call.

Interrupt Handling in ABIOS

Unlike CBIOS, ABIOS expects system devices to share interrupts. In a machine running under ABIOS, the operating system- not ABIOS-gets control when a hardware interrupt occurs. It is the responsibility of the operating system to call ABIOS to have the interrupt serviced, and the operating system must also issue the End of Interrupt command to the interrupt controller.

If more than one device is sharing a hardware interrupt, the operating system must invoke the ABIOS interrupt handling routine for each of these devices in turn. If the current interrupt does not affect a device, the operating system receives a return code from ABIOS that says, "This is not my interrupt; please try another device." The operating system continues to query devices until one responds to the interrupt request.

Future Compatibility

ABIOS is an important .step toward maintaining machine independence in the Intel protected-mode world. Unfortunately, the majority of PC compatibles available today-and likely to be available in the near future-do not have ABIOS, and users of multitasking operating systems such as OS/2 and Unix must buy machine-specific versions of the operating system and/or install device drivers to adapt the operating system to each machine.

There is no compelling technical reason, however, why ABIOS cannot be added to existing systems-as an add-in ROM or even as a TSR. (In fact, IBM has stated publicly that "ABIOS is contained in ROM but does not preclude a RAM implementation.") It is to be hoped that, in the long term, compatible manufacturers (and/or enterprising software designers) will provide ABIOS implementations for existing 80286 and 80386 machines. If this does happen, you can anticipate an even greater level of standardization and machine independence than that engendered by the original IBM PC BIOS.

In the meantime, the venerable IBM PC BIOS-now well understood and readily implemented- has fostered the development of a strong, consistent industry standard. While far from perfect, this standard will doubtless persist for another decade or more and will allow manufacturers to produce quality products at commodity prices. Hopefully, newer standards, such as ABIOS, will eventually replace the standard CBIOS as the basis for compatible machines with multitasking and more than 640K bytes of directly addressable memory. Only time will tell if these new standards will ever be as pervasive as the standard that lies at the heart of the IBM PC.

Content created and/or collected by:
Louis F. Ohland, Peter H. Wendt, David L. Beem, William R. Walsh, Tatsuo Sunagawa, Tomáš Slavotínek, Jim Shorney, Tim N. Clarke, Kevin Bowling, and many others.

Ardent Tool of Capitalism is maintained by Tomáš Slavotínek.
Last update: 08 May 2024 - Changelog | About | Legal & Contact