LoopyDOOM lets Casio’s sticker-printing console print a frame of Doom

Doom has reached the point where taking a screenshot can involve a paper jam.

LoopyDOOM connects the game to Casio’s sticker-printing console. In the Options menu, a screenshot command prints the current frame. The project’s status table adds the essential qualifier: “if it doesn’t jam.” These are the maker’s reported results and requirements, rather than our own run on a Loopy.

The game comes through the Doom, PrBoom and GBADoom lineage, with new glue for this console’s hardware. Running it on the real machine requires a Floopy Drive flash cartridge. The required WAD game-data files are supplied separately; downloading the source doesn’t give you a ready-to-play game collection.

Play the video on YouTube

The README warns that the emulator doesn’t reproduce the video hardware’s per-scanline sprite limits. A clean emulator picture therefore leaves a real-machine question open. Sound effects also need companion cartridge firmware and extra audio hardware; music follows a different path.

The underlying machine is a particularly odd destination for a shooter. The README describes a 1995 Japanese console with a 16 MHz Hitachi SH-1, about 512 KB of RAM and a thermal printer built into the case. That last peripheral turns the familiar porting challenge into something a modern PC cannot reproduce with a screen capture alone.

The current ROM holds six maps, E1M1 through E1M6. The maker says that is what fit in 4 MB. A visitor looking for the full campaign should keep that limit in mind before wrestling with the build. There is already a concrete answer to what survived the squeeze, and it stops well before an entire Doom installation.

Music and sound effects use separate hardware routes. The console’s synthesizer handles music, while PCM effects rely on the flash cartridge’s RP2040 and additional audio equipment. Hearing a soundtrack therefore does not prove that every sound path is available. The requirements make more sense when each audible result is matched to the component producing it.

The printer command is reachable through Options rather than firing on every frame. At the reported frame rate, a running scene and a printed scene are already quite different experiences. A sticker preserves a chosen instant after the game has moved on, assuming the paper mechanism cooperates.

For someone following the development, a useful progress report would show the same scene in the emulator, on the console, and on paper. That would make the documented sprite-limit difference visible and keep the printer from becoming a claim supported only by a menu option.

The source tree separates its portable game ancestry from the console-specific backend. Future improvements have several possible targets: fitting more data, drawing more reliably on actual hardware, or getting another usable image out of that unlikely little printer.

The unresolved challenge is how much smoother this can get on the original machine while keeping that printer involved.