Found by cortex over on Metafilter was this 2022 talk where someone noticed that the value of the constant pi in the source code of Doom was slightly incorrect. It’s a very tiny difference, and the results aren’t really visible in the game. So Luke Gotszling got the idea to compile the game with different values, and to see what the results are. They gave a talk about it! It’s 19 minutes long, and may be interesting if you’re of that frame of mind.
We love it when we find weird and unique indie games to tell you all about! Our alien friends to the left herald these occasions.
Found by Varyag on kitsunes.club, this may be the ultimate version of the Pico-8 version of other game phenomenon, not a remake of a classic arcade game but of id Software’s DOOM itself. And it has a great name: POOM. It’s made by freds72 on itch.io, and it’s free to download and play. Its levels are not ports of the original room, unless my memory is faulty, but smaller versions, but the general sense is still there. It even has a good remix of the first level music.
On Romhack Thursdays, we bring you interesting finds from the world of game modifications.
Look at that title and marvel a bit. Doom on a C64! What an idea. How could it even be possible? What an age we live in. It is a time of wonders. Children are our future.
Of course there’s more to it than that. There is a whole class of “retro” game that amounts to implementing the actual game on separate hardware, and using the supposed host platform as a glorified display and input device. That’s what’s going on in this case. Doom is really being run on a Raspberry Pi in a plug-in cartridge on a processor that’s underpowered by modern standards but far outpaces that of even Doom’s base configuration, and is thousands of times more powerful than the Commodore 64 to which it pipes its output.
But there’s still some technical interest in the means. The device that runs it is a “RAD Expansion Unit,” a DIY device that emulates a C64 RAM expansion, and apparently can even take over from the 6510 CPU and drive the system’s hardware directly. It works by writing to the VIC-II video and SID sound chips itself.
There was still a lot of coding work required to make this possible. A C64 has somewhat decent sound hardware, but the VIC-II chip has severe limitations on what it can display. The Raspberry Pi has to take the game’s display and port it, in real-time, to a graphics chip that can only display up to four colors (out of only 16) in each character cell, and that’s by sacrificing half of its horizontal resolution. Doing that on the fly itself is a noteworthy hack.
Could it be possible to run DOOM on a C64 without such assistance? At native resolution, ha ha ha: no. The memory limitations are too grievous, so at the very least you’ll need a RAM expansion.
I’ve mused at times on whether it might be possible if one uses the character screen as a kind of super-low-resolution graphics mode, each 8×8 character block representing either a 2×2 pixel grid (so, a resolution of 80×50) or a single pixel (40×25). Even at such a resolution 60 fps is probably out of the question, for it takes a lot of cycles to change every tile every frame, but maybe at 30 or 20? 15, 12, 10? (60 is divisible by a lot of numbers.) I will leave that question to people who are more current with C64 assembly coding.
I’ve been doing a lot of high-effort posts lately, even for things that should be fairly quick. Working to make this more sustainable, here’s a laid-back post that’s mostly just a Youtube video of a talk between the guys of Digital Foundry and Randy Linden, coder of the SNES port of DOOM, which uses the SuperFX chip to make the hardware push polygons at a rate that, while not stellar by PCs-of-the-time standards, at least not abysmal.
Let’s run down the differences of hardware:
PC running MS-DOS: targets VGA monitors, displays all its pixels in software, but makes up for it with a minimum requirement of a 386 running (if memory holds up over nearly 30 years) at 33 mHz.
SNES: Its processor is a much slower workalike of the 65C816, a 16-bit version of the 6502, running at 3.58 mHz. While it makes up for its slower clock speed with a simpler design, meaning instructions complete generally in fewer cycles, it’s hard to make up for that 10-fold difference in speed.
Their use of specialized graphics hardware was an important advantage, at the time, of consoles over personal computer hardware. Even many standard home microcomputers, like the Commodore 64 and Atari 800, had dedicated graphics hardware that helped games run better than what most PCs could do. Even when VGA came out, the standard had no hardware-level support for scrolling or sprites.
Consider what it takes to scroll a screen without hardware support: something in the system has to be able to move every pixel from one spot on-screen to another. The NES pulls this task off by having a bank of memory that its PPU can be pointed within, meaning the memory could stay in the same place, and the graphics chip would just work from a different region within it. Sadly, this technique is not amenable to 3D graphics, which usually do require every pixel on the screen to be recalculated every frame, either in software or hardware.
The SNES is known for having a rather slow chip for its time, but more demanding games tended to make up for it with co-processor chips included on the cartridges. The most well-known of these are the DSP-1, which functioned as a math co-processor; the SA-1, which was basically a second 65C816 running at around triple the speed and with a few added features; and the SuperFX, which ran at about the SA-1’s clock speed but functioned as a graphics accelerator. (The later SuperFX 2 ran at twice that speed.)
These were far from the only add-on chips included on Super Famicom and SNES carts. Since the SNES had a much larger address space than the NES’s 6502-clone, the need for mapper chips was much less, but these co-processors were used in a number of more notable games to help it make framerate goals.
Hm. Well, I tried making it a laid-back kind of post. Ah well, back to playing Live-A-Live.
A highlight of the channel that falls under our jurisdiction is him trying to get DOOM running on an old IBM machine running old IBM Unix. Over an hour long, the video is a long sequence of sadness, involving misconfiguring hostnames, getting X running, discovering that IBM’s C compiler costs about $2,500, running into basic C functions IBM didn’t implement, building OSS for AIX (and buying a $10 license for that), and then the issues with building and running the game itself. So yes, add it to the long list of devices that run DOOM, but at what cost?
Well, to NCommander, $10 plus several days of time. To you, about an hour of entertaining (somewhat) learning about obscure computing esoterica!
