Doom Is running on the Commodore 64 Ultimate with a brand new 3D engine

Doom has appeared on almost everything with a screen and a processor, but this version for the Commodore 64 Ultimate takes a more interesting technical route. It isn’t simply the original 1993 PC game forced onto different hardware. Instead, developer Stephen Lesinger has built a new 3D engine specifically for the C64 Ultimate, using Doom’s familiar E1M1 level as the test bed. And yes, it actually moves. The current build runs at a locked 16.6 frames per second on real hardware. It includes textured walls, doors, sprites, a weapon display, HUD graphics and music. Combat isn’t working yet, so this isn’t a finished Doom port. What it does show is how much of Doom’s basic world can be reconstructed when the engine is designed around the machine from day one.

This isn’t the original Doom engine

The big difference sits underneath the graphics. Doom C64U doesn’t run id Software’s original engine. The renderer, collision system, memory handling and audio code have been written specifically for the Commodore 64 Ultimate. The project can still use information from a Doom WAD, including the map geometry and graphics, but the code responsible for putting that world on screen is new.

That’s a sensible choice because the hardware works very differently from the PCs Doom originally targeted. The C64 Ultimate has a 6510-compatible processor capable of running at up to 64 MHz, but programmers still have to deal with a 64 KB main memory space. There’s also a 16 MB REU, or RAM Expansion Unit, which gives the project somewhere to keep larger amounts of map data, textures, sprites and music.

That extra memory matters. A lot. Instead of trying to keep everything in main RAM, the engine stores data in the REU and brings pieces across when they’re needed. It’s a practical answer to a familiar problem: Doom’s world is simply too large to sit comfortably inside the machine’s normal working memory.

Fixed-point maths keeps the renderer moving

There’s no floating-point unit here, so the engine avoids floating-point calculations. Projection, lighting and distance calculations use fixed-point maths instead. Trigonometric values and reciprocals come from lookup tables, which cuts down the amount of calculation required while each frame is being built.

The renderer also avoids drawing things the player can’t see. It checks the BSP structure and rejects invisible sections before spending time rendering them. That’s important because every millisecond counts.

The engine builds the 3D view in a 160 by 176 chunky framebuffer that takes up roughly 28 KB. That’s already a sizeable chunk of the available memory. The image then gets converted into a format the VIC-II video hardware can display.

Lighting is handled with ordered dithering. It’s a straightforward technique, but it works well here. Instead of trying to reproduce every colour and brightness level directly, the renderer uses pixel patterns to create the impression of different shades.

The frame rate is a target, not a lucky peak

Early versions of the renderer reached around 25 fps when the scene used simpler flat shading. Once textured walls, sprites, moving sectors and the weapon graphics arrived, performance naturally dropped. The current target is 16.6 fps.

That gives the engine just under 60 milliseconds to finish each frame. Miss the deadline and the experience becomes uneven, so the project treats frame time as a strict budget rather than chasing occasional high numbers.

The tests have also been carried out on actual C64 Ultimate hardware, which matters. Emulator figures can be useful during development, but real hardware tells you whether the timing assumptions actually hold up.

E1M1 makes a useful test level

Doom arrived on PC in 1993 and quickly became one of the defining games of the first-person shooter genre. Its shareware release put the opening episode in front of a huge number of players, and E1M1: Hangar became one of the most recognisable opening levels in PC gaming. Here, that familiarity has a practical benefit.

Doom C64U uses E1M1’s real BSP nodes, sectors and map structure. Doors work. Walls have textures. Doom objects and enemies can appear as sprites. The player can move through a level that follows the original layout rather than a rough recreation. It feels recognisably like Doom, even though the engine underneath it is completely different.

Combat is the next major hurdle

The current build supports keyboard, joystick and mouse controls. There’s movement bob, jumping, health, armour and ammunition on the HUD, and SID music running alongside the renderer. But the numbers on the HUD aren’t tied to a working combat system yet.

Enemies don’t attack. Weapons don’t deal damage. Projectiles and the wider gameplay loop still need to be added. That’s where things get harder. Rendering a level is one challenge. Adding AI, combat, damage calculations, effects and more active objects means spending even more of that tight frame budget.

For now, Doom C64U is best viewed as a working Doom renderer and level implementation rather than a finished game. But it’s already doing the interesting part: taking Doom’s data and rebuilding the experience with an engine designed specifically around the limits and strengths of the Commodore 64 Ultimate.

Spread the love