Building a Bootloader from Scratch — Just Assembly, No OS

Field notes on a hand-written Stage-1 x86 bootloader — raw assembly, no operating system, no standard library. Boots directly from BIOS. The exercise isn't nostalgic; it surfaces every layer of abstraction that hides between your code and the silicon.

⚠️ Status: Draft skeleton — subsumes the older draft bootloader-from-scratch.md (351 words, never published). Once this file is complete, delete the older draft.

Companion assets

• Original video:

  How to Build a Bootloader from Scratch — Just Assembly, No OS

  (597 views, 20 likes — second-highest performer on SecurityLab)
• GitHub: harrison001/NanoBoot — minimal x86 bootloader framework (<5KB, protected mode + GDT/IDT + scheduler)
• GitHub: harrison001/bootloader — original simpler version

TL;DR

A bootloader is the first code your CPU runs that you wrote. No OS to fall back on, no libc, no malloc, no syscalls — just 512 bytes the BIOS reads from the disk’s first sector. Writing one teaches you what every higher abstraction is hiding: how a CPU starts in 16-bit mode with one MB of addressable memory, how I/O is done by talking directly to BIOS interrupts, and what “loading the next stage” really means before the OS exists.

What the BIOS gives you

When your machine powers on, the BIOS:

1. Initializes hardware
2. Reads sector 0 of the boot disk (512 bytes) into memory at 0x7C00
3. Verifies the last two bytes are 0xAA 0x55 (the boot signature)
4. Jumps to 0x7C00 and lets your code run

That’s everything. No filesystem. No memory manager. No drivers. Just real-mode x86 and BIOS interrupts.

Debug command transcript

# TODO: paste actual nasm + qemu workflow from the video
# nasm -f bin boot.asm -o boot.bin
# qemu-system-i386 -drive format=raw,file=boot.bin
# (or with GDB attached: qemu-system-i386 -drive format=raw,file=boot.bin -s -S)

What this teaches backend / AI infra engineers

The bootloader exercise is famously “not useful at work.” That’s wrong. The lessons translate directly:

• You learn what’s actually a syscall. When you call printf in C, you eventually hit write() → kernel → device driver. In the bootloader, “print” is int 0x10 directly to BIOS. Seeing the raw form makes every higher-level I/O cost visible.
• You learn what memory addresses really are. In real mode there’s no virtual memory; [0x7C00] is exactly byte 31,744. In production Go, *ptr looks the same in C-syntax but goes through page tables, TLB, and kernel mappings. Knowing the difference is the basis of every “why is this slow” investigation that involves memory.
• You learn what “no abstraction” feels like. Every line is conscious. There’s no runtime.gc() happening behind you, no malloc() to free, no exception you didn’t expect. This is the baseline against which all higher-level systems should be evaluated for “what is this layer actually adding?”

For AI infrastructure: every layer between your code and the GPU is doing similar work to a bootloader — initializing state, loading the next stage, handing off control. Knowing what that looks like at the simplest level makes every “GPU initialization is slow” debugging session faster.

Related work

• Video: Debugging Real-Mode Bootloader in GDB
• Video: From Real Mode to Protected Mode (GDT/IDT)
• GitHub: NanoBoot

I occasionally advise small teams on backend reliability, Go performance, and production AI systems. Learn more: /services