Hubbry Logo
A20 lineA20 lineMain
Open search
A20 line
Community hub
A20 line
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
A20 line
A20 line
A20 line
View on Wikipedia
from Wikipedia

The high memory area is only available in real mode on 80286 processors if the A20 gate is enabled.

The A20, or address line 20, is one of the electrical lines that make up the system bus of an x86-based computer system. The A20 line in particular is used to transmit the 21st bit on the address bus.

A microprocessor typically has a number of address lines equal to the base-two logarithm of the number of words in its physical address space. For example, a processor with 4 GB of byte-addressable physical space requires 32 lines (log2(4 GB) = log2(232 B) = 32), which are named A0 through A31. The lines are named after the zero-based number of the bit in the address that they are transmitting. The least significant bit is first and is therefore numbered bit 0 and signaled on line A0. A20 transmits bit 20 (the 21st bit) and becomes active once addresses reach 1 MB, or 220.

Overview

[edit]
See also: x86 memory segmentation

The Intel 8086, Intel 8088, and Intel 80186 processors had 20 address lines, numbered A0 to A19; with these, the processor can access 220 bytes, or 1 MB. Internal address registers of such processors only had 16 bits. To access a 20-bit address space, an external memory reference was made up of a 16-bit offset address added to a 16-bit segment number, shifted 4 bits to the left so as to produce a 20-bit physical address. The resulting address is equal to segment × 16 + offset.[1] There are many combinations of segment and offset that produce the same 20-bit physical address. Therefore, there were various ways to address the same byte in memory.[2] For example, here are four of the 4096 different segment:offset combinations, all referencing the byte whose physical address is 0x000FFFFF (the last byte in 1 MB-memory space):

F000:FFFF
FFFF:000F
F555:AAAF
F800:7FFF

Referenced the last way, an increase of one in the offset yields F800:8000, which is a proper address for the processor, but since it translates to the physical address 0x00100000 (the first byte over 1 MB), the processor would need another address line for actual access to that byte. Since there is no such line on the 8086 line of processors, the 21st bit above, while set, gets dropped, causing the address F800:8000 to "wrap around"[1] and to actually point to the physical address 0x00000000.

When IBM designed the IBM PC AT (1984) machine, it decided to use the new higher-performance Intel 80286 microprocessor. The 80286 could address up to 16 MB of system memory in protected mode. However, the CPU was supposed to emulate an 8086's behavior in real mode, its startup mode, so that it could run operating systems and programs that were not written for protected mode. The 80286 did not force the A20 line to zero in real mode, however. Therefore, the combination F800:8000 would no longer point to the physical address 0x00000000, but to the address 0x00100000. As a result, programs relying on the address wrap around would no longer work. To remain compatible with such programs, IBM decided to correct the problem on the motherboard.

That was accomplished by inserting a logic gate on the A20 line between the processor and system bus, which got named Gate-A20. Gate-A20 can be enabled or disabled by software to allow or prevent the address bus from receiving a signal from A20. It is set to non-passing for the execution of older programs that rely on the wrap-around. At boot time, the BIOS first enables Gate-A20 when it counts and tests all of the system memory, and then disables it before transferring control to the operating system.

Originally, the logic gate was a gate connected to the Intel 8042 keyboard controller.[1] Controlling it was a relatively slow process. Other methods have since been added to allow more efficient multitasking of programs that require this wrap-around with programs that access all of the system memory. There are multiple methods to control the A20 line.[3]

Disconnecting A20 would not wrap all memory accesses above 1 MB, just those in the 1–2 MB, 3–4 MB, 5–6 MB, etc. ranges. Real-mode software cared only about the area slightly above 1 MB, so the Gate-A20 line was enough.

Enabling the Gate-A20 line is one of the first steps that a protected-mode x86 operating system does in the bootup process, often before control has been passed to the kernel from the bootstrap (in the case of Linux, for example).

Virtual 8086 mode, introduced with the Intel 80386, allows the A20 wrap-around to be simulated by using the virtual memory facilities of the processor; physical memory may be mapped to multiple virtual addresses. Thus, the memory mapped at the first megabyte of virtual memory may be mapped again in the second megabyte of virtual memory. The operating system may intercept changes to Gate A20 and make corresponding changes to the virtual-memory address space, which also makes irrelevant the efficiency of Gate-A20 line toggling.

A20 gate

[edit]

Controlling the A20 line was an important feature at one stage in the growth of the IBM PC architecture, as it added access to an additional 65,520 bytes (64 KB − 16 bytes) of memory in real mode, without significant software changes.

In what was arguably a "hack", the A20 gate was originally part of the keyboard controller on the motherboard, which could open or close it depending on what behavior was desired.[4]

In order to keep full compatibility with the Intel 8086, the A20 gate was still present in Intel CPUs until 2008.[5] As the gate was initially closed right after boot, protected-mode operating systems typically opened the A20 gate early during the boot process to never close it again. Such operating systems had no compatibility reasons for keeping it closed, and they gained access to the full range of physical addresses available by opening it.

The Intel 80486 and Pentium added a special pin named A20M#, which when asserted low forces bit 20 of the physical address to be zero for all on-chip cache- or external-memory accesses. It was necessary, since the 80486 introduced an on-chip cache and so masking this bit in external logic was no longer possible. Software still needs to manipulate the gate and must still deal with external peripherals (the chipset) for that.[6]

The PC System Design Guide PC 2001 removes compatibility for the A20 line: "If A20M# generation logic is still present in the system, this logic must be terminated such that software writes to I/O port 92, bit 1, do not result in A20M# being asserted to the processor."[7]

Support for the A20 gate was changed in the Nehalem microarchitecture (some sources incorrectly claim that A20 support was removed). Rather than the CPU having a dedicated A20M# pin that receives the signal whether or not to mask the A20 bit, it has been virtualized so that the information is sent from the peripheral hardware to the CPU using special bus cycles.[citation needed] From a software point of view, the mechanism works exactly as before, and an operating system must still program external hardware (which in-turn sends the aforementioned bus cycles to the CPU) to disable the A20 masking.[citation needed]

Intel no longer supports the A20 gate, starting with Haswell. Page 271 of the Intel System Programmers Manual Vol. 3A from June 2013 states: "The functionality of A20M# is used primarily by older operating systems and not used by modern operating systems. On newer Intel 64 processors, A20M# may be absent."[8]

A20 handler

[edit]

The A20 handler is IBM PC memory manager software that controls access to the high memory area (HMA). Extended-memory managers usually provide this functionality. A20 handlers are named after the 21st address line of the microprocessor, the A20 line.

In DOS, HMA managers such as HIMEM.SYS have the "extra task" of managing A20. HIMEM.SYS provided an API for opening/closing A20. DOS itself could use the area for some of its storage needs, thereby freeing up more conventional memory for programs. That functionality was enabled by the DOS=HIGH or HIDOS=ON directives in the CONFIG.SYS configuration file.

Affected programs

[edit]

Since 1980, the address wrap was internally used by 86-DOS and MS-DOS to implement the DOS CALL 5 entry point at offset +5 to +9 (which emulates the CP/M-80-style CALL 5 BDOS API entry point at offset +5 to +7) in the Program Segment Prefix (PSP) (which partially resembles CP/M-80's zero page).[9][10] This was, in particular, utilized by programs machine-translated from CP/M-80 through assembly language translators[9] like Seattle Computer Products' TRANS86.[11] The CALL 5 handler this entry point refers to resides at the machine's physical address 0x000000C0 (thereby overlapping the four bytes of the interrupt service routine entry point reserved for INT 30h and the first byte of INT 31h in the x86 real mode interrupt vector table).[12][13][14] However, by the design of CP/M-80, which loaded the operating system immediately above the memory available for the application program to run in, the 8080/Z80 16-bit target address stored at offset +6 to +7 in the zero page could deliberately also be interpreted as the size of the first memory segment.[9] In order to emulate this in DOS with its 8086 segment:offset addressing scheme, the far call entry point's 16-bit offset had to match this segment size (i.e. 0xFEF0), which is stored at offset +6 to +7 in the PSP, overlapping parts of the CALL 5.[13][14] The only way to reconcile these requirements was to choose a segment value that, when added to 0xFEF0, results in an address of 0x001000C0, which, on an 8086, wraps around to 0x000000C0.[15][12][14]

A20 had to be disabled for the wraparound to occur and DOS programs using this interface to work. Newer DOS versions which can relocate parts of themselves into the HMA, typically craft a copy of the entry point at FFFF:00D0 in the HMA (which again resolves to physical 0x001000C0), so that the interface can work without regard to the state of A20.[14][16]

One program known to use the CALL 5 interface is the DOS version of the Small-C compiler.[17] Also, the SPELL utility in Microsoft's Word 3.0 (1987) is one of the programs depending on the CALL 5 interface to be set up correspondingly.[18] Sun Microsystems' PC-NFS (1993) requires the CALL 5 fix-up as well.[16]

Also, to save program space,[1] a trick was used by some BIOS and DOS programmers, for example, to have one segment that has access to program data (such as from F800:0000 to F800:7FFF, pointing to the physical addresses 0x000F8000–0x000FFFFF), as well as the I/O data (such as the keyboard buffer) that was located in the first memory segment (with addresses F800:8000 to F800:FFFF pointing to the physical addresses 0x00000000 to 0x00007FFF).

This trick works for as long as the code isn't executed in low memory, the first 64 KB of RAM, a condition that was always true in older DOS versions without load-high capabilities.

With the DOS kernel relocated into higher memory areas, low memory increasingly became available for programs, causing those depending on the wraparound to fail.[19] The executable loaders in newer versions of DOS attempt to detect some common types of affected programs and either patch them on-the-fly to function also in low memory[20] or load them above the first 64 KB before passing execution on to them.[20] For programs, which are not detected automatically, LOADFIX[21] or MEMMAX -L[21] can be used to force programs to be loaded above the first 64 KB.

The trick was utilized by IBM/Microsoft Pascal itself as well as by programs compiled with it,[22][23][10][17] including Microsoft's MASM.[17] Other commonly used development utilities using this were executable compressors like Realia's Spacemaker[20] (written by Robert B. K. Dewar in 1982 and used to compress early versions of the Norton Utilities[24][25][26][27]) and Microsoft's EXEPACK[19][20][1][28][17] (written by Reuben Borman in 1985) as well as the equivalent /E[XEPACK] option in Microsoft's LINK 3.02 and higher.[19][1][28][26] Programs processed with EXEPACK would display a "Packed file is corrupt" error message.[1][20][28]

Various third-party utilities exist to modify compressed executables either replacing the problematic uncompression routine(s) through restubbing, or attempting to expand and restore the original file.

Modern Legacy BIOS boot loaders (such as GNU GRUB) use the A20 line.[3] UEFI boot loaders use 32-bit protected mode or 64-bit long mode.

See also

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

A20 line

View on Grokipedia
from Grokipedia
The A20 line, also referred to as the A20 address line or A20 gate, is a hardware signal in the x86 processor architecture that controls the 21st bit (A20) of the physical memory address bus, enabling access to memory locations beyond the 1 MB limit imposed by the original and 8088 processors. Introduced with the (PC AT) in 1984, which utilized the microprocessor featuring a 24-bit address bus capable of addressing up to 16 MB of physical memory, the A20 line was implemented to support while ensuring with earlier PC systems. By default, the A20 line is disabled at system boot, masking the A20 bit to replicate the 20-bit addressing behavior of the 8086 (limiting access to 1 MB and causing addresses above 1 MB to wrap around to the first MB), a design choice rooted in maintaining software compatibility for the burgeoning PC ecosystem. This mechanism, physically represented on the PC AT system board and I/O channel connectors, is toggled through the 8042 keyboard controller or routines, such as those using interrupt 15h for operations. Enabling the A20 gate—via commands like writing to the controller's output port (bit 1) or manufacturing test port 0x80—allows the 80286 to utilize its full protected-mode addressing capabilities, including up to 1 GB of per task, which became essential for memory-intensive applications and operating systems in the and early . The A20 line's management persisted as a legacy requirement in subsequent x86 systems, influencing bootloaders, real-mode operating systems like , and even modern emulators, until hardware designs in the late and beyond rendered it obsolete by permanently enabling extended addressing without compatibility constraints.

Background

Early PC Memory Limitations

The and 8088 microprocessors, which powered the original PC and its compatible systems, featured a 20-bit address bus consisting of lines A0 through A19, enabling direct access to a maximum of 1 MB of physical memory, equivalent to 2202^{20} bytes or addresses from 00000h to FFFFFh. This hardware constraint arose from the design of the Bus Interface Unit (BIU), which generated 20-bit physical addresses to interface with memory and I/O devices. In , the addressing scheme employed 16-bit segment registers (CS for code, DS for data, for stack, and for extra) combined with 16-bit offsets to form physical addresses, calculated as (segment value × 16) + offset, theoretically spanning the full 1 MB space. However, this mechanism introduced wraparound behavior at the 1 MB boundary, where addresses exceeding FFFFFh would cycle back to 00000h, potentially causing unintended overlaps or errors in memory access without explicit software management. Each segment was limited to 64 KB (65,536 bytes, addressed by offsets from 0000h to FFFFh), with segments aligned on 16-byte boundaries to facilitate overlapping and contiguous addressing. The PC, introduced in 1981, and its XT successor typically shipped with base read/write RAM configurations ranging from 16 KB to 64 KB on the system board, expandable in 16 KB increments up to a maximum of 640 KB for general-purpose use by applications and the operating system. The remaining upper memory regions were reserved: approximately 128 KB from A0000h to BFFFFh for video RAM (e.g., 32 KB for monochrome display at B0000h–B7FFFh or 32 KB for color/graphics at B8000h–BFFFFh), and 64 KB from F0000h to FFFFFh for ROM containing firmware, I/O drivers, and the Cassette . This allocation left 384 KB (from 640 KB to 1 MB) unavailable for base memory expansion due to these hardware reservations, enforcing a practical limit on usable RAM. Real-mode addressing quirks, such as the 64 KB segment size, required programmers to manage transitions across segment boundaries by adjusting the segment register when offsets approached FFFFh, as exceeding this would wrap the offset back to 0000h and potentially access unintended locations in the next segment. These characteristics, including the overlapping nature of segments offset by 16 bytes, influenced compatibility decisions in early PC software and hardware design to ensure reliable operation within the constrained 1 MB space.

Introduction of Extended Addressing

The original Intel 8086 and 8088 processors employed 20-bit addressing, constraining them to a 1 MB memory space with inherent wraparound at the upper limit. In February 1982, Intel introduced the 80286 microprocessor, which expanded physical addressing to 24 bits (A0–A23), enabling access to up to 16 MB of memory and marking a significant advancement beyond the 8086's capabilities. The 80286 incorporated two primary operating modes to balance innovation with legacy support: protected mode, which fully leveraged the 24-bit address bus for the complete 16 MB address space, and real mode, which preserved the 20-bit addressing and segmented memory model of the 8086 to ensure object-code compatibility with existing software. The IBM PC/AT, released in 1984, integrated the 80286 processor and introduced extended memory above the traditional 1 MB boundary, allowing for greater RAM capacity through onboard and expansion options while maintaining real-mode operation as the default for booting and running 8086-compatible applications. However, this transition created compatibility challenges, as the 80286's real mode did not automatically replicate the 8086's exact addressing behavior without additional hardware intervention. To achieve seamless 8086 emulation and prevent unintended access to the 1–2 MB address range—which would disrupt wraparound expectations—early motherboard designs like the IBM AT's included built-in logic to disable the A20 address line by default.

Technical Mechanism

Role of the A20 Address Line

The A20 address line, also known as bit 20 (zero-indexed) on the address bus, serves as the 21st bit in x86 processor addressing, enabling the distinction between the lower 1 MB of (addresses 00000h to FFFFFh) and the immediately beyond it (1 MB to 2 MB). This line was introduced with the processor, which featured a 24-bit address bus capable of accessing up to 16 MB in , but required specific handling in to maintain compatibility with earlier systems. When the A20 line is held low (0) by the external gate, bit 20 is masked on the address bus, causing addresses that exceed 1 MB to wrap around to the base of memory, thereby emulating the 20-bit addressing behavior of the original Intel 8086 processor and limiting the effective addressable space to 1 MB (00000h to FFFFFh). For example, a linear address of 100000h would map to 00000h under this condition, preventing unintended access to higher memory regions and ensuring software compatibility with legacy 8086/8088 applications that assume a 1 MB wraparound. In real mode on the 80286, the physical address is 24 bits with A21–A23 always low, but A20 may be high for addresses >=1MB; the external A20 gate forces A20 low to enforce the 1MB boundary and emulate 8086 wraparound. When the A20 line is asserted high (1), bit 20 is unmasked, allowing full 21-bit addressing in and extending access to the High Memory Area (HMA), which spans 100000h to 10FFEFh (1 MB to approximately 1 MB + 64 KB, or 65,520 bytes). This capability provides a modest expansion beyond the traditional 1 MB limit without switching to , though the HMA's usability is constrained by the 64 KB segment size in . Subsequent processors, such as the 80386, integrated the A20 mechanism into the CPU pinout (via the A20M# pin) while preserving it for real-mode compatibility, ensuring with 80286 software and hardware designs.

A20 Gating for Compatibility

The A20 gate, also referred to as the Gate-A20, is a hardware circuit integrated into the design of the PC/AT, introduced in 1984, which forces the A20 address line to a low state upon system reset or power-up. This mechanism emulates the 20-bit addressing behavior of the original /8088 processors used in the PC, limiting effective addressable memory to 1 MB in . By default disabling the A20 line, the gate ensures that the 21st bit of the address bus (A20) remains inactive, causing memory addresses exceeding 1 MB to wrap around to the base of the address space rather than accessing higher memory regions. The primary purpose of this gating logic was to maintain with software developed for the 8086-based PC, much of which relied on the wraparound behavior at the 1 MB boundary for proper operation. Without this intervention, programs running in on the 80286 processor—capable of 24-bit addressing up to 16 MB—could inadvertently access undefined areas above 1 MB, leading to unpredictable behavior or crashes in ported applications such as early versions of QDOS or development tools. This design choice allowed to transition to more advanced processors while preserving the vast existing software ecosystem without requiring widespread recompilation or modifications. In early implementations on the PC/AT, the A20 gate employed straightforward hardware elements, such as AND gates or latches, directly tied to the CPU's reset signals to enforce the low state of A20. These simple circuits sufficed in the absence of advanced features like on-chip caches, as the PC/AT's focused on reliable emulation of prior systems. As processor advanced into the 80386 era around 1985, the A20 gating mechanism grew more intricate to accommodate new complexities such as and the potential for external caching, which could otherwise introduce inconsistencies in address handling during real-mode operations. Despite these enhancements, the core principle of forcing A20 low on initialization endured to support real-mode emulation, ensuring continued compatibility with legacy software environments.

Enabling Methods

Keyboard Controller Approach

The 8042 keyboard controller, introduced as the standard interface in the IBM PC/AT in 1984, provided the primary mechanism for enabling the A20 address line through dedicated output port commands. This microcontroller managed keyboard and auxiliary device inputs while also controlling system signals, including the A20 gate via bit 1 of its output port. The controller's ubiquity in the PC/AT design and subsequent compatible systems, including machines, established it as the for A20 management across x86 platforms. To enable the A20 line, software writes the command byte 0xD1 to the controller's command port at I/O address 0x64, instructing it to prepare for an output port update; it then waits for the input buffer to empty (indicated by bit 1 of the at 0x64 being clear) before writing the data byte 0xDF to the data port at 0x60, which sets output port bit 1 high and activates the gate. Disabling A20 follows a similar sequence: write 0xD1 to 0x64, wait for buffer readiness, then write 0xDD to 0x60 to clear bit 1. This procedure, which typically requires polling the in a loop with timeouts up to 20 ms for command acknowledgment, is routinely implemented in initialization routines and operating system bootloaders to ensure reliable memory addressing transitions. The A20 signal propagates within 20 μs of the controller accepting the port data. Early implementations of the 8042 exhibited inherent processing delays, with response times for commands ranging from 15 ms to start transmission to 2 ms for completion, compounded by the need for buffer synchronization. These latencies, including signal switching times on the order of 20 μs, posed reliability challenges in faster systems where rapid A20 toggling was required, often necessitating extended wait loops or retries to avoid incomplete gate operations during mode switches.

FAST and Alternative Gates

The FAST A20 gate provides a direct hardware method to enable the A20 address line by manipulating the system control port at I/O address 0x92, bypassing the slower keyboard controller sequence. This approach sets bit 1 (value 0x02) of the port, which controls the A20 gate on compatible chipsets, allowing activation in a single I/O operation without the delays associated with command queuing in the 8042 controller. It became common in later systems and many 386-era motherboards starting in the late 1980s, offering significantly faster enabling for access in performance-critical bootloaders and early operating systems. To implement the FAST gate, software reads the current byte from 0x92, performs a bitwise OR with 0x02 to set the A20 bit while preserving other bits (such as bit 0 for CPU reset), and writes the result back; a direct write of 0x02 was occasionally used but could interfere with functionality on some hardware. This method became common in systems like those using AMI BIOS variants. Chipset-specific implementations, such as those in VIA's VT82C496G from the 1990s, supported fast A20 via 0x92 writes or other methods for enabling A20 on PCI/ISA platforms. Despite its speed advantages, the FAST A20 gate was not universally supported across all motherboards, leading to risks like system lockups or hardware damage if written to on incompatible systems. Reliable enabling required prior detection routines, such as probing the port's response or checking extension functions (e.g., INT 15h, AH=0x24), to confirm compatibility before attempting the write. This method saw adoption in operating systems like and early Windows versions, where it supplemented the keyboard controller approach on detected hardware for quicker initialization.

Software Implications

A20 Handlers and Memory Managers

A20 handlers are software routines implemented in or operating system code to detect the status of the A20 line and toggle it as needed for accessing beyond the 1 MB boundary. These handlers ensure compatibility with real-mode addressing while enabling access, particularly for operations involving the high memory area (HMA), which spans the 64 KB region immediately above 1 MB. In implementations, handlers often leverage interrupt 15h with AH=87h to perform block moves of , a function that requires the A20 line to be enabled to avoid wrapping and ensure correct transfer up to 16 MB. A prominent example of an A20 handler is provided by HIMEM.SYS, a device driver introduced with MS-DOS 5.0 in 1991, which implements the eXtended Memory Specification (XMS) for managing memory above 1 MB. HIMEM.SYS installs a dedicated A20 handler to control access to the HMA, supporting multiple machine-specific methods to toggle the line and allocating the HMA as a single 64 KB block for exclusive use by one program at a time. This driver detects the host system's configuration and selects an appropriate handler, such as those for IBM PC/AT compatibles, ensuring reliable enabling of extended memory without hardware conflicts. Detection of the A20 line's status in these handlers typically involves a probing sequence that writes a known value to a high , such as 0x500000 (5 MB), and then reads from the corresponding low , 0x100000 (1 MB), to check for due to wrapping. If the read value matches the written one at the low address, the A20 line is disabled; otherwise, it is enabled. Handlers retry alternative enabling methods—such as keyboard controller commands or chipset-specific ports—if the initial probe indicates failure, prioritizing non-disruptive approaches to maintain system stability. Beyond , other DOS memory managers incorporate A20 handling for advanced features like multitasking and expanded memory emulation. EMM386.EXE, Microsoft's expanded memory manager for , builds on XMS by emulating LIM 4.0 expanded memory using pages and relies on an underlying A20 handler (often from ) to switch between real and s for upper memory block (UMB) allocation. Similarly, Quarterdeck's QEMM provides an integrated A20 handler alongside its optimized , enabling efficient UMB usage and multitasking by dynamically controlling the line for tasks. In systems, such as early implementations, bootloaders include A20 enabling routines in assembly code (e.g., setup.S) to prepare for kernel loading, using probes and controller commands to ensure full 32-bit addressing before entry.

Affected Programs and Workarounds

Early DOS programs, particularly those developed for the 8086 processor, often relied on the 1 MB address wraparound behavior, where memory accesses beyond 1 MB folded back to the beginning of the address space. This assumption caused compatibility issues on 80286 and later processors, where the A20 gate was disabled by default to emulate the wraparound but could be enabled for extended memory access, breaking programs that depended on it. For example, Microsoft Pascal 1.0 (1981) used negative segment register values for copying static data, which wrapped around correctly on the 8086 but failed on the 80286 without wraparound emulation. Compilers like the compiler for exploited the CALL 5 interface in the program's segment prefix (PSP), a holdover from compatibility that invoked DOS functions via a far call wrapping from high addresses (e.g., FFFF:0005) to low (0000:0005). This mechanism, present since DOS 1.0 (1981), failed if the A20 line was enabled, as the wraparound no longer occurred, leading to incorrect execution of handlers. Similarly, executables compressed with 's EXEPACK utility (introduced in 1985 with Microsoft C 3.0) unintentionally depended on wraparound during in-memory unpacking; when loaded below 64 KB with A20 enabled, the unpacking algorithm produced corrupt code due to misaligned relocations. To address these issues, early workarounds involved loading affected programs at higher memory addresses (above 64 KB) to shift the load location and restore effective wraparound, as outlined in a 1985 patent for compatibility enhancements. In 3.3 (1987) and subsequent versions, the operating system began incorporating basic support, but specific A20-related fixes were limited; programs often required manual intervention, such as avoiding high memory loading. By 5.0 (1991), built-in exepatching mechanisms detected and modified common affected executables on-the-fly, particularly EXEPACKed files like EDIT.COM and FDISK.EXE, ensuring they functioned even when core DOS was relocated to the high memory area (HMA) with A20 enabled. The LOADFIX command, available in 5.0 and later, provided a user-friendly by preloading a 64 KB dummy block into upper , forcing subsequent programs to load higher and bypassing EXEPACK unpacking flaws or CALL 5 wraparound dependencies. For systems using extended managers, (included starting with 5.0) allowed configuration of A20 handling via options in , such as /A20CONTROL:OFF to prevent HIMEM from overriding existing A20 control by hardware or other drivers, thus maintaining wraparound for legacy software. Games and terminate-and-stay-resident (TSR) utilities from the mid-1980s, such as early Sierra On-Line adventure titles, frequently crashed if A20 was enabled mid-execution, as they assumed uniform low-memory access patterns without wraparound disruptions; users mitigated this by disabling memory managers like during gameplay or using LOADFIX to enforce compatible loading.

Modern Legacy

Phasing Out in CPUs

The A20M# pin, an active-low signal that masks address line A20 to emulate the 1 MB memory wraparound of the original 8086 processor, was introduced by in the 80486 in 1989 to provide explicit hardware control over A20 gating integrated directly into the CPU. This pin allowed system designers to assert it low during real-address mode operations for with 8086 software, while enabling full 32-bit addressing when deasserted. The feature was retained in subsequent architectures, including the series launched in 1993, where the pin similarly forced bit 20 to zero for on-chip cache accesses and external bus cycles when asserted. Support for the A20M# pin persisted through the Core 2 family in 2006, ensuring compatibility with legacy real-mode environments. However, starting with the Nehalem microarchitecture in 2008, the physical pin was removed from the CPU, with the A20M# signal instead generated by the chipset and forwarded to the processor via the QPI interface. In Intel's 64-bit mode (IA-32e), introduced with earlier architectures and extended in Nehalem, the CPU continued to emulate the real-mode A20 behavior internally, applying the mask to effective addresses in compatibility sub-mode to maintain 8086-like wrapping unless explicitly managed by software or hardware signals. This emulation preserved the functionality for older operating systems that relied on A20 gating during boot or legacy execution. The full deprecation of A20M# hardware support was noted starting with the Haswell microarchitecture in 2013, where Intel's System Programming Manual (Volume 3A) explicitly stated that the functionality—primarily used by legacy systems—was no longer supported in hardware on newer Intel 64 processors, and the signal may be ignored in long mode. In subsequent generations like Skylake and beyond (starting 2015), the CPU ignores the A20M# signal in long mode, as 64-bit addressing inherently exceeds the 1 MB boundary without needing emulation, rendering the pin vestigial or absent on the package. AMD processors followed a parallel path, incorporating A20M# support in their AMD64 architecture for 8086 compatibility via address bit masking, but this became vestigial in later designs from the late 2010s onward, where real-mode emulation persists only for minimal legacy needs without dedicated pin control.

Relevance in Contemporary Systems

In x86 systems utilizing legacy rather than , the A20 line must still be enabled during the boot process to support real-mode code execution, particularly for accessing beyond the first in components like option ROMs on expansion cards. This requirement persists to maintain compatibility with the original 8086 addressing model, where the A20 is initially disabled upon power-on to emulate wraparound, necessitating explicit enabling by the or for full 1MB+ utilization in . firmware, by contrast, automatically enables the A20 line early in the boot sequence, eliminating the need for manual intervention in modern firmwares. Operating system loaders such as GRUB continue to incorporate A20 handlers to ensure compatibility with legacy partitions, including those formatted for DOS or , allowing seamless ing of older real-mode environments on contemporary hardware. For instance, GRUB automatically enables the A20 gate during its initialization to access regions required by these legacy systems. Similarly, in scenarios involving legacy modes, components like the rely on underlying or compatibility layers to manage A20 state transitions when supporting older installation media or partitions. This handling prevents addressing conflicts and ensures that real-mode code from vintage OSes can execute without modification. Emulation environments replicate A20 gating to achieve faithful of 1980s-era PCs, preserving the exact addressing behaviors for software compatibility testing and retro . Virtual machines like and emulate the A20 line's toggle via I/O ports (e.g., 0x92 or keyboard controller), allowing users to disable it for authentic real-mode wraparound or enable it for protected-mode transitions, which is essential for running unmodified DOS applications or legacy . Retro hardware platforms, such as FPGA with its ao486 or PCXT cores, implement A20 logic in to mirror the original PC/AT chipset, enabling cycle-accurate execution of 8088/286/386 software including games and utilities that depend on gated addressing. As of 2025, A20 concepts see niche applications in embedded x86 systems for precise mapping in control applications and in hardware modifications like the original A20 hack, which grounds the line to bypass secure boot and map directly, facilitating installation on 2001-era consoles. These uses highlight lingering compatibility needs in specialized domains, though the A20 gate has had no mainstream impact on PC hardware or software since Intel phased out support around 2013 with the Haswell .

References

  1. https://bitsavers.trailing-edge.com/pdf/ibm/pc/at/1502494_PC_AT_Technical_Reference_Mar84.pdf
  2. https://www.os2museum.com/wp/the-a20-gate-fallout/
  3. https://www.inf.pucrs.br/calazans/undergrad/orgcomp_EC/mat_microproc/intel-8086_datasheet.pdf
  4. http://bitsavers.org/components/intel/8086/9800722-03_The_8086_Family_Users_Manual_Oct79.pdf
  5. https://bitsavers.org/pdf/ibm/pc/pc/6025008_PC_Technical_Reference_Aug81.pdf
  6. https://www.geeksforgeeks.org/computer-organization-architecture/architecture-of-8086/
  7. http://bitsavers.org/components/intel/80286/210308-001_Introduction_to_the_iAPX_286_1982.pdf
  8. http://bitsavers.trailing-edge.com/components/intel/80286/210498-005_80286_and_80287_Programmers_Reference_Manual_1987.pdf
  9. http://bitsavers.org/components/intel/80286/210498-005_80286_and_80287_Programmers_Reference_Manual_1987.pdf
  10. http://bitsavers.org/components/intel/80286/210760-002_80286_Hardware_Reference_Manual_1987.pdf
  11. https://computer.rip/2022-12-17-the-keyboard-controller.html
  12. http://wiki.osdev.org/A20_Line
  13. https://aeb.win.tue.nl/linux/kbd/A20.html
  14. https://tldp.org/HOWTO/Linux-Init-HOWTO-3.html
  15. https://bitsavers.org/pdf/viaTechnologies/VT82C496G_VT82C406MV_199504.pdf
  16. https://www.phatcode.net/res/219/files/xms20.txt
  17. https://fd.lod.bz/rbil/interrup/bios/1587.html
  18. http://jeffpar.github.io/kbarchive/kb/095/Q95555/
  19. http://jeffpar.github.io/kbarchive/kb/096/Q96711/
  20. https://foldoc.org/QEMM386
  21. https://tldp.org/HOWTO/Linux-i386-Boot-Code-HOWTO/setup.html
  22. https://www.os2museum.com/wp/the-a20-gate-it-wasnt-wordstar/
  23. https://www.os2museum.com/wp/exepack-and-the-a20-gate/
  24. http://info.wsisiz.edu.pl/~bse26236/batutil/help/HIMEM_S.HTM
  25. https://datasheet.octopart.com/80486DX2-66-Intel-datasheet-7086155.pdf
  26. https://ardent-tool.com/CPU/docs/Intel/Pentium/241428-004.pdf
  27. https://download.intel.com/design/mobile/SPECUPDT/31407918.pdf
  28. https://www.intel.com/content/dam/doc/datasheet/x58-express-chipset-datasheet.pdf
  29. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf
  30. https://www.scs.stanford.edu/05au-cs240c/lab/amd64/AMD64-2.pdf
  31. https://stackoverflow.com/questions/57747807/who-enables-the-a20-line-when-booting-in-pure-uefi
  32. https://www.thejat.in/learn/the-a20-line
  33. https://forum.osdev.org/viewtopic.php?t=29410
  34. https://en.wikibooks.org/wiki/X86_Assembly/Bootloaders
  35. https://www.reddit.com/r/osdev/comments/a20q4j/change_status_of_a20_line_when_qemu_starts/
  36. https://sourceforge.net/p/bochs/bugs/1061/
  37. https://github.com/spark2k06/PCXT_MiSTer
  38. https://www.delkin.com/blog/understanding-controls-applications-embedded-systems/
  39. https://connortumbleson.com/2021/07/19/the-xbox-and-a20-line/
  40. https://www.basicinputoutput.com/2024/11/grandpa-tell-me-story-again-about-a20.html
Add your contribution
Related Hubs
User Avatar
No comments yet.