--- title: "Doom runs on a 2010 DSLR. Doom is the easy part" locale: "en" url: "https://irz.fr/en/articles/doom-canon-550d-port-en" markdown_url: "https://irz.fr/en/articles/doom-canon-550d-port-en.md" category: "tech" tags: ["Doom", "Canon 550D", "Magic Lantern", "firmware", "reverse engineering", "hardware"] published_at: "2026-08-21T08:28:00.000Z" author: "Manon Girard" translation: "https://irz.fr/fr/articles/doom-canon-550d-port-fr.md" --- # Doom runs on a 2010 DSLR. Doom is the easy part Doom now runs on a Canon EOS 550D using its screen, buttons and even its speaker. The port is really a map of everything developers had to learn about the camera first. A playable Doom port now runs on the Canon EOS 550D through Magic Lantern. The camera was released in 2010; in the port its directional pad handles movement, `SET` fires, playback opens doors, the rear wheel changes weapons and the built-in speaker carries the sound.[1](https://github.com/lauris-nl/doom550d)[4](https://www.tomshardware.com/video-games/retro-gaming/github-programmer-ports-doom-to-dslr-camera-with-3-inch-tft-lcd-display-canon-eos-550d-with-open-source-magic-lantern-firmware-uses-cameras-button-as-controls-even-plays-sound) The mismatch between a DSLR and a 1993 game is the obvious attraction, although the source code is more useful than the demo because it shows how much camera-specific work remains after Doom itself has already been made portable. ## Wrong screen Doom550D writes into the Canon bitmap buffer and must leave that display state usable when the game exits. One added mode renders gameplay at **360 × 240**, expands each game pixel into a 2 × 2 block and places the result on the 720 × 480 bitmap exposed by the camera.[1](https://github.com/lauris-nl/doom550d) The project's porting notes list several things that have to be checked again on another Magic Lantern camera: video-memory layout, line pitch, palette handling and the Canon calls used to update the palette. Support in the same firmware project therefore does not imply that two camera models expose their displays identically.[1](https://github.com/lauris-nl/doom550d) > Illustration: A game of Doom displayed on the rear screen of the Canon EOS 550D. The DSLR screen becomes the game surface. Keeping the camera usable afterwards requires correct handling of the framebuffer and palette as well as drawing the game itself. Credit: [Bas Lichtjaar / doom550d](https://github.com/lauris-nl/doom550d). ## Borrowed buttons Input needs the same model-specific treatment. Doom550D defines the raw press and release codes used by the 550D, then maps only part of the camera's control set onto the game. ISO, depth-of-field and shutter controls are left unused because Canon can still process them below the module layer, where autofocus or EOS overlays may interrupt Doom.[1](https://github.com/lauris-nl/doom550d) This leaves a practical constraint for the port: a button that exists physically is useful only if the module can borrow it without conflicting with behaviour that the Canon firmware still owns. Held keys, releases and combinations also have to be checked on the real camera rather than inferred from the presence of a button on the case. The distinction matters when moving from a demonstration to something playable. A single successful key press proves little if the camera later intercepts another part of the same control sequence. ## Audio path The audio implementation is another camera-facing part of the project: Doom's MUS music is rendered by a small integer synthesizer, mixed with the game's 8-bit effects and sent as a 48 kHz mono stream through the Canon audio path.[1](https://github.com/lauris-nl/doom550d) For that path, the module expects eight Canon audio symbols from the matching Magic Lantern build. The documented list includes `StartASIFDMADAC` and `SetNextASIFDACBuffer`. The release notes therefore tell users to keep `autoexec.bin`, the 550D symbol file and `doom.mo` from compatible builds together; a mismatched symbol file may not export what the audio backend expects.[1](https://github.com/lauris-nl/doom550d) Canon never documented the 550D as an audio-development platform. By the time Doom550D arrived, however, Magic Lantern developers had recovered enough firmware behaviour for a later module to call into these functions, so its audio code starts from that earlier reverse-engineering work.[6](https://www.magiclantern.fm/forum/index.php?topic=11646.0) ## 3,780 lines IRZ cloned the repository at commit `b4a99c6`, where the module tree contains **76,540 lines of C and header files**; most belong to Doom or code inherited through earlier ports, so the total describes the software being built rather than the amount of new work done for the camera. A second count isolates five files concentrated around the Canon, Magic Lantern compatibility and audio: `doom550d.c`, `doom_audio_ml.c`, `doom_ml_compat.c`, `doom_softsynth.c` and `doomgeneric.c`. Together they contain **3,780 lines** in the audited tree, although the grouping is deliberately rough because those files still mix inherited and new code; it is useful mainly as a scale for the layer containing display and palette handling, button events, file access, audio, synthesis and the Doomgeneric bridge. > **Where the port lives** > Diagram showing Doom above a 3,780-line adaptation layer that talks to Magic Lantern and then Canon hardware. > - Doom is already portable. The Canon still has to be learned. > - Doom + inherited code · ~76,540 C/H lines total > - Canon / Magic Lantern / audio layer · 3,780 audited lines > - Display · palette · buttons · files · audio · cleanup > IRZ count of doom550d: 76,540 C/H lines in the module, with 3,780 across five files centered on Canon/Magic Lantern adaptation and audio. The grouping is indicative, not a line-by-line authorship claim. The README reaches a similar division from the developer's point of view. Much of the Doom engine, WAD handling, save code and synthesizer can move to another camera. Display setup, button codes, the audio backend, storage behaviour, cleanup and physical regression tests need another pass for the target model.[1](https://github.com/lauris-nl/doom550d) Doom is portable here because the generic parts have already been separated from the final machine-specific layer, which still has to be written and checked for the camera in front of the developer. ## Still Canon Magic Lantern provides the environment without removing Canon's original system: its 550D build targets firmware **1.0.9**, and installation sets a boot flag so the camera can start the program stored on the memory card while Canon's firmware remains installed.[2](https://builds.magiclantern.fm/550D-109.html) Doom550D has an equally narrow target. The released module is for the EOS 550D / Rebel T2i / Kiss X4 on firmware 1.0.9 and expects a compatible Magic Lantern core and symbol file. Its documentation warns users not to load that binary on another camera or firmware version.[1](https://github.com/lauris-nl/doom550d) This arrangement gives community software deep access without turning the camera into a general-purpose machine. Functions and addresses used by Magic Lantern were recovered through reverse engineering rather than published as a supported Canon interface.[6](https://www.magiclantern.fm/forum/index.php?topic=11646.0) The project also warns that Magic Lantern is unsupported by Canon and that failures can damage a camera.[2](https://builds.magiclantern.fm/550D-109.html) ## Second life The hardware Doom550D uses was present from the start, with Canon's manual already describing the rear display, physical controls, movie playback and built-in speaker that the port later reuses; the 2026 change is in the available software and documentation rather than the camera's components.[3](https://files.canon-europe.com/files/soft38013/manual/EOS%20550D_HG_EN_Flat.pdf) Another project reaches Doom on an older Canon by a different route: `sd1000-doom` targets the 2007 PowerShot SD1000 through CHDK and has its own camera-facing adaptation, so the two ports do not share one universal Canon layer and each depends on what its firmware ecosystem has learned about that model.[5](https://github.com/DaneBentley/sd1000-doom) Apparently ridiculous Doom ports remain useful because the game supplies a fixed target while display, input, storage, timing, audio and cleanup all have to work together on hardware that was never sold as a development platform; a boot screen confirms only the first part of that job. On the 550D, the more interesting result is the amount of machine knowledge required before Doom can keep running and still return control to a usable camera afterwards. ## References 1. [lauris-nl, Doom 550D — repository, documentation and source code](https://github.com/lauris-nl/doom550d) 2. [Magic Lantern, Canon EOS 550D firmware 1.0.9 build](https://builds.magiclantern.fm/550D-109.html) 3. [Canon, EOS 550D Instruction Manual](https://files.canon-europe.com/files/soft38013/manual/EOS%20550D_HG_EN_Flat.pdf) 4. [Tom's Hardware, Doom ported to a Canon EOS 550D, August 20 2026](https://www.tomshardware.com/video-games/retro-gaming/github-programmer-ports-doom-to-dslr-camera-with-3-inch-tft-lcd-display-canon-eos-550d-with-open-source-magic-lantern-firmware-uses-cameras-button-as-controls-even-plays-sound) 5. [Dane Bentley, sd1000-doom — Doom on a Canon PowerShot SD1000 through CHDK](https://github.com/DaneBentley/sd1000-doom) 6. [Magic Lantern Forum, explanation of Canon firmware loading and reverse engineering](https://www.magiclantern.fm/forum/index.php?topic=11646.0)