DOOM has been ported to so many devices that seeing it on another one isn't news by itself. What makes this port interesting is how little memory it has to work with. Developer Artur Bieniek has published DMC100-Doom, a fully playable build of the doomgeneric engine for the FNIRSI DMC-100 clamp meter. The meter runs on an Artery AT32F415 microcontroller with 32 KB of RAM. Hackaday covered the project on 23 October 2026 and put the meter at about $30. It says the 32 KB of RAM is the big limit and suggests this may be one of the lowest-RAM DOOM ports so far.
The silicon: what Artery says the AT32F415 is
Artery Technology's AT32F415 product page lists the part as a value-line microcontroller. Its specifications, as Artery gives them:
- Core: Arm Cortex-M4, up to 150 MHz, with MPU and DSP instructions
- Flash: 64/128/256 KB + 18 KB
- SRAM: up to 32 KB
- Interfaces: up to 5x UART, 2x SPI, 2x I2C, 1x SDIO, 1x CAN 2.0B
- Analog: 12-bit, 16-channel ADC at 2 MSPS
- Supply: 2.6 V to 3.6 V, with 5 V-tolerant I/Os
- Temperature range: -40 to +105 C
- Packages: LQFP64, LQFP48, QFN48, QFN32
- Security: sLib security library
Artery gives the flash as a range of options, and neither the project README nor Hackaday says which flash variant FNIRSI uses in the DMC-100. We won't guess. The figure that matters is the RAM: the project README and Hackaday both give 32 KB, which is the top of Artery's "up to 32 KB SRAM" range. Hackaday gives the clock as 150 MHz, the maximum on Artery's page.
How the port fits
The repository README describes three memory budgets:
- 32 KB of RAM for the running engine
- 99 KB (101,376 bytes) of flash for the program itself
- 4 MB of SPI NOR flash without XIP for game assets
The lack of execute-in-place (XIP) matters. With XIP, the CPU could run code or read data straight from the external flash as if it were mapped memory. Without it, the 4 MB chip can't be used that way, so the program itself has to fit in the MCU's internal flash, which is why the README budgets 99 KB for it. The README doesn't say how the engine reads game data from the external chip, so we won't describe a caching or streaming scheme the source doesn't document.
The toolchain requirement is also strict. The README says the build needs clang and ld.lld version 20 or newer. With clang 19 or older the firmware does not fit, and the linker stops with the error "the image runs into the settings page". A single compiler version decides whether the binary fits, which shows how little room is left in the program budget.
What actually runs
The project doesn't use id Software's commercial WADs. It runs Freedoom: Phase 1, Episode 1. According to the README, that includes:
- levels E1M1 to E1M9
- the title screen, intermission screens and finale
- the menu
- four save slots
Hackaday's write-up also lists the full E1M1 to E1M9 run.
The game draws on the meter's 320 x 240 colour screen, and sound effects come from the meter's buzzer. For input, Bieniek uses a DJI RC-N1 drone controller as the gamepad, and both the README and Hackaday name that controller. Hackaday calls the choice "rather curious".
The repository had five commits when we read it. It's a fresh personal project, not a maintained distribution.
The trade-off: it stops being a meter
The README is clear about what you give up. Flashing DMC100-Doom replaces the FNIRSI firmware. It doesn't run alongside it. The README warns that this may void the warranty and that the meter doesn't measure anything while DOOM is installed, so you shouldn't connect test leads or clamp it around a conductor. It also says the original firmware can be flashed back.
A clamp meter is built to be used on live conductors. A unit that has been reflashed, or that is in an unknown firmware state, shouldn't be trusted for measurements. Treat it as a game device until the stock firmware is back on and working.
What It Means for Makers
This is a firmware hack, not a product. The hardware is FNIRSI's DMC-100 clamp meter, which Hackaday put at about $30 as of 23 October 2026. The software is a public GitHub repository. You need the meter, a USB-C cable to a computer, a recent clang/LLVM toolchain (version 20 or newer) and, to play it the way the author does, a DJI RC-N1 controller.
For most readers, the value isn't in playing DOOM on a meter. It's that the project is a documented worked example of a memory budget for a cheap Cortex-M4 part. Embedded engineers looking at the AT32F415, or similar parts with around 32 KB of SRAM, get a concrete case study:
- a complete game engine, drawing to a 320 x 240 colour screen, in 32 KB of RAM
- a 99 KB program image
- game data held on a non-XIP SPI NOR chip
The fact that clang 20 versus clang 19 decides whether the build fits is also a useful data point for anyone squeezing firmware into a fixed flash size. The constraints are real, the hardware is cheap, and the result is easy to see, which makes it a reasonable teaching example.
It also shows how much capability sits inside low-cost test equipment. The meter's chip, by Artery's own specifications, offers SPI, I2C, UART, SDIO, CAN 2.0B and a 2 MSPS 12-bit ADC. Repurposing that hardware is possible, but it comes at a price. The meter doesn't measure while the custom firmware is installed, and your warranty may be void.
