16-bit x86: real mode and the 8086

A 64-bit x86 processor that boots through a legacy BIOS runs its first instructions in a 16-bit mode that reaches only 1 MiB, the 1,048,576 bytes of the 8086’s 20-bit address space. That mode, real mode, is how every x86 machine still starts, so boot loaders, firmware and the 8086 labs of many universities all live in it.

Real mode forms each address as segment x 16 + offset, from two 16-bit numbers. A BIOS copies 512 bytes to 0x7C00 and runs them in this mode; you will build such a sector and prove its layout from its bytes.

Real mode builds a 20-bit address from a segment and an offset

The 8086 has eight 16-bit general-purpose registersgeneral-purpose register: A register a program may freely use for integer values and addresses, as opposed to a special register with a fixed job. x86-64 has 16 (rax..r15), AArch64 31 (x0..x30) and RISC-V 32 (x0..x31). More in “Registers on x86-64, AArch64 and RISC-V”: ax, bx, cx and dx, whose halves are al, ah and so on, and si, di, bp and sp, which mostly hold addresses. One 16-bit register reaches only 64 KiB, so four segment registerssegment register: One of the x86 registers cs, ds, ss and es (later also fs and gs) that selects a segment of memory. In real mode its value times 16 is the base address of the segment. extend it: cs for code, ds for data, ss for the stack and es for a second data area. ip holds the next instruction’s offset.

In real modereal mode: The 16-bit mode every x86 processor starts in, inherited from the 8086. An address is segment x 16 + offset, about 1 MiB is reachable, and there is no memory protection or privilege check. the processor shifts the segment left by 4 bits, multiplying it by 16, and adds the offset, so 07C0:0000 and 0000:7C00 name one physical addressphysical address: The address that reaches the memory bus after any translation the processor does. In real mode it is segment x 16 + offset; with paging it is the address a virtual address maps to., 0x07C00 (Intel’s manual, real-address mode). FFFF:FFFF gives 0x10FFEF, past 1 MiB: the 8086 had 20 address lines and wrapped it to 0x0FFEF, while later processors keep the carry unless the A20M# signal masks address line 20A20 line: Address line 20 of an x86 processor, the 21st address bit. The 8086 had only 20 lines, so its addresses wrapped at 1 MiB; later processors could mask line 20 with the A20M# signal to imitate that wrap..

"""Real-mode addresses: physical = segment x 16 + offset, for a few pairs.

The 8086 had 20 address lines, so a sum above 0xFFFFF lost its carry and wrapped
to the bottom of memory. Later processors keep the carry on address line 20 (A20)
unless the A20M# signal masks it, so one pair can name two different bytes.
"""

ONE_MIB = 1 << 20  # 1,048,576 bytes: all that 20 address lines can reach


def physical(segment: int, offset: int) -> int:
    """The address formed when line A20 is enabled: no wrap."""
    return (segment << 4) + offset


def on_8086(segment: int, offset: int) -> int:
    """The 8086 drops the carry out of bit 19, so the sum wraps at 1 MiB."""
    return physical(segment, offset) % ONE_MIB


def pairs_naming(address: int) -> int:
    """How many segment:offset pairs name one byte below 1 MiB."""
    lowest = max(0, -(-(address - 0xFFFF) // 16))  # first segment that reaches it
    highest = min(0xFFFF, address // 16)  # last segment that starts at or below it
    return highest - lowest + 1


PAIRS = [
    (0x07C0, 0x0000, "the boot sector, as one BIOS loads it"),
    (0x0000, 0x7C00, "the same byte through another pair"),
    (0xB800, 0x0000, "colour text video memory"),
    (0xF000, 0xFFF0, "the reset CS:IP by the normal rule"),
    (0xFFFF, 0x0010, "one byte past the first MiB"),
    (0xFFFF, 0xFFFF, "the highest pair of all"),
]

print("pair        segment*16+offset  8086 (wraps)  note")
for segment, offset, note in PAIRS:
    full = physical(segment, offset)
    wrapped = on_8086(segment, offset)
    print(
        f"{segment:04X}:{offset:04X}   0x{full:06X}           0x{wrapped:05X}       {note}"
    )

print()
for address in (0x00000, 0x07C00, 0xB8000, 0xFFFF0):
    print(f"pairs that name 0x{address:05X}: {pairs_naming(address)}")
above = physical(0xFFFF, 0xFFFF) - ONE_MIB + 1
print(f"bytes above 1 MiB that real mode reaches with A20 on: {above}")

pair        segment*16+offset  8086 (wraps)  note
07C0:0000   0x007C00           0x07C00       the boot sector, as one BIOS loads it
0000:7C00   0x007C00           0x07C00       the same byte through another pair
B800:0000   0x0B8000           0xB8000       colour text video memory
F000:FFF0   0x0FFFF0           0xFFFF0       the reset CS:IP by the normal rule
FFFF:0010   0x100000           0x00000       one byte past the first MiB
FFFF:FFFF   0x10FFEF           0x0FFEF       the highest pair of all

pairs that name 0x00000: 1
pairs that name 0x07C00: 1985
pairs that name 0xB8000: 4096
pairs that name 0xFFFF0: 4096
bytes above 1 MiB that real mode reaches with A20 on: 65520

1985 pairs name 0x07C00, every byte from 0x0FFF0 to the top of the first MiB has 4,096 names, and with A20 enabled real mode reaches 65,520 bytes above 1 MiB.

Every x86 processor still leaves reset in real mode

Reset puts an x86 processor of any generation in real mode. Intel’s manual gives the state: the visible cs selector holds F000H, its hidden base FFFF0000H and eip FFF0H, so the first fetch, the reset vectorreset vector: The address a processor fetches its first instruction from after a reset. On x86 it is FFFFFFF0H, 16 bytes below 4 GiB, where the board maps its firmware., is at FFFFFFF0H, just below 4 GiB, where the board keeps its firmware. The first far jump reloads cs, and the segment x 16 rule holds from then on.

The firmware decides how long real mode lasts. A legacy BIOSBIOS: Basic Input/Output System, the firmware of the original PC design. It tests and sets up the hardware, offers services through software interrupts, and boots a disk by running its first sector at 0x7C00 in real mode. starts a 512-byte boot sector in real mode. UEFIUEFI: Unified Extensible Firmware Interface, the firmware standard that replaced the PC BIOS. On x64 machines it switches the processor to 64-bit long mode itself and starts the operating-system loader as a 64-bit program. firmware switches an x64 processor to 64-bit long modelong mode: The 64-bit mode of x86-64 processors, which Intel calls IA-32e mode, with 64-bit registers and paging always on. Operating systems run in it, and UEFI firmware on x64 machines starts loaders in it. itself and calls the operating-system loader as a 64-bit program (the UEFI specification, x64 platforms), so a UEFI loader never sees real mode.

A legacy BIOS runs the 512 bytes it loads at 0x7C00

A boot sectorboot sector: The first 512-byte sector of a disk. A legacy BIOS loads it at physical address 0x7C00 and jumps to it in real mode, so it holds the first code of a BIOS boot. is the first 512-byte sector of a disk. SeaBIOS, the BIOS that QEMU uses for its PC machines, reads it to 07C0:0000, refuses a hard disk whose bytes 510 and 511 are not 55 AA, and jumps to it as 0000:7C00 (its boot.c). The code must fit in front of the boot signatureboot signature: The bytes 55 AA at offsets 510 and 511 of a boot sector, the word 0xAA55 stored little-endian. A BIOS that checks it refuses to boot a hard disk whose first sector lacks it. and know its own load address.

In boot16.asm, org 0x7c00 makes NASM count labels from the load address, ds = 0 makes ds:si the plain address of the message, and times pads to byte 510 before dw 0xaa55, stored little-endianlittle-endian: The byte-order rule in which the lowest-value byte of a multi-byte value sits at the lowest address. Every mainstream x86-64, AArch64 and RISC-V system is little-endian in practice. More in “Endianness, strings and text in memory” as 55 AA. Each character leaves through COM1, the first serial portserial port: An interface that sends data one bit after another over a line, driven by a UART. PCs name their serial ports COM1, COM2 and so on, and an emulator can wire one to a terminal., and a write to port 0xF4 ends QEMU.

; boot16.asm: a 512-byte boot sector for a PC that starts in real mode.
; A legacy BIOS copies this sector to physical address 0x7C00 and jumps to it.
bits 16
org 0x7c00                  ; labels count from the load address, not from 0

start:
    cli                     ; nothing may interrupt this short program
    xor ax, ax
    mov ds, ax              ; DS = 0, so DS:SI is the physical address SI
    cld                     ; lodsb steps forward through the string
    mov si, msg

next_char:
    lodsb                   ; AL = byte at DS:SI, then SI = SI + 1
    test al, al
    jz finished             ; a zero byte ends the string
    mov bl, al
    mov dx, 0x3fd           ; COM1 line status register
wait_ready:
    in al, dx
    test al, 0x20           ; is the transmitter ready for a byte?
    jz wait_ready
    mov al, bl
    mov dx, 0x3f8           ; COM1 data register
    out dx, al
    jmp next_char

finished:
    mov al, 0x10
    out 0xf4, al            ; the exit device the QEMU command line adds
halt:
    hlt
    jmp halt

msg: db "Hello from 16-bit real mode", 13, 10, 0

times 510 - ($ - $$) db 0   ; fill the sector up to byte 510
dw 0xaa55                   ; bytes 55 AA: the boot signature

"""Assemble boot16.asm as a 512-byte boot sector and read it back."""

import pathlib
import sys

sys.path.insert(0, str(pathlib.Path(__file__).parent / "sessions"))
import session

session.run("""
# Assemble a flat binary: no header, so byte 0 of the file is byte 0 of the sector
nasm -f bin -o boot16.bin boot16.asm
# A legacy BIOS reads exactly one 512-byte sector
wc -c boot16.bin
# Offsets 510 and 511 must hold 55 AA, the boot signature
xxd -s 510 -l 2 boot16.bin
# Read the code back as 16-bit instructions at the address the BIOS loads them to
ndisasm -b 16 -o 0x7c00 boot16.bin | head -n 9
""")

# Assemble a flat binary: no header, so byte 0 of the file is byte 0 of the sector
$ nasm -f bin -o boot16.bin boot16.asm
# A legacy BIOS reads exactly one 512-byte sector
$ wc -c boot16.bin
     512 boot16.bin
# Offsets 510 and 511 must hold 55 AA, the boot signature
$ xxd -s 510 -l 2 boot16.bin
000001fe: 55aa                                     U.
# Read the code back as 16-bit instructions at the address the BIOS loads them to
$ ndisasm -b 16 -o 0x7c00 boot16.bin | head -n 9
00007C00  FA                cli
00007C01  31C0              xor ax,ax
00007C03  8ED8              mov ds,ax
00007C05  FC                cld
00007C06  BE277C            mov si,0x7c27
00007C09  AC                lodsb
00007C0A  84C0              test al,al
00007C0C  7412              jz 0x7c20
00007C0E  88C3              mov bl,al

The run proves the layout: 512 bytes, 55 AA at offset 0x1FE, and mov si,0x7c27, the message’s address after 39 bytes of code.

The script below boots the image on QEMU’s PC machine in your Linux lab. In this sector, in and out each move one byte between al and an I/O port. MASM lab programs differ from NASM mostly in directives and operands.

#!/bin/sh
# Boot boot16.bin on QEMU's PC machine, in your Linux lab.
# -drive format=raw         the file is a raw disk image: sector 0 is the boot sector
# -serial stdio             COM1 is wired to this terminal
# -display none             no window: the program talks only through COM1
# -device isa-debug-exit    an I/O port at 0xf4 that ends QEMU when the guest writes it
set -eu
nasm -f bin -o boot16.bin boot16.asm
status=0
qemu-system-i386 -drive format=raw,file=boot16.bin -serial stdio -display none \
  -device isa-debug-exit,iobase=0xf4,iosize=0x04 || status=$?
echo "qemu exit status: $status"

import pathlib
import sys

sys.path.insert(0, str(pathlib.Path(__file__).parent / "sessions"))
import linux_lab

# In the Linux lab: the sector built with NASM and booted on QEMU's PC machine, whose COM1 is this terminal.
linux_lab.run("""
sh run_on_qemu.sh
""")

$ sh run_on_qemu.sh
Hello from 16-bit real mode
qemu exit status: 33

The BIOS ran the sector, COM1 carried its message to the terminal, and the write to port 0xF4 ended QEMU, which reported status 33.

Practise: change the sector and predict the bytes

Work on copies of segaddr.py, boot16.asm and the build session, and write each prediction down before you run.

1. Add the pairs 0040:0000, 1234:5678 and FFFF:000F to PAIRS in segaddr.py, predict all three addresses, and run it.
2. Put two nop lines in front of mov si, msg in boot16.asm and predict the operand of mov si in the read-back.
3. Change dw 0xaa55 to dw 0x1234, then predict the two bytes xxd prints at offset 0x1FE.

A boot sector that prints over COM1 and exits QEMU Pro: opens with a Pro, Premium or Ultimate pass

MASM lab programs in NASM, with a translation table Pro: opens with a Pro, Premium or Ultimate pass

Interview questions

How does an 8086 turn a segment and an offset into a physical address, and why can two different pairs name the same byte?

The 8086 shifts the 16-bit segment left by 4 bits and adds the 16-bit offset, which gives a 20-bit address. Segments start every 16 bytes and span 64 KiB each, so they overlap: 07C0:0000 and 0000:7C00 both name 0x07C00. FFFF:FFFF needs 21 bits, 0x10FFEF, which the 8086 wrapped to 0x0FFEF; later processors keep the carry unless A20M# masks it.

Three harder questions from the module’s bank start where that answer stops: a sector that boots wrongly, the wrap that old software relied on, and a MASM lab program to port:

Key takeaways

• Real mode forms a 20-bit physical address as segment x 16 + offset, so one byte has many segment:offset names.
• The 8086 wrapped addresses past 0xFFFFF to 0, and later processors keep the carry unless A20M# masks line 20.
• Every x86 processor leaves reset in real mode and fetches its first instruction at FFFFFFF0H.
• A legacy BIOS runs the first 512-byte sector at 0x7C00 when it ends in 55 AA, and a boot sector’s size, signature and addresses can all be checked from its bytes.