Real mode: Difference between revisions
Line 18: | Line 18: | ||
==Switching to real mode== |
==Switching to real mode== |
||
Intel introduced protected mode into the x86 family with the intention that operating systems which used it would run entirely in the new mode and that all programs running under a protected mode operating system would run in protected mode as well. Because of the substantial differences between real mode and even the rather limited 286 protected mode, programs written for real mode cannot run in protected mode without being rewritten. Therefore, with a wide base of existing real mode applications which users depended on, abandoning real mode posed problems for the industry, and programmers sought a way to switch between the modes at will. However, Intel, consistent with their intentions for the processor's usage, provided an easy way to switch into protected mode on the 80286 but no easy way to switch back to real mode. Before the 386 the only way to switch from protected mode back to real mode was to reset the processor; after a reset it always starts up in real mode to be compatible with earlier x86 CPUs back to the 8086. Resetting the processor does not clear the system's RAM, so this, while awkward and inefficient, is actually feasible. From protected mode, the processor's state is saved in memory, then the processor is reset, restarts in real mode, and executes some real mode code to restore the saved state from memory. It can then run other real mode code until the program is ready to switch back to protected mode. The switch to real mode is costly in terms of time, but this technique allows protected mode programs to use services such as BIOS, which runs entirely in real mode (having been designed originally for the [[8088]]-based [[IBM Personal Computer]] model ''(machine type)'' 5150). This mode-switching technique is also the one used by [[DPMI]] (under real, not emulated, DOS) and [[DOS extender]]s like [[DOS/4GW]] to allow protected mode programs to run under DOS; the DPMI system or DOS extender switches to real mode to invoke DOS or BIOS calls, then switches back to return to the application program which runs in protected mode. |
Intel introduced protected mode into the x86 family with the intention that operating systems which used it would run entirely in the new mode and that all programs running under a protected mode operating system would run in protected mode as well. Because of the substantial differences between real mode and even the rather limited 286 protected mode, programs written for real mode cannot run in protected mode without being rewritten. Therefore, with a wide base of existing real mode applications which users depended on, abandoning real mode posed problems for the industry, and programmers sought a way to switch between the modes at will. However, Intel, consistent with their intentions for the processor's usage, provided an easy way to switch into protected mode on the 80286 but no easy way to switch back to real mode. Before the 386 the only way to switch from protected mode back to real mode was to reset the processor; after a reset it always starts up in real mode to be compatible with earlier x86 CPUs back to the 8086. Resetting the processor does not clear the system's RAM, so this, while awkward and inefficient, is actually feasible. From protected mode, the processor's state is saved in memory, then the processor is reset, restarts in real mode, and executes some real mode code to restore the saved state from memory. It can then run other real mode code until the program is ready to switch back to protected mode. The switch to real mode is costly in terms of time, but this technique allows protected mode programs to use services such as BIOS, which runs entirely in real mode (having been designed originally for the [[8088]]-based [[IBM Personal Computer]] model ''(machine type)'' 5150). This mode-switching technique is also the one used by [[DPMI]] (under real, not emulated, DOS) and [[DOS extender]]s like [[DOS/4GW]] to allow protected mode programs to run under DOS; the DPMI system or DOS extender switches to real mode to invoke DOS or BIOS calls, then switches back to return to the application program which runs in protected mode. This is probably the reason why until Windows ME it was possible to restart the computer to MS DOS mode from within the operating system. The changing towards the NT kernel resulted in the operating system not needing DOS to boot the computer as well as unable to use it. The need to restart the computer in Real Mode MS DOS declined after Windows 3.1x till it was no longer needed. The only way of currently running DOS applications in Real Mode from within newer versions of Windows is by using emulators such as [[DOSBox]]. |
||
==See also== |
==See also== |
Revision as of 11:29, 15 August 2010
Part of a series on |
Microprocessor modes for the x86 architecture |
---|
|
First supported platform shown in parentheses |
Real mode, also called real address mode, is an operating mode of 80286 and later x86-compatible CPUs. Real mode is characterized by a 20 bit segmented memory address space (giving just over 1 MB of addressable memory) and unlimited direct software access to all memory and I/O addresses and peripheral hardware. Real mode provides no support for memory protection, multitasking, or code privilege levels. 80186 CPUs and earlier, back to the original 8086, have only one operational mode, which is equivalent to real mode in later chips. All x86 CPUs in the 80286 series and later start in real mode when reset.
History
The 286 architecture introduced protected mode, allowing for (among other things) hardware-level memory protection. Using these new features, however, required a new operating system that was specifically designed for it. Since a primary design specification of x86 microprocessors is that they be fully backwards compatible with software written for all x86 chips before them, the 286 chip was made to start in 'real mode' — that is, in a mode which turned off the new memory protection features, so that it could run operating systems written for the 8086 and the 80186. To this day, even the newest x86 CPUs (including x86_64 CPUs) start in real mode at power-on and can run software written for any previous chip (with a few exceptions due to slight instruction set differences).
The PC BIOS which IBM introduced operates in real mode, as do the DOS operating systems (MS-DOS, DR-DOS, etc.). Early versions of Microsoft Windows ran in real mode, until Windows 386, which ran in protected mode, and the more fully realized Windows 3.0, which could run in either real or protected mode. Windows 3.0 could actually run in two "flavours" of protected mode: "standard mode", which ran using protected mode, and "386-enhanced mode", which is a virtualized version of standard mode and thus would not run on a 286. Windows 3.1 removed support for real mode, and it was the first mainstream operating environment which required at least an 80286 processor. Almost all modern x86 operating systems (Unix, Linux, OS/2, Windows 95 and later, etc.) switch the CPU into protected mode at startup. It is worth noting that the protected mode of the 80286 is considerably more primitive than the improved protected mode introduced with the 80386; the latter is sometimes called 386 protected mode, and is the mode most modern x86 operating systems run in.
Addressing capacity
The 8086, 8088, and 80186 have a 20-bit address bus, but the unusual segmented addressing scheme Intel chose for these processors actually produces effective addresses which can have 21 significant bits. This scheme shifts a 16-bit segment number left four bits (making a 20-bit number with four least-significant zeros) before adding to it a 16-bit address offset; the maximum sum occurs when both the segment and offset are hexadecimal FFFF, yielding FFFF0h + FFFFh = 10FFEFh. (The small "h" on the end of each number denotes hexadecimal notation.) On the 8086, 8088, and 80186, the result of an effective address that overflows 20 bits is that the address "wraps around" to the zero end of the address range, i.e. it is taken modulo 2^20 (2^20 = 1048576 = 10000h). However, the 80286 has 24 address bits and computes effective addresses to 24 bits even in real mode. Therefore, for the segment FFFFh and offset greater than 000Fh, the 80286 would actually make an access into the beginning of the second binary megabyte of memory, whereas the 80186 and earlier would access an address equal to [offset]-10h ( = [offset]-16 decimal), which is at the beginning of the first megabyte. (Note that on the 80186 and earlier, the first 1 KB of the address space, starting at address 0, is the permanent, immovable location of the interrupt vector table.) So the actual amount of memory addressable by the 80286 and later x86 CPUs in real mode is 1 MB + 64 KB - 16B = 1114095 Bytes.
A20 line
Some programs predating the 80286 were designed to take advantage of the wrap-around (modulo) memory addressing behavior, so the 80286 presented a problem for backward compatibility. Forcing the 21st address line (the actual logic signal wire coming out of the chip) to a logic low, representing a zero, results in a modulo-2^20 effect to match the earlier processors' address arithmetic, but the 80286 has no internal capability to perform this function. When IBM used the 80286 in their IBM Personal Computer AT, they solved this problem by including a software-settable gate to enable or disable (force to zero) the A20 address line, between the A20 pin on the 80286 and the system bus; this is known as Gate-A20 (the A20 gate), and it is still implemented in PC chipsets to this day. Most versions of the HIMEM.SYS extended memory driver for IBM-/MS-DOS famously displayed upon loading a message that they had installed an "A20 handler", a piece of software to control Gate-A20 and coordinate it to the needs of programs. Obviously, in protected mode the A20 line needs to be enabled, or else physical addressing errors will occur, likely leading to a system crash.
Switching to real mode
Intel introduced protected mode into the x86 family with the intention that operating systems which used it would run entirely in the new mode and that all programs running under a protected mode operating system would run in protected mode as well. Because of the substantial differences between real mode and even the rather limited 286 protected mode, programs written for real mode cannot run in protected mode without being rewritten. Therefore, with a wide base of existing real mode applications which users depended on, abandoning real mode posed problems for the industry, and programmers sought a way to switch between the modes at will. However, Intel, consistent with their intentions for the processor's usage, provided an easy way to switch into protected mode on the 80286 but no easy way to switch back to real mode. Before the 386 the only way to switch from protected mode back to real mode was to reset the processor; after a reset it always starts up in real mode to be compatible with earlier x86 CPUs back to the 8086. Resetting the processor does not clear the system's RAM, so this, while awkward and inefficient, is actually feasible. From protected mode, the processor's state is saved in memory, then the processor is reset, restarts in real mode, and executes some real mode code to restore the saved state from memory. It can then run other real mode code until the program is ready to switch back to protected mode. The switch to real mode is costly in terms of time, but this technique allows protected mode programs to use services such as BIOS, which runs entirely in real mode (having been designed originally for the 8088-based IBM Personal Computer model (machine type) 5150). This mode-switching technique is also the one used by DPMI (under real, not emulated, DOS) and DOS extenders like DOS/4GW to allow protected mode programs to run under DOS; the DPMI system or DOS extender switches to real mode to invoke DOS or BIOS calls, then switches back to return to the application program which runs in protected mode. This is probably the reason why until Windows ME it was possible to restart the computer to MS DOS mode from within the operating system. The changing towards the NT kernel resulted in the operating system not needing DOS to boot the computer as well as unable to use it. The need to restart the computer in Real Mode MS DOS declined after Windows 3.1x till it was no longer needed. The only way of currently running DOS applications in Real Mode from within newer versions of Windows is by using emulators such as DOSBox.