Your machine is already running when this lab begins. A bootloader — Limine, provided by the course — has done the unglamorous work: it walked the firmware's memory map, built page tables, switched the CPU into 64-bit long mode, and called a function you are about to write. You start where the interesting part starts: with the whole machine at your feet and nothing between your code and the hardware. (By the end of the course nothing in that sentence will be mysterious, and an optional arc lets you replace the bootloader with your own.)
What the bootloader hands you
Your kernel's entry point receives one argument: a pointer to a BootInfo
struct. It is a flat, C-layout record — the contract between any bootloader and
this kernel, and the one interface in this course that never changes shape. For
this lab, one field matters: the framebuffer.
The framebuffer is the screen, with all pretence removed. The graphics hardware
scans out a rectangle of memory; whatever bytes sit there are whatever pixels
you see. BootInfo.fb tells you everything needed to write into it:
addr— the virtual address of pixel (0, 0), already mapped and writablewidth,height— the mode's dimensions in pixelsbpp— bits per pixel; this course's target mode is 32 (oneu32per pixel,0x00RRGGBB)pitch— bytes per row, and the field that separates working code from folklore: rows may carry padding, so the pixel at (x, y) lives ataddr + y*pitch + x*4, never ataddr + (y*width + x)*4. The two formulas agree on many machines and then one day, on someone else's, they don't.
Volatile, or the compiler will "help"
Writing pixels is writing to memory that hardware reads behind the compiler's
back. To the optimizer, a buffer nobody ever loads from is a buffer whose
stores can be deleted. write_volatile is the instruction to leave the store
alone; the scaffold's Fb::plot uses it, and every device the course touches
from here on will repeat the same pattern.
Why the screen, first
Two reasons. The honest one: drawing on bare metal in your first hour is the point — a picture your own kernel produced is proof the machine is really yours. The engineering one: the framebuffer needs no driver, no interrupts, no setup — it is the one piece of hardware you can command with nothing but a pointer and arithmetic, which makes it the right first exercise in being the operating system: nobody catches your mistakes anymore, and nothing happens unless you make it happen.