There is a catch, of course. There is an art to these kinds of hacks though, and it lies in finding the right catch. The catch that makes the hack possible at all, but seems the least like a cheat.

You can technically “run” Doom on a C64, if you actually run it on a Raspberry Pi plugged into it, that only uses the machine’s video hardware for output. That’s an egregious cheat; Raspberry Pis didn’t exist back in 1983 when the C64 was new.

There are speed-up cartridges for the C64, and you could even implement a co-processor to do much of the hard work of rendering the display for you. That’s also a cheat, although a bit less of one.

One could approach the problem from the other direction, diminishing the scope of the hack until it fits more comfortably in the computer’s capabilities. There are 3D corridor games on the C64; when I was a kid, a tape of software that a co-worker gave to my dad had one, called LABYRINTH, that was written in BASIC. But if it was truly the equal of Wolfenstein 3D it’d have revolutionized the gaming world. It wasn’t, and it didn’t. It generated one of those Wizardry-style mazes, sometimes called “blobbers,” where your perspective is fixed in the center of a grid-based maze. It wasn’t a shooter, it didn’t animate smoothly, and it was a pretty simple algorithm, simple enough that lots of games used it, especially RPGs.

What makes smoothly rendered graphics slow on a C64, indeed on pretty much all home computers at the time? It’s the necessity of using a bitmapped graphics mode. The math of deciding where the corridor vertices and lines go is within the machine’s capability, even at 1 mHz, but writing all those bytes into the C64’s 8K bitmap screen takes a huge amount of time.

It’s why few action games on the Commie used the bitmapped modes. Even if you used a hand-tuned machine code loop to write a single value to every byte in the bitmap, it’d be slow enough that you could visibly watch the screen fill up. If you wanted to actually vary those bytes, such as by rendering walls, it’d take much longer. Even filling the text screen takes so long that it’s difficult to do it in a single video frame, which is why games that feature NES-style full-screen scrolling on the C64 are impressive. (There are tricks to doing it; some of them quite bizarre. Let’s discuss those some other time.)

But you could do what jimo9757 did, and use text characters to simulate the rendering. In fact they did it one better, and used the PETSCII graphics characters for the display. The result is pretty striking! See for yourself in this demo (8 minutes):

Reserving a port of the screen for a status display is itself a bit of a cheat, that cuts down on the number of bytes that must be changed for each screen update, but it’s one that Wolfenstein 3D used too so let’s give it a pass. The walls only have horizontal lines for textures, but it’s not like the original’s were that worthy either. It’s certainly not 60 fps, it’s maybe 15 or 12, but it’s certainly still impressive to see those walls glide by smoothly on a machine with a 1 mHz 6502-class chip.

Since the game uses PETSCII for the maze, this engine can even work on the Commodore’s first home computer, the PET, whose character set was fixed in unchangeable mask ROM. Here’s video of the first-person shooter they made for the PET (3 minutes). I think the graphics, while many would call them primitive, have a fun style to them:

Both the PET game, Escape From PETSCII Castle, and the tech demo of the work-in-progress C64 version can be downloaded from itch.io, to play around with in the emulator of your choice.

rodneylives