Development interview with Randal Linden and John Linneman Part 1: Encounters of the Super NES Kind
July 17 2025
Development interview with Randal Linden and John Linneman Part 1: Encounters of the Super NES Kind
by John Linneman
Encounters of the Super NES Kind
The first time I saw Super NES, I was working at Bethesda Softworks back in Maryland around 1990. I was developing Nintendo 8-bit games and then suddenly we got a Super Nintendo in the office with Super Mario World. I started playing Super Mario World and the graphics and sound effects were just amazing. Super Mario World remains the one game that I have played all the way through. That was my introduction to the Super NES.
We developed Wayne Gretzky Hockey and Where's Waldo and Home Alone on the Nintendo 8-bit and then I moved on from Bethesda and did some work at a company in San Diego called Leland Interactive Media. They did “Super Off-Road: The Baja” and the guy who developed it was John Morgan. After some time, John and I left Leland and started to work for Sculptured Software. We set up a little office that was known as “Sculptured West,” and I started work on a monster truck game that was going to be published by Acclaim. John was great at 3D and math and was set to do “Dirt Trax FX”, which brings us to the FX chip.
Super FX – How it Started
In 1994 we flew out to Nintendo’s headquarters along with developers from all over the world. Inside, they had a projector set up with a big screen and rows of seats. Everybody sat down, but we didn't know what to expect. They then dimmed the lights and showed the intro for Star Fox with the Arwing flying out of the base. When it finished, they raised the house lights again and everybody just stood up. After gasping at what we were seeing on screen when the demo was running, everyone just started clapping and gave it a standing ovation. It was amazing!
Afterwards, Nintendo had a packet of information they gave us. It was a basic overview of the Super FX technology. The documents described that it was a RISC processor and along with the basic operations for 3D math there was a plot command, which was unique for Super NES because the system uses a planar graphics architecture, which means that all the graphics are split into individual bit planes and then recombined by the picture processing unit. That was a bottleneck for doing 3D graphics, which typically operate with a chunky architecture, which means that each pixel is stored with all its bits together. The Super FX document was maybe 30 or 40 pages and didn't really have any further technical details.
This brings us back to “Dirt Trax FX.” There was no development system available from Nintendo. They basically gave us this technical brief but that was all that they provided. There was no hardware, no software, no assembler, linker, toolchain or anything like that. So, when Sculptured decided that they wanted to do a Super FX game, there was no roadmap for how it was going to be developed.
The Romulator
I was known for having created a development system on the Amiga called the “Access” Development System and I said that I would be able to update it to add support for the Super FX, but I would need some basic technical information like the instruction set and registers and things like that. So, Nintendo sent along that basic information which was a list of op codes and what the op codes did and I came up with the idea for what we internally called the “Romulator.”
I said to John and to others at Sculptured, we know that Star Fox has a Super FX chip on it – the actual cartridge that you could go to a retail store and buy -- so let's buy a couple of Star Fox cartridges and contract with an electrical engineer to remove the ROM chip from the game. We can then replace the ROM chip with RAM and a small eight kilobyte boot EEPROM instead. The reason we needed the boot EEPROM is that, when you turn on the Super Nintendo, the boot EEPROM kicks in and it allows us to execute a little program known as a monitor program. That program is what's used to communicate between the Super Nintendo and the development system, which at that time was an Amiga 2000.
So, I designed a little hardware interface that connected between the two joystick ports on the Super Nintendo and the Amiga and wrote software that communicated using those two or three wires. In conjunction with the Romulator, which was a large breadboard, basically a Star Fox cartridge glued onto a breadboard with a bunch of RAM along with this little EEPROM, we were able to grab control of the Super Nintendo and the Star Fox chip, load a program into RAM, execute it and single-step and debug it.
Using this method, we were able to make a complete development system that was then used for Dirt Trax FX. While I was working on the development system, working on programs to test things, it struck me that DOOM would be a perfect showcase for the Super FX chip. I needed a test program to work on anyway, so why not DOOM?
Doom in the beginning
So, I started working on DOOM and little by little built it up from a bunch of tools that allowed me to process the DOOM data into a rendering engine. When I had the very first level of DOOM E1M1 operational, I showed it to Sculptured as a technical demo and said “here's what I believe can be made into an actual product.” I remember showing it to George Metos, who was the president at Sculptured, and Kelly Zmak, who was the vice president. Kelly's first words were “Wow, it's DOOM running on a Super Nintendo!” George was impressed as well and we all decided “yes, let's make this into a product.”
This initial prototype was very limited, of course; it didn't have any objects, so there were no pickups, enemies or sprites – just walls and floors. The floors were solid colored and the walls were texture mapped. You could run around the first map and that was basically it, but it was enough.
Reverse Engineering Everything
To pull this off, I reverse engineered the Super FX chip, reverse engineered the hardware so that we could interface with it, and I reverse engineered DOOM itself because we never received the DOOM source code. We also lacked the game data, graphics, sounds and the levels. So, all of it was a massive amount of reverse engineering and undertaking in order to get it to operate. By the time it was demoed to id Software, it was operational, but it was done completely without their support or assistance.
The look and feel were adjusted over a number of months of more reverse engineering and playing DOOM to see how things operated. Eventually we worked with id software to tweak all the numbers, the damage amounts, the splash damage from rockets, how much health you got for different pickups and more. That's all configurable, but because it was all reverse-engineered based on my own engine technology, there was a lot of tweaking and adjusting required so that it felt like DOOM even though it wasn't based on the DOOM engine.
I investigated adding floors and ceilings with textures, but the memory requirements were too high. The wall textures are compressed with RLE (run length encoding), but floor and ceiling textures would have required 4KB for each texture uncompressed and there just wasn’t room in the 2MB ROM for even a single floor texture or ceiling texture.
I remember when I first saw DOOM on PC, I was amazed. It was fast, fluid, and visceral — technically brilliant, but it required a fairly powerful PC. I’ve always gravitated toward technically challenging projects, and porting DOOM to such a limited system was the ultimate challenge. It allowed people to play DOOM on a vastly reduced system and still get a feel for DOOM without having to spend a few thousand dollars on a home computer.
I was told that DOOM on the Super Nintendo was the origin of the impossible ports and the saying “Can it run DOOM?” because now everything these days runs DOOM, but it was the very first time that somebody said, well, “Can it run DOOM?” Well, yes, it can!