Run DOOM
The final boss. Port doomgeneric onto everything you've built — your filesystem loads the WAD, your framebuffer is its screen, your keyboard is its input. When the title screen appears, you've proven it's a real OS.
DOOM is the universal "is this a real computer" test for a reason: it needs a framebuffer, timed input, memory, and file loading — a cross-section of everything an OS provides. You've built every one of those. This module wires them to doomgeneric, a clean DOOM port designed to be dropped onto new platforms.
7.1 Why DOOM is the benchmark
DOOM isn't magic — it needs exactly four things, and you built all of them: a framebuffer to draw into (Module 03), timed input from the keyboard (Module 02), a memory allocator (Module 02), and file loading for its WAD data (Module 05). Porting it is really just connecting your OS's versions of those four things to the interface doomgeneric expects.
7.2 doomgeneric's porting layer
doomgeneric hides all the DOOM internals behind five callbacks you implement. Fill these in with your OS's primitives and the game runs. That's the entire port surface:
void DG_Init(void) { } // one-time setup
void DG_DrawFrame(void) {
// DG_ScreenBuffer is 320x200 (scaled); blit it to your framebuffer
blit_scaled(DG_ScreenBuffer, framebuffer);
}
void DG_SleepMs(UINT32 ms) { sleep_ticks(ms); }
UINT32 DG_GetTicksMs(void) { return ticks * MS_PER_TICK; }
int DG_GetKey(int *pressed, unsigned char *key) {
// pull from the keyboard queue you built in Module 2.5
return key_queue_pop(pressed, key);
}7.3 Framebuffer, input, timer, WAD
Each hook maps to a system you already have. DG_DrawFrame scales DOOM's 320×200 buffer up to your resolution and copies it — your compositor's blitter. DG_GetKey translates your scancodes to DOOM's key codes. DG_GetTicksMs reads your timer. And DOOM's WAD file loads through your FAT32 reader. Six modules of work, all converging on one game loop.
DOOM has its own key constants (KEY_UP, KEY_FIRE, etc.). Your keyboard produces raw scancodes. The one tedious-but-simple task is a lookup table mapping your scancodes to DOOM's keys — arrow keys to movement, ctrl to fire, and so on. It's a table, not an algorithm; just fill it in.
7.4 It runs — and the licence you must respect
Build it, load the shareware WAD off your filesystem, and boot. The DOOM title screen on an OS you wrote from an empty file, on real hardware, is the moment this whole course was building toward. Record it — it's the single best proof you can show that you built something real.
doomgeneric is licensed GPL-2.0. Learning from it and building on it is completely fine. But if you distribute a binary that statically links it, that combined work falls under the GPL — so keep your DOOM port a clearly-separate, GPL-labelled module, and don't bundle it into a proprietary OS image you sell. Use the shareware WAD (freely redistributable), never a retail one. Teaching this is fine; shipping it commercially without honouring the licence is not.
- doomgeneric's five hooks implemented against your OS
- DOOM's frame buffer scaled and blitted to your framebuffer
- Scancodes translated to DOOM's key codes
- The WAD loaded off your own FAT32 filesystem
- DOOM running on your OS — on real hardware
You started with an empty file. You now have an operating system — memory management, a compositor, windows, a desktop, a filesystem, a network stack — that boots on real hardware and runs DOOM. That's not a tutorial exercise. That's a real system you built and understand from the firmware up. Go record the boot, and show the world.