Before the kernel, there is a sector
This project is a deliberately small answer to a large systems question: what does a computer actually do before an operating system exists? Classic BIOS looks for bootable media, reads the first 512 bytes into memory at 0x007C00, checks for the 0x55AA signature, and transfers control to the code it loaded.
That is an unusually good learning boundary. There is no filesystem abstraction, no process model, and no convenient runtime. The program has to establish enough state to make the next instruction predictable.
The boot chain
BIOS / POST
│ read sector 0
▼
0x007C00 ──► 512-byte boot sector ──► larger bootloader ──► kernel ──► OS
real modeThe repository’s own notes use the experiment to contrast real mode with protected mode. Real mode gives early code direct BIOS access but no modern memory protection or multitasking. A larger loader such as GRUB can then take over the work that cannot fit into the first sector.
The implementation surface
bootloader.asm is the source of truth. The first-stage code initializes the early execution environment, configures segment registers, establishes a stack, and leaves a compact base for a future handoff. boot.com is the assembled binary that makes the size constraint visible rather than theoretical.
| Artifact | Role in the experiment |
|---|---|
bootloader.asm | Human-readable x86 assembly source. |
boot.com | Flat assembled boot-sector artifact. |
bochsrc.txt | Emulator configuration for a repeatable boot. |
bochsout.txt | Captured emulator output for inspection. |
README.md | Notes on BIOS, POST, real mode, protected mode, and chainloading. |
The build path stays intentionally direct:
nasm -f bin bootloader.asm -o boot.com
bochs -f bochsrc.txtWhy the 512-byte limit is useful
A bigger program can hide a surprising amount of state behind libraries and conventions. A boot sector cannot. The limit forces a direct relationship between each instruction and the machine state it prepares. It also clarifies why classic BIOS does not simply load an entire operating system: BIOS knows how to read sector zero and check a signature, not how to parse every filesystem and locate a kernel.
The “x64” label is therefore a useful point of discussion rather than a claim that the first instruction executes in a modern 64-bit environment. The initial firmware handoff begins in the historical real-mode setup; protected-mode and long-mode transitions belong to later stages.
Evidence map
bootloader.asmcontains the compact boot-sector implementation.boot.comshows the assembled flat binary that must fit the boot-sector boundary.bochsrc.txtmakes the emulator invocation reproducible.bochsout.txtpreserves a run artifact for inspection.- The repository documents the BIOS load address, boot signature, real-mode constraints, and chainloading model.
Limits and next stage
This is an educational first-stage boot experiment, not a complete operating-system loader. It does not parse filesystems, load a kernel, transition through protected mode, or provide a full long-mode runtime. Those limits are exactly what make the project useful: it isolates the first handoff instead of claiming to be an OS.