Forem: Raymond Mwaura

Transitioning to Protected Mode in BeaconOS

Raymond Mwaura — Thu, 06 Nov 2025 19:50:52 +0000

Date: 2025-11-06
Author: Raymond Mwaura

In the previous post, I explored enabling the A20 line to prepare the system for accessing memory beyond the 1 MB boundary. With that foundation in place, I moved on to something I’ve been eagerly anticipating: switching the CPU from real mode to protected mode.

This post documents that process, explains what protected mode is, and walks through the implementation details and challenges I encountered while bringing BeaconOS into a 32-bit environment.

Understanding Protected Mode

Protected mode was introduced with the Intel 80286 processor. It comes with several features missing in real mode:

4 GB of addressable memory.
Memory segmentation using the Global Descriptor Table (GDT).
Virtual memory support through paging.
Four privilege levels (0-3).
Hardware-enforced isolation between user and kernel space.

Protected mode allows software to take full advantage of the CPU’s capabilities.

It’s also worth noting that BIOS interrupts are not available in protected mode. I actually like this for the exact reason many people don’t: it forces me to handle everything manually. That makes protected mode feel much more “low-level”; which is exactly what drew me to operating system development in the first place. I have a feeling this will be both fun and painful.

Before switching modes, two conditions must be met:

The A20 line must be enabled (covered in the previous post).
A proper Global Descriptor Table (GDT) must be defined and loaded.

Implementation

Transitioning to protected mode involves several carefully ordered steps. Each must be executed correctly; a single mistake can trigger a triple fault and reset the system. Below is the process I used in BeaconOS, along with explanations for each stage.

Throughout this process, interrupts were disabled (cli) to prevent any control transfer during the transition.

1. Loading the Global Descriptor Table (GDT)

Protected mode uses descriptors to define memory segments, rather than fixed segment values. These descriptors are stored in the GDT.

For my setup, I created a simple GDT with three entries:

Null Descriptor; required placeholder.
Kernel Code Segment Descriptor; defines executable memory space.
Kernel Data Segment Descriptor; defines readable/writable memory space.

; GDT
gdt_start:
    ; Null descriptor.
    dd 0
    dd 0

; Kernel code segment descriptor.
; Limit=0xFFFFF, Base=0.
; Access byte: present bit set, ring 0, code segment, read allowed.
; Flags: granularity is set, 32-bit segment.
kernel_code:
    dw 0xFFFF       ; Lower limit.
    dw 0            ; Base (0-15).
    db 0            ; Base (16-23).
    db 0b10011010   ; Access byte.
    db 0b11001111   ; Flag + higher limit.
    db 0            ; Base (24-31).

; Kernel data segment descriptor.
; Limit=0xFFFFF, Base=0.
; Access byte: present bit set, ring 0, data segment, write allowed.
; Flags: granularity is set, 32-bit segment.
kernel_data:
    dw 0xFFFF       ; Lower limit.
    dw 0            ; Base (0-15).
    db 0            ; Base (16-23).
    db 0b10010010   ; Access byte.
    db 0b11001111   ; Flag + higher limit.
    db 0            ; Base (24-31).

gdt_end:

gdt_descriptor:
    dw (gdt_end - gdt_start - 1)
    dd gdt_start

Once defined, I loaded the GDT using the lgdt instruction. This instruction loads the base address and limit of the GDT (Global Descriptor Table) from memory into the CPU's GDTR (Global Descriptor Table Register). This tells the CPU where the GDT is and how large it is.

lgdt [gdt_descriptor]

2. Enabling Protected Mode

With the GDT loaded, I set the Protection Enable (PE) bit in the control register CR0. This single bit flips the CPU from real mode to protected mode.

mov eax, cr0
or eax, 1
mov cr0, eax

However, simply setting the bit isn’t enough; the instruction prefetch queue must be flushed. To do that, I performed a far jump to a 32-bit code segment:

jmp 0x08:protected_mode_entry

This jump clears the queue and loads the new code segment selector (0x08, the kernel code segment) from the GDT into the cs register. At this point, the CPU is officially running in protected mode.

3. Initializing and Testing Protected Mode

At the protected_mode_entry label, the CPU executes in 32-bit protected mode. The next step is to reload the segment registers (ds, es, ss, etc.) to point to the data segment defined in the GDT.

bits 32
protected_mode_entry:
    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov gs, ax
    mov ss, ax

I then tested the mode switch by printing a string. Since BIOS interrupts no longer work, I wrote directly to the VGA text buffer (0xB8000).

protected_mode_entry:
    ; After reloading the segment registers.

    ; Clear the screen.
    mov edi, 0xB8000    ; VGA text buffer.
    mov ecx, (80 * 25)  ; Counter.
    mov eax, 0x0720     ; 0x20 = ' ', 0x07 = light gray on black.
    rep stosw

    ; Print a message.
    lea esi, [success_msg]
    mov edi, 0xB8000
    mov ah, 0x07        ; Attribute: light gray on black.

    .print_loop:
        lodsb
        cmp al, 0
        jz done

        mov [edi], al       ; Write character.
        mov [edi + 1], ah   ; Write attribute.
        add edi, 2          ; Advance pointer.

        jmp .print_loop

done:
    hlt
    jmp done

;; VARIABLES.
success_msg db "Switched to protected mode successfully.", 0

That message appearing on-screen confirmed that BeaconOS had successfully entered protected mode; easily one of the most satisfying milestones so far.

Full Code

Here’s the full second-stage bootloader responsible for switching to protected mode.
(Note: this assumes the A20 line is already enabled; QEMU does this by default.)

org 0x7E00
bits 16

cli

; Load the GDT.
lgdt [gdt_descriptor]

; Set PE bit.
mov eax, cr0
or eax, 1
mov cr0, eax

jmp 0x08:protected_mode_entry

; GDT
gdt_start:
    ; Null descriptor.
    dd 0
    dd 0

; Kernel code segment descriptor.
; Limit=0xFFFFF, Base=0.
; Access byte: present bit set, ring 0, code segment, read allowed.
; Flags: granularity is set, 32-bit segment.
kernel_code:
    dw 0xFFFF       ; Lower limit.
    dw 0            ; Base (0-15).
    db 0            ; Base (16-23).
    db 0b10011010   ; Access byte.
    db 0b11001111   ; Flag + higher limit.
    db 0            ; Base (24-31).

; Kernel data segment descriptor.
; Limit=0xFFFFF, Base=0.
; Access byte: present bit set, ring 0, data segment, write allowed.
; Flags: granularity is set, 32-bit segment.
kernel_data:
    dw 0xFFFF       ; Lower limit.
    dw 0            ; Base (0-15).
    db 0            ; Base (16-23).
    db 0b10010010   ; Access byte.
    db 0b11001111   ; Flag + higher limit.
    db 0            ; Base (24-31).

gdt_end:

gdt_descriptor:
    dw (gdt_end - gdt_start - 1)
    dd gdt_start

; ========== Protected Mode Code ==========
bits 32
protected_mode_entry:
    ; Setup segment registers.
    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov gs, ax
    mov ss, ax

    ; Clear the screen.
    mov edi, 0xB8000    ; VGA text buffer.
    mov ecx, (80 * 25)  ; Counter.
    mov eax, 0x0720     ; 0x20 = ' ', 0x07 = light gray on black.
    rep stosw

    ; Print a message.
    lea esi, [success_msg]
    mov edi, 0xB8000
    mov ah, 0x07        ; Attribute: light gray on black.

    .print_loop:
        lodsb
        cmp al, 0
        jz done

        mov [edi], al       ; Write character.
        mov [edi + 1], ah   ; Write attribute.
        add edi, 2          ; Advance pointer.

        jmp .print_loop

done:
    hlt
    jmp done

;; VARIABLES.
success_msg db "Switched to protected mode successfully.", 0

times 512 - ($ - $$) db 0

Reflections

Switching to protected mode felt like putting on the Infinity Gauntlet; moving from the cramped limitations of real mode into a true 32-bit environment with far more power and control. This step deepened my understanding of how an operating system seizes control of the hardware at its most fundamental level.

It also reinforced one key lesson: precision is everything in low-level programming. Every byte in the GDT, every instruction in the bootloader, and every bit in a control register matters. One wrong value can mean hours of painful debugging and questioning of life choices.

What’s Next

Now that BeaconOS runs in protected mode, the next step is learning C.

I’ve decided to pause kernel development until I’ve strengthened my C programming skills. Since the BeaconOS kernel will be written primarily in C (with some assembly), mastering the language will make development cleaner, faster, and less error-prone. It’ll also prevent the kind of subtle bugs that come from half-understanding the fundamentals.

I’m genuinely excited about this next phase. I can't wait to learn C and meet the infamous pointers everyone keeps warning me about.

Resources

The complete source code, along with development notes and comments, is available in the this repository.

Enabling the A20 Line in BeaconOS

Raymond Mwaura — Wed, 29 Oct 2025 11:39:18 +0000

Date: 2025-10-29
Author: Raymond Mwaura

Introduction

This past week, I have been working on enabling the A20 line, as part of the early boot sequence for BeaconOS.

The A20 line, or the 21st address line refers to a specific signal on the system bus that controls the CPU's ability to access memory beyond the first megabyte. Enabling the A20 line is essential because it allows the CPU to access memory beyond the 1MB limit.

Historical Context

The Intel 8088 microprocessor had 20 address lines (A0-A19). This allowed it to access a maximum of 2²⁰ bytes, or 1 MB of RAM. The processor used a segmented memory model to form a 20-bit physical address from two 16-bit values (a segment and an offset), calculated as (segment * 16) + offset.

Due to the 20-bit address bus, any attempt to access an address beyond 1 MB resulted in the 21st bit being silently truncated. For example, the address FFFF:0010 would be calculated as 0xFFFF0 + 0x0010 = 0x100000. However, since the 8088 only had 20 address lines, the 1 at bit 20 was lost, causing the address to wrap around to 0x00000. Some programmers, seeking performance optimizations, began to rely on this wrap-around behavior.

When IBM introduced the PC AT (1984) based on the Intel 80286, a significant problem emerged. The 286 had 24 address lines, enabling it to access up to 16 MB of memory. In its real mode (intended for 8086 compatibility), the 286 did not force the A20 line to zero. Consequently, addresses above 1 MB no longer wrapped around to zero. Programs that depended on the old wrap-around behavior would now access unexpected memory regions above 1 MB, causing them to malfunction or crash.

To maintain compatibility with 8086 software, IBM introduced a mechanism to forcibly control the A20 address line. This was the "A20 gate" or "Gate A20". When this gate was disabled (the default state at boot), the A20 line was forced to zero, mimicking the 8088's wrap-around behavior. When enabled, the A20 line could carry its true signal, allowing the CPU to access the full range of physical addresses. The gate was originally implemented by routing the A20 line through an AND gate controlled by a spare pin on the Intel 8042 keyboard controller.

Methods for Controlling the A20 Gate

The primary method involved the Keyboard Controller. In this, commands were sent to I/O ports 0x64 and 0x60 to set the A20 bit. This method was notoriously slow and required careful status polling.

A faster alternative, the System Control Port A (or Fast A20 Gate), utilized I/O port 0x92. Setting bit 1 of this port would enable the A20 line. This method was significantly faster and simpler than the keyboard controller approach.

A third approach was through a BIOS Interrupt. By invoking the BIOS interrupt INT 0x15, with AX=0x2401, software could request the BIOS to enable the A20 line. This method was simple and abstracted the hardware details, but its major drawback was inconsistent support across different BIOS versions.

Operating systems would attempt several methods to ensure successful activation.

Implementation

To enable the A20 line, I implemented two common methods:

BIOS Interrupt (INT 15h, Function 24h)
Fast A20 Gate (port 0x92)

The program begins by checking whether the A20 line is already active. If it is, execution ends immediately with a success message. If not, the system first attempts to enable it using the BIOS interrupt. Should that fail (likely due to BIOS incompatibility), the program falls back to the fast A20 gate method.

If all attempts fail, the program halts and reports the failure. The logic ensures graceful fallback and clear reporting at each stage.

; Test A20.
call test_a20
cmp al, 1
je  a20_enabled ; If enabled.
jmp bios_enable ; If disabled.

bios_enable:
    lea si, [bios_attempt_msg]
    call print_string

    mov ah, 0x24
    mov al, 0x01
    int 0x15
    jc fast_a20_enable

    call test_a20
    cmp al, 1
    je a20_enabled
    jmp fast_a20_enable

fast_a20_enable:
    lea si, [fast_a20_attempt_msg]
    call print_string

    in al, 0x92
    or al, 0x02
    out 0x92, al

    call test_a20
    cmp al, 1
    je a20_enabled
    jmp a20_disabled

a20_enabled:
    lea si, [a20_enabled_msg]
    call print_string
    jmp done

a20_disabled:
    lea si, [a20_disabled_msg]
    call print_string
    jmp done

done:
    cli
    hlt

Explanation

Initial check:
The program begins by calling test_a20 to verify whether the A20 line is already enabled. If it is, execution jumps directly to a20_enabled.
BIOS Method:
If the A20 line is disabled, the BIOS interrupt INT 15h (Function 24h, Subfunction 01h) is invoked to enable it. Some BIOS implementations provide this service, but many modern systems do not.
Fallback to Fast A20 Gate:
If the BIOS call fails (as indicated by the Carry Flag) or if the test still shows A20 is disabled, the program attempts the fast A20 gate method. This method writes to I/O port 0x92, setting bit 1 to enable the A20 line directly via the system control port.
Final verification:
After each enabling attempt, test_a20 is called again to confirm success. The program prints a message indicating the result and halts cleanly.

This dual-method approach increases compatibility across different hardware and firmware environments, ensuring the A20 line is enabled regardless of BIOS support.

Verification

To verify whether the A20 line is enabled, I used a helper function, test_a20. It performs the check using two methods: a BIOS test and a memory wraparound test.

; ---------------------------------------------------------------
; Test if A20 is enabled or disabled using either
; BIOS subfunction 02h, or
; memory wraparound method.
; Return value: Places the current A20 state in the AL register.
;   1: Enabled
;   2: Disabled
; ---------------------------------------------------------------
test_a20:
    call bios_test_a20
    cmp al, 2
    jb .test_return

    call memory_test_a20
    jmp .test_return

    .test_return:
        ret

The BIOS test (INT 15h, Function 24h, Subfunction 02h) checks the A20 state directly if the BIOS supports it.

; ---------------------------------------------------------------
; Test if A20 is enabled using BIOS subfunction 02h.
; Return value: Places the current A20 state in the AL register.
;   0: Disabled
;   1: Enabled
;   2: Error
; ---------------------------------------------------------------
bios_test_a20:
    mov ah, 0x24
    mov al, 0x02
    int 0x15
    jc .bios_test_fail

    cmp al, 1
    je .bios_a20_enabled
    jmp .bios_a20_disabled

    .bios_a20_enabled:
        mov al, 1
        jmp .bios_test_return

    .bios_a20_disabled:
        mov al, 0
        jmp .bios_test_return

    .bios_test_fail:
        mov al, 2
        jmp .bios_test_return

    .bios_test_return:
        ret

If the BIOS does not support this interrupt, the function falls back to the memory wraparound test, which is more hardware-oriented and universally reliable.

This method compares memory contents at two addresses: 0x000000 and 0x100000.
If the A20 line is disabled, both addresses point to the same physical location (due to 20-bit address wraparound), and the values read back are identical.
If the A20 line is enabled, they reference different memory cells, producing distinct values.

; ------------------------------------------------------------------------
; Test whether A20 is enabled or disabled using memory wraparound method.
; Return value: Places the current A20 state in the AL register.
;   1: Enabled
;   2: Disabled
; ------------------------------------------------------------------------
memory_test_a20:
    push ds
    push es
    push si
    push di

    mov ax, 0x0000
    mov ds, ax
    mov si, ax

    mov ax, 0xFFFF
    mov es, ax
    mov di, 0x0010

    ; Preserve original values.
    mov al, [ds:si]
    push ax
    mov al, [es:di]
    push ax

    ; Write.
    mov byte [es:di], 0x00
    mov byte [ds:si], 0xFF

    ; Read.
    mov al, [es:di]
    cmp al, 0xFF
    je .memory_a20_disabled
    jmp .memory_a20_enabled

    .memory_a20_enabled:
        mov al, 1
        jmp .memory_test_ret

    .memory_a20_disabled:
        mov al, 0
        jmp .memory_test_ret

    .memory_test_ret:
        ; Restore original values.
        pop bx
        mov [es:di], bl
        pop bx
        mov [ds:si], bl

        pop di
        pop si
        pop es
        pop ds

        ret

Explanation

BIOS Test:
Uses INT 15h, AX=2402h to query the BIOS for the A20 state. If supported, this method is simple and direct. If unsupported, the Carry Flag is set, and the test returns an error code (AL=2).
Memory Wraparound Test:
Performs a direct hardware-level test by writing and comparing memory values.

If values at 0x000000 and 0x100000 are identical, the A20 line is disabled (address wraparound occurred).
If they differ, the A20 line is enabled. After testing, the function restores the original memory contents to prevent corruption.

Return Values: The final A20 state is stored in the AL register:

1; Enabled
0; Disabled
2; Error or unsupported BIOS call

This layered verification ensures reliability across systems and helps confirm that the A20 line is properly active.

Conclusion and Next Step

Enabling the A20 line marks a significant milestone in the early development of BeaconOS. It sets the stage for the transition to protected mode; a part of the journey I've been anticipating since the start. I'm excited to finally take that step and see BeaconOS come to life in a more capable environment.

The complete source code and accompanying notes are available in this repository.

Building BeaconOS From Scratch

Raymond Mwaura — Wed, 22 Oct 2025 15:48:13 +0000

Hi there! My name is Raymond Mwaura, and I’m deeply passionate about low-level programming. My main focus is Operating System development.

For the past five months, I’ve been steadily learning the fundamentals of how computers really work beneath the surface. During this time, I’ve explored topics such as:

Computer architecture and how hardware components interact.
Number systems (decimal, hexadecimal, and binary) and how they relate to data representation.
Assembly language, learning syntax, instructions, and how to write efficient low-level routines.
BIOS interrupts, understanding how early system software communicates with hardware.
The real mode memory model, and how it shapes the earliest stages of system execution.
Bootloader development, including how to load a second-stage bootloader into memory.

Right now, I’m working on enabling the A20 line; a crucial step that allows access to memory beyond the 1MB boundary on x86 systems. Once that’s working, my next milestone is switching to protected mode.

Why I’m Building an Operating System

I’m developing an educational OS called BeaconOS. The name Beacon represents guidance; a light for learners navigating the often complex and confusing world of operating system development. My goal is for BeaconOS to become a practical learning tool that helps others understand how every part of an operating system works.

Looking Ahead

This blog will document my journey; the progress, the mistakes, and the lessons learned along the way. I’ll be sharing insights, technical deep dives, and reflections as BeaconOS evolves.

If you’re interested in systems programming, low-level computing, or just curious about how operating systems are built, I’d love to have you along for the ride.

Welcome to my journey; and to the story of BeaconOS.