EPISODE 1748

[INTRODUCTION]

[00:00:01] ANNOUNCER: Doom is a pioneering first-person shooter that needs no introduction. The game was released in 1993 for DOS and was an instant success. This led to ports of the game to other major platforms, including Windows, PlayStation, and Sega Saturn. One of the most remarkable ports was to the Super Nintendo with development being led by legendary engineer, Randy Linden. In addition to his work on the SNES port of Doom, Randy developed PlayStation and Dreamcast emulators, and worked at Microsoft on the Xbox 360 and Kinect. 

Limited Run Games and Bethesda recently announced a new version of Doom for SNES that Randy also worked on. It has performance improvements, new features, and uses a new version of the Super FX chip that can handle full motion video. Randy joins the show today to talk about his career, reimplementing video games, the new SNES Doom port, and more. 

Joe Nash is a developer, educator, and award-winning community builder who has worked at companies, including GitHub, Twilio, Unity, and PayPal. Joe got his start in software development by creating mods and running servers for Garry's Mod. And game development remains his favorite way to experience and explore new technologies and concepts.

[INTERVIEW]

[00:01:22] JN: Welcome, Randy. Thanks for joining me today. 

[00:01:25] RL: Thank you very much for having me, Joe. I appreciate it.

[00:01:28] JN: We touched on in that intro some know early video game history. You worked on a lot of, I guess, the first and second-generation video game consoles. What was your journey into game development at that time? I imagine it was a very different path than what some of today's game developers would have taken. 

[00:01:42] RL: Well, maybe not actually. My first experience with computers was at our high school library. They got in a Commodore PET 4032 computer, which was a monochrome computer that had 40 characters display. It was very, very basic. And there was a game called Space Invaders. Everybody knows Space Invaders. But there was a version of Space Invaders available for the Commodore PET. And it was written by a guy named Jim Butterfield. And I lived in Toronto at that time. Toronto in Ontario, Canada. And looked up in the foam book and there was a Jim Butterfield who, as it turns out, was the Jim Butterfield who wrote the version of Space Invaders. 

And I called him up. I was probably 12 or 13 at the time. And it was great. It was eye-opening. He was very friendly. He was very welcoming of the questions. I got hooked on Space Invaders. Got hooked at school with - there was an arcade across from the street. My first foray then into gaming was with a program I wrote called Barriers. And, basically, there was a vertical line of Commodore PET graphics that came across the screen. And you had a spaceship ship and you could fire at the vertical line. You had to make a big enough hole so the spaceship could fly through the hole. And it got faster, and faster, and faster. And it was my first assembly language program. And I did this when I was 12 or 13. 

And from there, I went on and - well, one other interesting story about that is, when I was first learning, I had this Space Invaders program and I thought, "Oh, I'll print it out so I can look at the program." And it was all written in machine language. What I didn't know was that the machine language, you had to look at the hex values and a disassembly. I took this massive program and printed it and sent it to the printer. And, of course, back then, you sent characters, random characters to a printer every time it hit a character 12, which is the line feed character. It ejected a page. 

[00:03:57] JN: The printer was interpreting the file you sent to print.

[00:04:01] RL: Yes. 

[00:04:03] JN: Oh, wow.

[00:04:03] RL: Yes. Exactly. I went home with a listing that was like this thick. And it was just gobbledygook characters and line feeds that was just - it was completely useless. But I thought, "Oh, I'll -" it sort of goes to show that you can start from absolutely no knowledge in an area and become an expert in an area just by applying yourself and learning. And you're going to make mistakes. And one of those mistakes was thinking that I could just send this listing. Because I was used to a basic listing and just discovered the machine language monitor. And thought, "Okay. Well, I'll just dump out this memory range to the printer." And 12-year-old me had no idea.

[00:04:46] JN: Cool. That's, yeah, fascinating. It also just kicked me with nostalgia just like the idea of an arcade opposite a school, really. A thing that has unfortunately got in the way of the dinosaurs. 

[00:04:58] RL: I know. I loved the arcade across from the school. Two of my favorite games of all time were Xevious, because it looked like it was a top-down shooter. But all the graphics looked like they were 3D. 

[00:05:10] JN: Interesting. Okay. 

[00:05:12] RL: And Dragon's Lair. 

[00:05:13] JN: Okay. Nice. Moving on to, I guess, what we're here to talk about and quite a lot of what you spend your career doing, which is I guess I kind of put under the broad category of reimplementing video games, which was - honestly, when I read about your career and a lot of the things you've worked on, and especially when we talk SNES Doom and the original SNES Doom, I was blown away by like the whole sequence of events that led to building some of these things. But when it comes to like the high-level, I guess, idea of you rock up, liked this game, and you're like, "I'm going to rebuild that from scratch without access to the code and just like a blackbox environment." How do you go about doing that? Are you doing it from a feature-by-feature, "I'm going to reimplement this?" Are you trying to work out how the game - how the engine's working and kind of building it from first principles kind of what I'm driving at here? What's your take on it? 

[00:06:00] RL: It's a good question. And it is sort of both of those methodologies. I started off for the Doom project, there was a Nintendo Developer Conference. I had worked on 8-bit Nintendo games. I'll sort of duck a little bit. I did Home Alone and Where's Waldo? Yes, which are well known for being not particularly great games. But from a technical standpoint, they were very, very technical, which doesn't translate to being a great game. But it is what it is. 

And then I moved on to Super Nintendo. And I was working on Super Nintendo at a company called Sculptured Software at the time. And there was a Nintendo Developer Conference where, basically, Nintendo had said, "Gather all the Nintendo of America developers." And they flew us out to Redmond, Washington. And what we saw was the prototype of a game called Star Fox. And it was running on this brand-new chip. 

One of the unique things about Nintendo hardware is that it can add additional chips for processing for horsepower, for graphics, for whatever. And this game was using a brand-new custom risk-based architecture that was doing 3D polygons. It was unbelievable. The game got a standing ovation from the crowd. And Sculptured made a decision to do a Super FX game. And it was called Dirt Trax FX. And it was written by a friend of mine. His name is John Morgan. And his math skills were off the charts. And he made a full 3D dirt track game on the Super FX. But the problem was there were no development systems for the Super FX. 

Nintendo typically said, "Here's the hardware specifications. And here's how things operate." But because the Super FX was so new, they didn't give us hardware specific. There was no development system that we could order from Nintendo. There was no way to start developing the software. One of the tasks that I was assigned was to create a development system for the Super FX chipset. 

[00:08:15] JN: Which I've seen you talk about this in a prior interview. I mean, I have so many questions about this whole situation. The game development scene at the time just from this whole - all of this sounds bizarre world. I don't know how they managed to put that conference together about development hardware. But you reverse-engineered this development kit was the version of the story I got. Can you go into the Frankenstein - well, obviously, it worked. But the Frankenstein monster you created for this? 

[00:08:39] RL: Yes. Yeah. Absolutely. Because we didn't have a development system, but Sculptured wanted to do a Super FX game, I knew that I would have to write a tool chain, an assembler, a linker, a source-level debugger. And so, I said about doing that. But the problem was how could we test the actual software that was being written? 

And so, I came up with this idea that I called a ROMulator, which is sort of a cross between an emulator and a ROM-based system. You basically take a Star Fox cartridge, a retail. Just go to the store and buy one. You open up the device and then you bring on an electrical engineer. Because I'm a software guy. So I don't know much about the electrical engineering side of things. But I basically described it as this; what I want to do is, when the system boots, I want a little 8K EPROM that sits at the reset vectors so I can grab control of the machine at boot. I will write a serial transfer protocol that ran across two wires connected to both joysticks on the Super Nintendo. Plugged it into an Amiga. Because I had done most of my development for PCs at that point on. Amiga systems. And I'll write a transfer protocol that can talk to the Amiga. And I'll write on my software side, the Amiga, so that it would talk back to the Super Nintendo. 

But instead of the Super FX ROM, I want you to desolder the ROM. And in its place, put RAM so you had basically a megabyte or 512k worth of ram. An 8K boot EPROM on this breadboard. Had to have been about this tall. 

[00:10:25] JN: Just stuck in the top of a cartridge slot.

[00:10:27] RL: Stuck in the top of a cartridge slot. Exactly. And it worked. It worked. 

[00:10:32] JN: Yeah. That's incredible. 

[00:10:33] RL: We were able to develop Dirt Trax FX. And as part of that development, I thought to myself, "You know -" because Doom had hit really big at that time and the office at Sculptured, every evening, was awash with people playing Doom and Deathmatch. And I thought, "This would be an awesome game to play on the Super Nintendo for all the people that didn't have a $2,000 or $3,000 PC to run the game. What if they could buy a $200 Super Nintendo and play the game on Super Nintendo?" I started to work on the Prototype and developed a functional, basic, minimal version of Doom. 

[00:11:14] JN: I'm going to come back to Super FX and, I guess, SNES hardware questions in the moment. Because I'm also fascinated by that. But to follow on this. Just to clarify when you say you start working on the prototype. Again, as we kind of alluded to, this was you just being like, "Hey, I like Doom. I've got this game. I can see it working. I'm just going to rebuild it." There was no - at that point, Doom wasn't - I guess this is like now Doom is famous for being ported to everything. From like smart fridges to whatever. But you were very much like pre all of that being a thing. Right? 

[00:11:40] RL: Yes. Yes. That's exactly what it was. I really liked Doom. The office was enamored with the game. There was this new technology that was running at an unheard of 21 megahertz. I mean, compared to the Super Nintendo's 1.7, I think, megahertz. It's very, very slow. And this processor was running blazingly quickly. We had 16-bit general-purpose registers. It was a very, very powerful chip. And I thought, "Let's make Doom." 

And I started to do what I'm well-known for, which is reverse engineer the game itself. I did have an awful lot of help in the way of the unofficial Doom specs, which basically is a large number of people contributed to it. But it was a breakdown of how Doom's internal data structures are laid out. It says, "Here's the vertices. And here's the line divs. And here's the segments. And here's the sectors. And here's how this stuff is all the raw data." 

And then I sort of set to working on an engine that could take a processed version of that data and display it. As you were asking earlier, it sort of goes from both first principles and features. And sometimes things translate really, really well. And sometimes they get sort of Lost in the translation. And one of those things that I've rectified in the latest version, actually two of those things, is the translucent spectre demons. That was a technical issue. And the fact that, on nightmare mode, there was no monster responding. 

And the reason that there was no monster responding is because I had no idea that there was supposed to be monster responding. I never implemented it. And nobody came to me and said, "By the way, on nightmare mode, the monsters are supposed to respond." For the new version of Doom, I've added that in.

[00:13:38] JN: Okay. This brings me to one of I think what is the wildest parts about the story. But just to briefly - for those who aren't aware of your re-releasing SNES Doom with Limited Run. And you've been working on it brought back onto that project. And we'll come on to that and what's new in a moment. But just to like settle in the time and place - because this is one of the things that immediately baffled me. And you saying that, at the time, no one told you about the nightmare feature is like really hits on this, which is like - you've implemented Doom yourself. Another company that's not id. And that has ended up being like a certified Nintendo release. Did at any point anyone go like, "Hey, maybe you should report the original id code?" How did that thing become a certified release? Was everyone involved just like, "That's great work. Ship it?" What was the path like? 

[00:14:19] RL: They really were. People were very surprised to see it. And I started developing this prototype in my office at home. And then once it was functional, I brought it to Sculptured software and said, "I've been working on something in my spare time. What do you think?" And they booted it up and the president and the vice president at Sculptured software, their jaws hit the floor when they saw. They basically just turned around and looked at each other and said, "This is Doom on a Super Nintendo. We've got to get in contact with ID and publish this." 

What they did was they then contacted id Software and said, "We've been working on something. We want you to see it." They sent a prototype to id Software, which is actually very similar to how the current version was done, where we, at Limited Run, said, "We've been working on a re-release of Doom for the Super Nintendo." And we sent them a Super Nintendo, and a Super Nintendo special development cartridge, and a joystick. And sent all this stuff off and said, "Take a look at it." 

And so, this is back in 1995 now. Id software looked at it. And my understand is that Romero was immediately surprised by it and said, "Yes. Absolutely. This is doom on Super Nintendo. Let's publish this." 

[00:15:37] JN: Incredible.

[00:15:37] RL: Went back to Sculptured Software. Sculptured said, "Well, we've got the go-ahead from id. Let's put a team on this so we can hit this Christmas - in this holiday season." And then they assigned musicians, and artists, and a couple of people to help with some of the level work. But I was the only programmer on it.

[00:15:57] JN: Right. It's such a, to me, just like magical series of events. I think, because it's such a contrast to what everyone expects, intellectual property hell to be like with these studios now that like that was able to happen like that. It's just a really magical sequence of events. I guess onto SNES Doom, the re-release. Oh, God. I have so many questions about how this is happening. But you mentioned it there. Obviously, a big part of how Doom was able to work on the SNES was the Super FX cartridge. And in a re-release of Doom for the SNES, it's not merely software. You're shipping new hardware as well, right? This cartridge comes with I guess a modern take on the chip? 

[00:16:32] RL: It does. We're actually looking at two different avenues for completing the chip. One is an FPGA, which is similar to what's in like the FX Pak Pro. And one is an ASIC-based solution which will emulate - completely emulate the Super FX chip. But it will allow us to have a higher clock rate, faster memory access time. But it will still be running Super FX logic underneath the covers. 

But, yes, we're actually shipping cartridges. That's the way that you'll get this new version of the game. Cartridges and our special new - now, this isn't the final right version of the controller. But I don't know if you can see, there's - 

[00:17:21] JN: A little bit of notch here. Audio viewers, we've got an SNES controller with like I guess - 

[00:17:27] RL: Rumble. 

[00:17:27] JN: Geometry. Yeah. We've got rumble packs on that. Yeah.

[00:17:30] RL: Rumble packs on the back. That's exactly it. We're shipping not only hardware for the Super Nintendo as far as the cartridge goes with the Super FX. Well, we're calling it the Super FX 3. But, of course, it's our own modified version. 

[00:17:45] JN: Right, it's only a continuity at this point. 

[00:17:47] RL: Exactly. And we're shipping the rumble controllers, which has dual rumble. And each of the rumble motors can have an intensity between 1 and 15. It's programmable. There's different waveforms that are built into the game. So that when you pick up a shotgun, you can feel the kickback. You can feel the ejection and the reload. When you've got the chainsaw, you can feel the low-level idle of the chainsaw as it's rumbling. And then when you activate the chainsaw to cut into something, you can feel it rev up. And people were very surprised when they were playing the game at QuakeCon. And then they felt rumble and they were just - their eyes lit up. 

[00:18:31] JN: A whole extra dimension that was missing in the 90s. Yeah. 

[00:18:34] RL: Exactly.

[00:18:34] JN: Actually, that's just made me think of saying that I hadn't really thought about until now, do you see - are you shipping any developer docs with this controller? Do you hope other SNES folks get involved in the rumble? 

[00:18:44] RL: Yes. That's an excellent question. And, yes, we are doing that. I am following in the footsteps of people like Jim Butterfield who lent a helping hand. That's why I released the code for Doom for the Super Nintendo. I guess it's about four years ago now. And we'll release the code. But we are also going to be releasing the technical specs for the rumble along with documentation and sample code, so that other people can develop not only titles but can reverse engineer and hack in to existing titles. 

I know that a couple of people working on the Star Fox EX project are very excited to add rumble to Star Fox. And we'll also be releasing the tech technical specs for the Super FX 3 so that it can be emulated at some point and people will be able to play the game more widely.

[00:19:37] JN: That's fantastic. Very cool. Go back to Super FX 3. You've got that more powerful hardware. What are some of the effects that's having on the game? What are some of the new - I guess the new bells and whistles on the re-release? 

[00:19:48] RL: Yeah. Absolutely. Super FX 3 - we're calling it three for two reasons. One, the last official release for Nintendo was the Super FX 2. And so, this is plus one. But more specifically, it has a 3-megabyte Super FX memory space, which is an odd size for a memory space. But it is what it is. It works. Plus, there's one megabyte for Super Nintendo. 

An interesting thing about the Super FX chip is that there's this notion of ownership. It's not dual-ported ROM. It's not dual-ported RAM. Either the Super FX effects owns the RAM or the ROM. Or the Super Nintendo owns the RAM or the ROM. And they're independent. You've got to block a RAM and you got to block a ROM. And only one device. Super FX or Super Nintendo can own it. 

[00:20:43] JN: Right. It can't be changed at runtime. It's once the game boots, it's locked in.

[00:20:46] RL: No. No. Actually, you can change it at runtime. 

[00:20:48] JN: Okay. Cool. Okay. 

[00:20:49] RL: But you can't have both devices access the ROM simultaneously. You can't have both devices access the RAM simultaneously, which is an interesting architecture. That's why there's three megabytes of Super FX ROM and one megabyte of Super Nintendo ROM as well for a total of four megabytes. We've increased the memory space. We've decreased the weight states so that every access is faster for the ROM. Because there's a number of weight states when accessing the ROM or the RAM. And so, that's faster. And that translates to a smoother, faster, higher frame rate, which is always welcome on the Super Nintendo version of Doom. 

[00:21:31] JN: Am I right in saying the original one, was it - did it run at 30 FPS? Or was it 20 FPS? 

[00:21:35] RL: Maximum for the engine is 20 FPS. Because the way that the game engine builds the display is it does it in thirds. It basically divides the screen into thirds. Because on the original version of Super NES Doom, there was a 64k byte SRAM. And so, there was only enough memory for one-third of the display at a time. I generated one-third of the display into the SRAM, switched the ownership so that the Super NES had access to the RAM. Transferred that one-third to video RAM then gave the RAM back to the Super FX so it could generate the middle third. 

It was this constant machinery of switching, and transferring, and DMA-ing, and then doing the next third, and the next third, and the next third. And then eventually it swapped everything. The new Super FX 3 has 128k. It's got double the amount of SRAM, which is still small. But it's enough to fit the entire display. I still generate it in thirds. And this is why, the game can only access video RAM during VBlank. That's one of the reasons that the Super Nintendo version of Doom is letter boxed, so that the black area at the top and the black area at the bottom count as vertical blank. 

I have increased the vertical blanking. Instead of transferring about 6k, I can transfer around 11k per vertical blank. 11k happens to be about one-third of the screen. And so, after three vertical blanks, I've transferred three-thirds of the screen and then I can do a page flip. That's why the inherent limitation of the engine is about 20 FPS. We hit typically 15 FPS. The original version of Doom for the Super Nintendo was closer to 12-ish FPS. 

[00:23:44] JN: Cool. Yeah. That comes - I guess I don't know if this is a question that makes sense or not. But this was my first time learning about Super FX doing the research and learning about SNES Doom. And I guess one of the questions that came to mind, especially when I realized that you were making a new Super FX chip, is what is the cartridge interface like? Did Nintendo design the Super NES knowing they were going to make essentially a graphics chip on a cartridge? Because I imagined - and this seems to very much be key. The ability to push info from the cartridge to the console is a restraint. That just seems like a wild design and architecture to me. 

[00:24:18] RL: It is. Nintendo designed the Super NES video RAM for throughput. It's basically got 64k VRAM that is accessed as words with low bytes and high bytes. And it's a very, very obscure, complicated architecture for a system back then. But it does it so that it can output the graphics at appropriate refresh rates. 

The Super NES cartridge interface gives you general access to the bus. The address bus, the data bus, obviously. But what was interesting about the Super FX, and I don't think that they had really intended on putting a whole graphics processor on the cartridge bus. But it's not so much a graphics processor as it is a general-purpose ALU. You can do all the basic ALU operations. Add, subtract. There's a carry. You can do exclusive ors. And you can do increments, and decrements, and all sorts of basic operations. But the registers are only 16-bit wide. 

And the nice thing about the Super FX is that it is general-purpose. It wasn't really designed to do polygons per se. What it does do is it's got a command called plot, which, as you expect, you specify an X and a Y coordinate and a color. And you say plot a pixel. And you're probably thinking, "Well, why - I mean, sure that saves you some calculations into a bit map." The key thing is that there isn't really a bit map on the Super Nintendo. It's what's known as a planer graphics architecture. So your bit planes are - if you look at the graphics this way, your pixels are into the screen. And if you turn it this way, you'll see that there's multiple planes that make up the individual bits of the color for a pixel. 

And so, instead of, for example, writing to a chunky architecture where every byte of an 8-bit per pixel memory map is one color - you write a particular color to a memory location, that's a byte wide. And it's that color. The Super Nintendo has to write to eight separate memory locations. Because the low bit of eight separate memory locations, those eight low bits are what form your 8-bit byte. And so, the Super FX has a chunky to planer, is what it's called, pixel plotting logic that operates at high speed. 

I was able to, in Doom, basically trace out floors, trace out walls, and ceilings, and objects by just literally writing a logic that said read the color - do a color lookup for the darkening effect and then plot a pixel. And the Super FX hardware handled all of the logic that was required to get the correct bit planes set in the right patterns. 

[00:27:42] JN: Amazing. Sorry. Composing - still trying to understand, visualize the planer graphics in my head. That's really - yeah.

[00:27:49] RL: Yeah. Another computing system that used a planer graphics format was the Amiga, where you had - I remember a lot of games on the Amiga used different color resolutions and bit depths. But it was a planer format. That means that when you write a pixel, you have to write to all of the bit planes as opposed to writing one chunky color value. 

[00:28:18] JN: It's fascinating. Very cool. Still, you've been able to up the frame limit. Thanks to Super FX 3. And you have another great new feature, I guess, I saw you mentioned was full motion video. You've got full-motion video intros on this? 

[00:28:30] RL: Yes. Yes. We've got full-motion video intros in the cartridge. Part of the full motion video was - it's running on the stock Super NES. But it's using a dual-threaded decoding system, where the same limitation of transferring data to vertical blank - transferring data, pardon me, to the VRAM during vertical blank exists across all games. It's not something specific for Doom for the Super Nintendo. 

I've got dual-threaded architecture where my vertical blank logic running off the NMI transfers the data that was decompressed by the mainline logic. The mainline logic basically says, "Okay, I'm going to start decompressing." And it fills up memory with decompressed frames. And while that's running, every vertical blank, I transfer a block of the data to the video RAM and then flip the pages when it's appropriate. 

We use this for the Bethesda spinning cube logo. We use it for the id Software through the tunnel logo. And we use it for the Limited Run Games glowing logo. It's kind of neat. And we've got the rumble support. 

[00:29:43] JN: You get rumble during the video? 

[00:29:45] RL: Oh, not during the video.

[00:29:46] JN: Okay. Yeah. Right. The new features. Yeah. 

[00:29:50] RL: New features. Yes. We've got the rumble support. We've got mouse support. Mouse is now a first-class citizen in Doom for the Super NES. It was not officially supported but it sort of worked in the previous doom. And I went and I got a mouse for the Super Nintendo. 

[00:30:09] JN: I don't remember the Super Nintendo having mice. Was that a thing? 

[00:30:12] RL: It was a thing. There was the original Super Nintendo mouse. And there's another one out by a company called Hyperkin. And I just got it off Amazon. Yes, there's a Super Nintendo mouse support. There is a translucent spectra demons. They now actually translucent. 

[00:30:30] JN: You mentioned when you spoke about some of the MPC stuff before, there was like just an implementation detail at the time. But was translucency a technical restriction when you first wrote it? 

[00:30:40] RL: Yes. Because of the speed of the Super FX processor and the speed of the engine itself. I did a bunch of engine optimizations. But the big step forward was through the fact that we've got a new hardware, it allows us to run things more smoothly, more quick quickly. And so, that allowed me to add the translucency effect for the spectre demons. Before, they were just all pinkies. Now they are actual translucent spectre demons. 

There is the respawning in nightmare mode. There is a music player. A lot of people really liked the Super Nintendo music for Doom. And so, now there's a music player that lists all the different musical tracks. And you can pick which song you want to listen to. There's what I call a rumble player, where it lists all the different rumble effects. And you can select each of the rumble effects to try and play it. There is a level select where you can select any level that you want to play. And there is a level code screen where you can type in - you can enter a code on the level code screen and it takes you to a particular level. There was no save RAM. And there was no battery backup for the original Super NES Doom. And so, people that were playing the game had to basically complete the game in one sitting. And so, now we've added in the level select and the level codes. So that helps with that.

[00:32:12] JN: That's a feature that I really particularly enjoy seeing revisited. Because we spoke to a developer recently who develops so-called boomer shooters. Modern shooters in the style of shooters in the era. And one of the really common things you see in those modern games is having to play it through in a single setting. There's no between level saves. Yeah, it's really fun to kind of see people reimplementing that restriction whilst you're fixing it in the 90s game. It's amazing.

[00:32:36] RL: Yeah. Because Doom for the Super NES was well-known as being a difficult game. And so, adding in the ability to start on any level. And as you're playing it, you just go to the auto map and it shows you - in the bottom right-hand corner of the screen, it shows you here's the level code. So you can just go back to - 

[00:32:55] JN: Always jump - 

[00:32:56] RL: Yeah. Exactly.

[00:32:58] JN: Obviously, one of the elements of this is you have been brought back on to work on this remake. And it was your original code. I think I saw in a previous interview someone asked you, "Oh, where did you get the code from?" And you were like, "Oh, it's was mine. I just pulled it up." I mean, A, respectable archiving process. I can't imagine anyone else still having their code around. But what was it like diving back into - I mean, I know you've re-released it in the years since. But that's a fairly old code base. And I don't think I can look at my own code from six months ago and not flinch. How was that experience for you? 

[00:33:29] RL: It was good. I will say that I used to be very smart. Because I looked at the code and I had to - the code is well-commented, I think.

[00:33:40] JN: Yeah. That's good.

[00:33:41] RL: Objectively speaking, I think the code - especially, you can go and look at it on GitHub and you'll see that the code is well-commented. But even with the comments, there were some pieces of logic that I had to sit down with pencil and paper and really retrace my steps to understand exactly what thought process was going on. 

I think the hardest part about looking at the existing code, it's twofold. It's, one, having to come to terms with the tradeoffs that were made and understanding, "Okay. That's why I did the code this way." Or, "That's why I did the code that way." And then trying to expand the feature set and to expand the options and the quality of life improvements to get that to work in the existing code. 

It was nice to be able to go through and optimize some of the code. But there was a lot of places where you sort of amortize the cost of optimization throughout the entire game. And it's like, "Well, I could save a couple clock cycles here or there. But would that really make a difference?" And in some cases, it did right. But in other cases, it was a lot of time spent trying to optimize something. It's like, "Okay. Well, it's spending a thousand clock cycles on this particular calculation or this particular sequence of operations. And I've managed to save five." I would spend an awful lot of time going through. And it's like, "Wow. I used to be really, really smart when I wrote this code originally." It kept tripping me up sometimes.

[00:35:17] JN: That's a really interesting point. As you're going for that code and understanding the tradeoffs and what was made where, when it came to the feature set for the new game, was that afford - a lot of features that you knew? Like, we want to add these. And I'm working out how. Or was it a case of like understanding how you wrote - why you wrote some code and realizing, "Oh, we no longer have that restriction with the new hardware." Which way around did things come out? 

[00:35:38] RL: It actually came out both ways. One of them was here's a bunch of features that we wanted. A good example is circle strafing. There was no circle strafing in the original version of the game. And this was just like the no nightmare monster responding. This was an oversight. this wasn't done for any technical reason. When the code was released back in 2020, people said about and looked at the source code and they were able to see where that corresponded to in the actual ROM. And people were able to patch in circle strafing for the game. It was clearly something that people wanted. And so, that was something that I implemented, like the nightmare respawning. 

But then there were other things like the full-screen videos, the translucent spectre demon that came about as a result of the new hardware because the Super FX was running faster. Because we now had - instead of a 2-megabyte memory chip, we now have a whopping 4-megabytes of memory. And then it was also the third, I guess, prong in that is coming up with new hardware. I always thought it would be cool for the Super NES to have rumble support. 

And so, coming up with a way of doing the rumble, it was both living with the existing limitations that are, in many cases, still there. Like the vertical blank and the maximum transfers to VRAM. Adding features that were now possible, like the full motion video or the translucent spectre demons, because the Super FX chip now has enhanced capabilities. And adding our own Hardware take on things to add features that were never there before. 

[00:37:26] JN: Very cool. Yeah, the new hardware I think is a really nice unexpected touch for a remaster of any kind. That's just really cool. 

[00:37:33] RL: Yeah. It's something that I have to say, it's only because Limited Run really takes not just pride in these things. But they take risks, I guess, is the best way to put it. 

[00:37:41] JN: Yeah. I mean, who would think like making new cartridges of a new specialty ALU in it? Yeah.

[00:37:48] RL: Exactly. 30 years after the console has hit its peak. And here we are. 

[00:37:53] JN: Yeah. Which I guess brings me on to - my next question was about the process of developing for the game. We spoke about your old development kit hacked from a Star Fox cartridge. I imagine, in some ways, developing for the SNES has gotten better. Development environments in general, more sophisticated. But then it's been such a long time since the console was developed for. Have you had to buy a lot of weird esoteric SNES development kit stuff off eBay? How have you gone about putting together a new dev kit for 2024? 

[00:38:22] RL: It's an excellent question. Actually, I do my development. I still do my development on Amiga. But not actually on a hardware Amiga. I use WinUAE to emulate the Amiga on a Windows 11 PC. I have enhanced and modified my development system. But I use now the FX Pak Pro for hardware tests. So I can literally put the ROM onto a tiny little SD card. These things are microsco - it's amazingly how much space is on such - 

[00:38:59] JN: They [inaudible 00:38:59] all the time. They're like dust. 

[00:39:01] RL: Exactly. They are like dust. I test for actual hardware on that. And I use an emulator, a spectacular emulator called Mesen. Mesen is an open-source, incredibly powerful emulator. Not only does it emulate the Super NES very, very well among other systems. But it has a full source-level, single-stepping debugger for the Super NES 65816, or the SPC700 sound side, and for the Super FX chip. 

[00:39:37] JN: Wow. Okay. 

[00:39:39] RL: I'm able to literally assemble, link, and build my executable in about five seconds flat. Literally. I then run it in Mesen for single-step source-level debugging. And then when it's operational and I want to test on the actual hardware, I copy it to an SD card that I put into the FX Pak Pro. Now, you're probably thinking, "Well, but these things don't support Super FX 3 because that didn't exist at the time." And that's true. That's one of the powerful aspects of open-source software and hardware. I was able to make modifications to Mesen to add not only support for the Super FX memory space and timing but also for rumble. If you happen to have a - 

[00:40:32] JN: You can use an Xbox controller on it.

[00:40:34] RL: An Xbox controller, that's a USB controller that you plug into your PC when testing Super NES Doom, the rumble - rumbles. that's how I was able to develop the waveforms and test the rumble support and modified the FPGA firmware for the FX Pak Pro that was already emulating the Super FX 2. I modified it to emulate the Super FX 3 by changing the memory map and allowing it to access the additional regions of memory space.

[00:41:09] JN: Both those patches have been pushed upstream into the main projects? Or are they still in your development? Cool. That makes sense. 

[00:41:14] RL: Not yet. Yeah. Once everything is finalized, that's exactly the plan. The plan is to release the technical specs and the memory map. And here's the patches that allow that support to operate. Yeah. 

[00:41:27] JN: Such an impressive project with so many layers. Also, I hadn't heard of the FX Pak before this. I think you've kind of explained along. It's like an FPGA. Essentially, you can use it to run any game you want on the cartridge and emulate any hardware that was on cartridge. Very cool.

[00:41:41] RL: That's exactly it. It's an excellent piece of hardware. And we just get them off of Amazon or we get them from krikzz.com, which is the - not plugging this hardware. But it's a spectacular hardware, especially coming from a software guy where I know very little about the underlying hardware. It is an SD card reader that you can put your ROMs on. And it's an FPGA solution that allows it to emulate the Super FX, the cartridges. It allows it to emulate the SA1 hardware, which is a nice speedy version of the 65816 as an add-on co-processor. It emulates the MSU1 and a whole bunch of others. BSP1. 

[00:42:31] JN: I imagine the old-school cheat cartridges as well. That's one of my fondest memories of the SNES is the big cheat cartridges.

[00:42:36] RL: Yes. That's exactly what this is like. It's like a big cheat cartridge. But it's using an FPGA to emulate the hardware. And it's very, very powerful. It's only because of the constellation of hardware, and software, and firmware that something like the new version of Super NES Doom was even possible. I was approached - I guess it's about two years ago. I did an interview with Digital Foundry about my history, my career, and about Super NES doom. And one of the guys who was from Digital Foundry, his name was Audi Sorlie, worked at Limited Run Games. 

And after the interview, he said, "By the way, what do you think about doing a new version of Super Nintendo Doom?" And I was like, "Wow. That sounds like a great idea." And it sort of started to get the ball rolling. I had a friend who said, "Well, if you're going to do it, adding on these new levels," he said, "well, why don't you add on episode four?" And I said, "What do you mean add on episode four?" He said, "Well, yeah. Now, every version of Doom comes with the fourth episode Thy Flesh Consumed. Why not add it on?" I said, "Well, I've already told id Software we're using version 1.666, which only had the first three episodes." And he says, "Well, tell them that -" 

[00:43:58] JN: They seem very amenable to whatever you will suggest. 

[00:44:01] RL: That's exactly it. He said, "Tell them that you could add on this new episode." And so, I did." And so, now we've got all four episodes and all the missing levels. 

[00:44:11] JN: Yeah. Really is amazing some of the I guess retro gaming stuff that's being unlocked by FPGA. This FX Pak cartridge reminds me a lot of I guess what's happening with the analog for the Game Boy. It's just a complete revolution. It's fantastic.

[00:44:24] RL: Yeah. At QuakeCon, we were demoing new Super NES Doom using analog NT hardware, which is basically a Super Nintendo. But it has really, really nice sharp integer pixels. Everything looked really, really good.

[00:44:43] JN: That's awesome. We are coming at the end of time. I guess I want to end on you've made a career of reimplementing and now remastering games. Is there a game that, given the opportunity, you would love to give this treatment to? 

[00:44:56] RL: That is a good question. I would say there isn't really. I think that the ability to remaster titles, I sort of do more reimplementation of titles. I started off with my centipede clone called Bubbles for the Commodore 64. I did Dragon's Lair for the Amiga. I did Wayne Gretzky Hockey on the Nintendo 8-bit. And then I did Doom for the Super Nintendo. I think really what pushes me is the technical challenge. And I think we're at a point now where there aren't a lot of technical hurdles. There aren't a lot of - I mean, I'm sure there are. But the level and the quality of graphics, and sound, and level design is really - now, it's an art form. Whereas my sort of forte is pushing the boundaries of what's technically possible on hardware. That, now, the hardware is so capable, so powerful that I think it's nice to be able to revisit a title like Super NES Doom and really push the hardware beyond what it was originally designed for and then add on all of our new stuff to it. 

[00:46:17] JN: Yeah. That makes sense. It's a very different - you couldn't really reimplement an Elden Ring or a Skyrim in the same way on a modern PC with modern AAA games. It's not a very different ballpark, isn't it, intellectually and I guess satisfactorily? 

[00:46:33] RL: Yeah. It gives me great satisfaction to work on something. And I guess there were two things that really sort of struck me that, yes, we're heading down the right path with this new Super Nintendo Doom when I was demoing it at QuakeCon. I guess three things. One, people were very surprised that, yes, I'm the author and they were talking to me. And it's like, "Well, yes. Of course, I'm happy to talk about it." 

The second one was when people were playing it and they felt the chainsaw rumble for the first time. It's like, "Wow. This is really like a chainsaw." And the third thing was that people said, "Well, this is sort of like playing the PC version of Doom back 30 years ago." And it's like, "Oh, that means that I've sort of approached the PC version as far as gameplay. And that's a tremendous compliment." 

[00:47:23] JN: Yeah, on that limited hardware. That's the original goal. That's awesome. 

[00:47:26] RL: Exactly.

[00:47:27] JN: It reminds me a lot of - are you familiar with the fantasy consoles like PICO-8 and TIC-80? It's reminds me - there a lot of like that whole scene. The satisfaction in pushing that limit but the constraint is the game. Right? 

[00:47:39] RL: Yes. Exactly. People will always have their favorite feature or option that Super Nintendo Doom doesn't have. And part of the - I don't want to say Nostalgia. But part of the thing that makes Super Nintendo Doom, it's the limitations. The inherent, "Well, you can't do this. And you can't do that." But it's still Doom. And it's still Doomy. I think that sort of makes it exactly what the game is all about.

[00:48:10] JN: Perfect. Well, I think that is a wonderful place to put a pin in this episode. Randy, thank you so much for joining me today. This has been wonderful. And I guess they still - is there a firm release date for SNES for the remastered - 

[00:48:22] RL: There is not. Still finalizing things. 2025 is when we're looking at doing the launch. We're still tightening the last little bits pieces, and testing it, and fixing bugs. And that's one of the challenges but also one of the exciting aspects of developing for a system that's hardware cartridge-based. There's no such thing as a patch. 

[00:48:45] JN: It's out. It's out. 

[00:48:47] RL: Right. It's out. It's out. It's got to hit the ground running. It's got to be flawless. And so, we're doing all of our testing and due diligence to make sure that it all works as expected.

[00:48:58] JN: Perfect. All right. Well, keep an eye on that for 2025. And, yeah, thank you so much for joining me today. 

[00:49:03] RL: Thank you so much, Joe. My pleasure.

[END]