How We Got DOOM Running on Zephyr (And Why You Should Try It)
summary
Port of PrBoom to Zephyr shows concrete choices: uses the Zephyr native simulator for development and tracing, replaces POSIX hooks for graphics/input, and runs on real hardware. Memory tricks include putting lookup tables in flash and reusing external LCD SRAM as a double buffer moved to external SRAM to fit within M33 150 MHz 512KB SRAM, trading some tearing for feasibility. Demo runs successfully on MCU hardware; audio remains unimplemented.
AI-written summary · about
chapters (10)
- 0:00Introduction and motivation
- 0:36Project goals and scope
- 1:54Doom engine selection
- 2:38Development and simulation
- 4:29Display and input integration
- 6:20Hardware porting challenges
- 7:30Optimization strategies
- 10:53Advanced input implementation
- 11:55Lessons learned and conclusion
- 13:38Q&A and discussion
related talks
27mInsights on the Re-Architecting to a Single Codebase, Running on Different Hardware...
35mBoosting Product Development With the Zephyr RTOS – a Critical Reflection
30mCombining Zephyr & C++20 to Build Safe, Low-footprint, Event-based Applicati...
42mInter Process Confusion - Navigating Zephyr's IPC APIs
16mKeynote: The Rise of Frameworks in Zephyr: From Devices to Subsystems to Frameworks
43mReproducible Multi Element System Composition with Linux, Xen & Zephyr
47mLinkage in the Third Millenium. Ideas, Innovations, Experiments and Prototypes for Fl...
41mFuture of Zephyr Device Model