The First 30 Seconds

What is the POST?

Author: Terry Jefferson - Wichita, Kansas
Source: THE FIRST 30 SECONDS PC Magazine, 13 Feb 1990, Vol 9, no. 3

What is the POST? Exactly what does the PC do from the time you turn on the power switch until the DOS prompt appears?

Our reader asks a simple question, but the answer is rather lengthy. POST stands for power-on self-test. It's a set of diagnostic routines encoded in ROM that serves as your computer's first line of defense against unwanted gremlins; it also ensures that the hardware you entrust your data to has been checked and certified ready to go each time you power it up.

When you turn on your PC and see an error message indicating that a RAM chip has gone bad, that message is an outward sign that one of the POST's diagnostic routines failed. The POST validates every byte of memory in your system at startup with a series of read/write tests designed to ferret out bad RAM locations. When it finds one, it reports the problem—before you have a chance to lose data.

But testing RAM is only one of the POST's many responsibilities. Besides running reliability tests on your system board components, it configures the various support chips that work with the microprocessor, determines what optional equipment is attached, gives adapters the chance to initialize themselves, sets up the interrupt vector table in low memory, gets the keyboard ready to transmit keystrokes to the CPU, and invokes the bootstrap loader, which in turn loads the operating system. After this final step, you see the first evidence that the PC is up and running— the command-line prompt under DOS and the window-based Presentation Manager in OS/2.

To better understand this process, we'll trace the startup sequence followed by the original IBM PC, then double back to highlight the differences between its POST and the POSTs for the AT and PS/2. The complexity of the startup ROM has grown as hardware has evolved, but the same theme and general order of operations has been carried through from the very first PC to the most recent. Figure 1 is a general sketch of the various parts of a typical computer; it generally applies to both AT and Micro Channel computers.

Figure 1: By testing the primary system board components (the CPU, DMA controllers, and interrupt the POST ensures that the system is working properly at the lowest levels.

The very first CPU-related event that takes place when power is applied to the microprocessor is execution of the instruction at address FFFFh:0000h. In the IBM PC, this instruction is a far jump to the beginning of the POST encoded in ROM in the upper 8K of segment F000h.

The startup ROM begins by exercising the CPU and trapping any errors or inconsistent handling of instructions. Six of the nine status flags—CF, ZF, SF, AF, OF, and PF—are individually set or cleared and tested with relative jump instructions whose destination (if the test fails) is an HLT instruction that simply halts the microprocessor. Each of the CPU's registers (with the exception of CS and IP, which are implicitly tested by the very execution of the routine) is written and read to verify that it is capable of handling data.

After verifying that the ROM containing the BIOS and startup code is intact, which it does by employing a checksum procedure, the POST turns to the 8253 timer chip. The 8253 provides three multipurpose counter/timers for accurate timing of events under software control. Timer 0 is wired into the CPU through the 8259A programmable interrupt controller to generate timer interrupts at a frequency of roughly 18.2 times per second. Timer 1 is used to trigger dummy DMA (Direct Memory Access) transfer requests for periodic RAM refresh. Timer 2 is available for tone generation in the speaker and other multipurpose timing applications under user control (see the January 16, 1990, Tutor column for an in-depth discussion of how timer 2 can be used to measure time intervals in the sub-55-millisecond range). The POST tests timer 1 and initializes it to the proper refresh rate. Then it initializes timer 0, submits it to a crude frequency check, and configures it to produce a pulse (interpreted as an interrupt by the 8259A) every 65,536th clock cycle.

The 8253 is accompanied on the system board by an 8237 DMA controller. DMA is a mechanism for transferring data directly between memory locations without involving the CPU. On the PC, three of the 8237's four 20-bit DMA channels are used primarily to free the microprocessor from relatively slow disk I/O; the fourth is dedicated to memory refresh. Immediately after initializing the 8253, the POST subjects the registers of the 8237 to a write/read test and, if no problems are detected, begins the periodic memory refresh.

With dynamic RAM now up and available, the POST reads the system board DIP switches to determine how much memory is installed on the system board and expansion cards. The first 16K is subjected to a full integrity test while any remaining RAM is simply initialized to zero. Then the 8259A is set up to arbitrate interrupts arriving on its eight request lines, and the first 32 interrupt vectors are directed to a temporary interrupt service routine. The 8259A handles interrupts in the PC by prioritizing requests from external sources and passing them on one at a time to the CPU. After the 8259A is initialized, the POST tests it by masking off hardware interrupts and entering a do-nothing delay loop of approximately 1 second in duration. If no interrupts occur during that time, then the POST continues; otherwise, execution is abruptly stopped.

Finally, to round out the first phase of operation, the POST copies the proper values of interrupt vectors 10h through 1Fh to their respective slots in low memory.

With the most-basic pieces of hardware now working, the POST turns its attention to the video controller card. Switch block 1 is read, and the result is stored in the low byte of the BIOS data area's equipment flag word. The POST determines the default video mode from sense switches 4 and 5 and calls function 0 of interrupt 10h to initialize the 6845 video controller, set up video parameters in the BIOS data area, clear the video buffer, position the cursor in the upper-left corner of the screen, and enable the video signal. The Motorola 6845 is the programmable CRT controller used in IBM's original CGA and MDA display adapters. For compatibility, the 6845 is partially emulated in today's higher-performance EGA and VGA adapters. As a result, you can insert an EGA into a slot in an old PC and the POST will still work correctly—even though it predated the EGA by several years.

Next, video RAM is subjected to a thorough write/read/verify test, and a single row of characters is written to the video buffer. To make sure the hardware is functioning properly, the POST delays long enough to verify that the vertical and horizontal retrace bits in the CRT status register periodically change polarity. Then, after clearing the screen, it makes a sweep of ROM address space between segments C000h and C800h in 2K increments, looking for video adapters with their own internal startup codes like the EGA. If any additional ROM modules are found, the POST transfers control to them long enough to let them perform their own specialized hardware initialization procedures.

Next comes the incremental memory check you see displayed on-screen on machines postdating the original PC. Every byte of RAM is written and read with all ones, all zeros, and alternating checkerboard patterns to check for sympathetic, stuck, and unresponsive bits. Up to this point, the POST's general response to a test failure has been to shut down the system with no explanatory remarks or messages to the user. With video now functioning, however, a data compare or parity check error results in a 201 error code that is displayed on your screen.

With memory now verified, the keyboard is reset, tested, and checked for stuck keys. An error produces a 301 message. Interrupt vectors 8 through 0Fh are set up, and a scan for adapter ROMs in the range of segment addresses C800h through F400h is initiated. A ROM module is identified by the word value 55AAh in its first storage location at offset 0. When a ROM module is found, the POST transfers control to it by effecting a jump to offset 3 in the ROM segment. By convention, the byte at offset 2 holds the length of the module expressed in the number of 512-byte blocks, while offset 3 holds the first byte of the adapter's internal startup code.

The final memory test performed is a simple checksum on the 32K BASIC ROM containing the interpreted BASIC kernel routines. The POST follows up by enabling disk interrupts, resetting the floppy disk controller, turning on the drive motor, delaying for one second, performing a seek, and shutting off the motor again. An error in any of these exercises produces a 601 indicator on your screen but does not halt execution.

With most of its work done, the POST does some miscellaneous housekeeping that includes setting up the remainder of the values not already defined inside the BIOS data area. The data area is a 256-byte RAM workspace at absolute address 400h used by the ROM BIOS. The POST sets up the keyboard buffer and enters default time-out values for parallel and serial ports. It also determines how many parallel and serial ports are attached and fills in their respective I/O addresses in the data area's communications address tables.

The final task the POST performs before calling the bootstrap loader is to enable NMI. NMI, or nonmaskable interrupt, is "nonmaskable" because it isn't routed through the 8259A and therefore can't be masked in the same sense that other interrupts can. It can, however, be enabled and disabled by toggling a latch accessed through an I/O port. NMI is used on the PC to report parity check errors and math coprocessor exceptions.

The POST ends by emitting one short beep from the PC's speaker and executing an interrupt 19h to invoke the bootstrap loader. The loader is charged with the task of loading an operating system from disk to get the machine running, without benefit of the operating system's high-level disk I/O services. The process is called bootstrapping because the PC figuratively pulls itself up by its bootstraps.

The interrupt 19h handler uses BIOS interrupt 13h to read the very first sector of the disk in drive A: (called the "boot sector" by DOS) and copy its contents to absolute address 7C00h. If the call succeeds, control is transferred to 7C00h with a JMP instruction. If no disk is present in the drive or if a drive malfunction prevents the sector from being read, the loader executes an interrupt 18h to invoke cassette BASIC.

On more contemporary machines such as the XT, the BIOS is smart enough to go to the hard disk before defaulting to BASIC if there is no disk in the A: drive. Getting an original PC to do the same requires a ROM upgrade. With a hard disk installed in the system, the sector read by the loader (the first physical sector on the disk) contains the master partition table and a fragment of code that inspects the table to determine which operating system Is bootable. The boot sector belonging to the bootable operating system—found in the first logical sector of the corresponding partition—is loaded and given control.

If that operating system is PC-DOS, the bootstrapping code checks to see if the disk contains a copy of the operating system by reading the first sector of the root directory and looking for the hidden files IBMBIO.COM and IBMDOS.COM. The files must occupy the first two slots in the root directory. Moreover, IBMBIO.COM must lie in contiguous sectors beginning in the disk's first data sector. If these conditions are met, IBMBIO.COM is read into memory and handed control. IBMBIO.COM, in turn, loads IBMDOS.COM, which contains the DOS kernel.

IBMBIO.COM sets up interrupt vectors 20h through 3Fh and performs various other tasks required to get the operating system working. Among other things, it is responsible for initializing resident device drivers, processing the CONFIG.SYS file, loading installable device drivers, and structuring DOS's layout in memory to accommodate disk buffers, internal tables, file control blocks, and device drivers. It finishes up by calling the EXEC function to load and execute COMMAND.COM, or an alternative command processor if one was specified with the SHELL command in CONFIG.SYS.

It's the command processor that finally brings up the DOS prompt. COMMAND.COM, DOS's default command processor, processes the AUTOEXEC.BAT file, then splits itself into a resident and a transient portion. The latter half is copied into high memory, where it can be overwritten if an application program needs the extra memory (if a program destroys the upper half, COMMAND.COM uses the COMSPEC variable to locate its image on disk and reload itself when the program ends). Its final act during startup is to display the DOS prompt in the format specified by the PROMPT environment variable and call DOS function 0Ah to read input from the keyboard—the point at which you can finally type a command.

Fundamental hardware differences between the PC and the AT dictate that the AT's POST routines be somewhat more sophisticated than the PC's. The AT POST, for example, checks for and initializes a hard disk immediately after initializing the first disk drive and attempts to boot from the hard disk if drive A: is empty. It checks the keyswitch on the front of the box to make sure the keyboard isn't locked. And it provides more-descriptive error messages when problems do occur.

Other AT hardware advancements required more subtle refinements to the POST. The AT, for example, uses a pair of cascaded 8259A interrupt controllers to double the number of hardware interrupt lines available. It also implements two 82377 DMA controllers in place of the single one found in the PC. In each case, two chips must be initialized rather than one. Another key difference arises from the AT's use of CMOS RAM to store configuration data. CMOS RAM is validated with a checksum process similar to the one used to check BIOS ROM, and hardware information is pulled from CMOS RAM rather than system board DIP switches.

But the most significant change made to the POST was driven by the AT's use of the 80286. The AT switches from real mode to protected mode and back at least three times during startup. The first time, the POST determines how much of the 16-megabit address space is filled with RAM. The second time, all RAM above the first 64K is tested. Each time thereafter, one or more hardware functions essential to protected-mode operation are tested.

The bootstrapping process is more a function of the operating system than of the hardware it's running on and, in general, has remained relatively unchanged over time. But with the AT—and with 286 and 386 machines in general—comes the possibility that the operating system being loaded is OS/2 rather than DOS.

The OS/2 bootstrapping process is roughly analogous to DOS's. In Version 1.1, the bootstrap code locates and loads the system file OS2LDR, which in turn loads OS2KRNL. OS2KRNL immediately jumps into protected mode and initializes the various components of OS/2, then processes CONFIG.SYS and, based on the hardware configuration, loads OS/2's internal disk, keyboard, screen, clock, and printer device drivers. Finally, Presentation Manager is loaded. Presentation Manager completes the list of startup tasks, which includes processing the command file STARTUP.CMD and initializing the Start Programs window along with the Task Manager, DOS compatibility box, and print spooler icons, before giving the machine up to user control.

We know a little less about the PS/2 startup ROM because the PS/2 BIOS listings were never published—as were the PC and AT listings. From inference, we do know that the Personal System/2 POST routines form a superset of those found in the AT. The chief differences stem from the implementation of a power-on password and the programmable option select (POS) feature of the Micro Channel bus.

If a power-on password has been defined, the POST displays a keylike symbol on the screen and pauses until the user replicates the password from the keyboard. The password bytes are then locked in CMOS RAM so that no subsequent program can access them and defeat the protection scheme.

Immediately after the CPU and support chips are checked out and initialized (or, at least, the equivalent of the support chips; much of what was packaged in discrete chips in the PC is implemented in custom integrated circuitry in PS/2s) and CMOS RAM is determined to be in working order, the POST sequence is started. The POST reads an ID code from each adapter plugged into the Micro Channel and compares it with the ID code recorded for that slot in CMOS RAM. If the two agree, the POST sends programmable configuration data to the card; if the [Ds do not match, the machine beeps and displays an error code. The POST then proceeds as normal, but it will not boot the computer until the reference disk has been placed in the A: drive. The reference disk contains the configuration utility needed to resolve the conflict.

The POST varies in non-IBM BIOSs, but only to accommodate slight differences in hardware and to ensure that copyrights are not infringed upon. Similarly, there is a high degree of uniformity among PCs in the way the operating system is loaded because the bootstrap loader exists primarily in software, not in firmware.

It's difficult to trace through the actions of the power-on diagnostic and initialization routines without gaining a deeper appreciation for the complexity of the hardware and the delicacy of the interactions between components. And with appreciation comes understanding—the kind that may help you determine what went wrong the next time the POST reports an error.

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: 20 Jan 2024 - Changelog | About | Legal & Contact