Running DOOM on Sarrus OS - Development Plan
Maps a 6-phase plan to port DOOM (1993) onto a custom OS, covering kernel, graphics, filesystem, input, C library, and game integration.
What this file does
Maps a 6-phase plan to port DOOM (1993) onto a custom OS, covering kernel, graphics, filesystem, input, C library, and game integration.
When to use it
- Planning a hobby OS project with a concrete demo goal
- Evaluating scope and timeline for adding graphics and sound to a kernel
- Learning OS development by following a structured, milestone-based roadmap
- Porting a retro game to a custom operating system
Assumes this stack
Running DOOM on Sarrus OS - Development Plan
šÆ Project Goal
Get the classic DOOM (1993) running on Sarrus OS as a demonstration of a fully functional operating system.
š Executive Summary
Running DOOM requires a significant OS infrastructure. This is not a "bare minimum" - it's actually a comprehensive OS development project that will take several months to complete properly.
Estimated Timeline: 6-12 months of dedicated development Difficulty Level: Advanced (requires deep OS development knowledge)
šļø Architecture Overview
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā DOOM Game ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā C Library ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā System Call Layer ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā File System ā Graphics ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā Memory Manager ā Input/Sound ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā Kernel Core ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā Hardware Layer ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
š Phase 1: Core Kernel Infrastructure (2-3 months)
Memory Management System
-
Physical Memory Manager
- Page frame allocator
- Memory detection and mapping
- Reserved memory regions
-
Virtual Memory Manager
- Page directory and page tables
- Memory protection (user/kernel space)
- Memory mapping functions
-
Heap Allocator
- Kernel heap (kmalloc/kfree)
- User heap (malloc/free)
- Memory defragmentation
Process Management
-
Process Control Blocks (PCB)
- Process states and scheduling
- Context switching
- Process creation/termination
-
ELF Loader
- Parse ELF executables
- Load programs into memory
- Set up process memory layout
Interrupt and Exception Handling
-
Interrupt Descriptor Table (IDT)
- CPU exceptions (page faults, etc.)
- Hardware interrupts
- Software interrupts (system calls)
-
Timer Management
- Programmable Interval Timer (PIT)
- Scheduler timer interrupts
- System time keeping
š„ļø Phase 2: Graphics and Display (1-2 months)
VGA Graphics Support
-
VGA Mode Setup
- Switch to VGA Mode 13h (320x200, 256 colors)
- Or VESA modes for higher resolution
- Double buffering support
-
Graphics Primitives
- Pixel plotting
- Line drawing
- Rectangle filling
- Bitmap blitting
Frame Buffer Management
- Display Driver
- Frame buffer allocation
- Page flipping
- Vertical sync support
DOOM Graphics Requirements
-
Palette Management
- 256-color palette support
- Palette animation
- Color mapping
-
Scaling and Rendering
- Software rendering support
- Texture mapping helpers
- Column drawing optimization
š¾ Phase 3: File System (1-2 months)
Virtual File System (VFS)
-
VFS Layer
- File operations interface
- Directory operations
- Mount point management
-
File System Implementation
- Simple file system (SFS) or FAT32
- Directory structure
- File allocation and metadata
Disk I/O
-
ATA/IDE Driver
- Hard disk detection
- Read/write operations
- DMA support (optional but recommended)
-
File Operations
- open(), read(), write(), close()
- seek() and file positioning
- Directory listing
DOOM File Requirements
- WAD File Support
- WAD file format parsing
- Resource loading
- Asset management system
š® Phase 4: Input/Output Systems (1 month)
Keyboard Input
-
Keyboard Driver
- PS/2 keyboard interface
- Scan code translation
- Key state management
-
Input Buffer
- Keyboard event queue
- Non-blocking input
- Key repeat handling
Sound System (Optional but recommended for DOOM)
-
Sound Blaster Driver
- PC Speaker support (basic)
- Sound Blaster 16 driver (advanced)
- Audio buffer management
-
Audio Mixing
- Multiple sound channels
- Sound effect playback
- Music support (MIDI/OPL)
š§ Phase 5: C Library and System Calls (1 month)
Standard Library Implementation
-
String Functions
- strlen, strcpy, strcmp, etc.
- Memory functions (memcpy, memset)
- Buffer manipulation
-
Math Functions
- Basic arithmetic
- Trigonometric functions (sin, cos)
- Fixed-point math for performance
-
I/O Functions
- printf family
- File I/O wrappers
- Error handling
System Call Interface
-
System Call Implementation
- System call dispatcher
- Parameter validation
- Return value handling
-
POSIX-like API
- Process management calls
- File system calls
- Memory management calls
šÆ Phase 6: DOOM Porting (1-2 months)
DOOM Source Preparation
-
Source Code Analysis
- Study DOOM source code structure
- Identify platform dependencies
- Plan abstraction layer
-
Platform Abstraction Layer
- Video output interface
- Input handling interface
- Sound output interface
- File I/O interface
DOOM Integration
-
Compile DOOM for Sarrus OS
- Cross-compile DOOM source
- Link with Sarrus OS libraries
- Create DOOM executable
-
Asset Management
- Load DOOM.WAD file
- Handle game resources
- Memory management for assets
-
Performance Optimization
- Optimize rendering pipeline
- Memory usage optimization
- Input responsiveness tuning
š ļø Development Milestones
Milestone 1: "Hello World" Process (Month 1)
- Load and execute simple user programs
- Basic memory management working
- Simple file system operational
Milestone 2: "Graphics Demo" (Month 3)
- VGA graphics working
- Can display images and basic graphics
- Mouse/keyboard input functional
Milestone 3: "Media Player" (Month 5)
- Can load and display image files
- Sound system working
- File system fully operational
Milestone 4: "DOOM Preview" (Month 7)
- DOOM engine initializes
- Can load WAD files
- Basic rendering working
Milestone 5: "Playable DOOM" (Month 9)
- Full DOOM gameplay
- Sound effects and music
- Save/load functionality
š Technical Specifications
Minimum Hardware Requirements
- CPU: 486 DX2-66 or compatible
- RAM: 8 MB (4 MB for OS, 4 MB for DOOM)
- Graphics: VGA compatible
- Storage: 50 MB for OS + DOOM files
- Sound: PC Speaker or Sound Blaster compatible
DOOM Technical Requirements
- Graphics: 320x200 256-color display
- Memory: ~4 MB for game data
- CPU: Software rendering, fixed-point math
- Storage: Access to DOOM.WAD (~12 MB)
š§ Development Tools and Resources
Required Tools
- Cross-compiler toolchain (already have)
- QEMU for testing (already have)
- DOOM source code (GPL release)
- WAD file editor/viewer
- Graphics tools for debugging
Reference Materials
- DOOM source code analysis
- VGA programming guides
- Sound Blaster programming docs
- File system design documents
- Operating systems textbooks
š Complexity Analysis
Easy Components (Green)
- Basic VGA text mode ā (already done)
- Simple memory allocation
- Basic file operations
Medium Components (Yellow)
- VGA graphics mode
- Keyboard input
- Simple file system
- ELF loading
Hard Components (Red)
- Virtual memory management
- Process scheduling
- Sound system
- DOOM engine integration
Very Hard Components (Critical)
- Memory protection
- Performance optimization
- Debugging complex interactions
- DOOM-specific optimizations
šÆ Alternative Approaches
Approach 1: Full OS Development (Recommended)
- Build complete OS infrastructure
- Maximum learning experience
- Most flexible and extensible
Approach 2: Minimal DOOM OS
- Bare minimum to run DOOM
- Single-tasking system
- Direct hardware access
Approach 3: Exokernel Approach
- Minimal kernel, maximum application control
- DOOM has direct hardware access
- Simpler but less educational
šØ Reality Check
What You're Really Building
This isn't just "running DOOM" - you're building:
- A complete memory management system
- A graphics subsystem
- A file system
- Device drivers
- A C runtime library
- A process management system
Estimated Effort
- Full-time development: 6-12 months
- Part-time development: 1-2 years
- Learning included: Add 50% more time
Skills You'll Develop
- Low-level system programming
- Hardware interface programming
- Graphics programming
- File system design
- Operating system architecture
- Performance optimization
š The Reward
When complete, you'll have:
- A working operating system
- DOOM running on YOUR OS
- Deep understanding of system programming
- An impressive portfolio project
- Serious bragging rights in the programming community
š Next Steps
- Review current kernel - ensure solid foundation
- Choose your approach - full OS vs minimal DOOM OS
- Set up development environment - debugging tools, etc.
- Start with Phase 1 - memory management
- Build incrementally - test each component thoroughly
š” Recommendation
Given your current progress, I recommend:
- Start with Phase 1 - build a solid kernel foundation
- Focus on one component at a time - don't try to do everything
- Test extensively - each component must work before moving on
- Document everything - you'll thank yourself later
- Be patient - this is a marathon, not a sprint
Ready to embark on this epic journey? š
"The best way to understand an operating system is to build one... and the best way to test it is to run DOOM on it!"
Total Estimated Development Time: 6-12 months
Difficulty: Advanced
Coolness Factor: Maximum š
What's inside
6 phases, 5 milestones, 3 alternative approaches, complexity analysis, and a reality-check section
Change this for your project
- Replace
Sarrus OSwith your own OS name throughout - Replace
samir-djili/sarrus-oswith your repository URL - Replace
DOOM.WADwith the actual WAD file path you will bundle
Where it goes
Keep in docs/ or alongside the feature. Agents read it to implement against a defined contract.
Worth borrowing
- Milestone-driven breakdown turns an overwhelming project into manageable checkpoints
- Complexity analysis (easy/medium/hard/very hard) helps prioritise implementation order
- Alternative approaches section lets you choose between full OS, minimal, or exokernel paths
Related Documents
GPU Selection Guide for Large Language Models (LLMs)
Guides GPU selection for LLM inference, fine-tuning, and training by mapping model sizes, precision levels, and budgets to VRAM requirements.
Community AI Agent Skills Discovery Sources
Catalogs 50+ platforms, repositories, directories, and communities for discovering and sharing AI agent skills across multiple coding tools.
ReleaseKit - Technical Requirements Document
Specifies a Go library and CLI for release automation with conventional commit parsing, validation checks, and workflow orchestration.
api_llm Specification
Defines a workspace of thin HTTP API clients for major LLM providers with no abstraction layer and explicit developer control.