|
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.
ABIOS
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.
| Bytes | Stack contents |
|---|
| 2 | Common data area pointer (segment/selector only) — required. |
| 4 | Request block pointer — required. |
| 4 | Function transfer table pointer — furnished by ABIOS or caller. |
| 4 | Device 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.
|