@BulkSlash Looking into it, it seems like the extra PINs some carts have aren't 100% necessary for expansion chips in carts. I found this old Reddit comment about those pins:
"Doom, Yoshi's Island, Star Fox and a few other games use Super FX chips, and the Super Game Boy has an actual Game Boy inside. The pins are there to connect them to the SNES's clock, but I think on Doom and Yoshi's Island they're not actually connected and the chips use their own clocks. I think every DSP chip had its own clock, so none of their boards were made with those pins."
Now, the pins aren't JUST the SNES clock. There's also PINs for Address Bus B lines, and audio input from the cart for any with additional sound chips. But it seems if the expansion chip doesn't need the SNES system clock, and doesn't need Address Bus B, then it can work without them. Doom maybe had them because it was developed using a modified StarFox cart, and it wasn't until this remaster that they figured out they could configure the game to run without those extra pins.
@smoreon You can't just look at clock speeds when comparing different CPU architectures. While the Genesis/MegaDrive CPU has almost twice the clock of the SNES one, the SNES CPU takes half the clock cycles to perform many of the same instructions, so that can even things out in terms of pure number crunching. Then it gets into more complex issues like the bus, and the video processor. The main thing though is that the SNES isn't as "obviously" underpowered as it may seem just looking at clock speed.
@smoreon "Wouldn't it have been much more practical to just spend $10-20 more on the hardware itself..."
The issue is that not only would the cost of the system increased (when it was already more expensive than the Sega MegaDrive/Genesis), and likely delayed the system to add more hardware to the design, but it could've potentially locked out chips like the SuperFX being included in carts later. The SuperFX simply didn't exist when the SNES launched, so we may have lost out on StarFox and even Doom on SNES if Nintendo had opted to make stronger base hardware at launch, instead of opting to allow for expansion chips in carts.
Also, just because the Pi is running at 150MHz doesn't mean the performance is drastically better than a SuperFX chip. Keep in mind that the Pi is EMULATING the SuperFX chip, so there's slowdown being introduced there. As the "SFX3" designation implies, it's likely more performant than an SFX2 chip, but it's possible Nintendo could've produced a real "SFX3" chip back in the day. LRG is going with Pi emulation because that's the cheaper option nowadays.
@snaphat My mistake, they don't say that they looked at the Verilog code for MMC5, but for MMC3, from the article: "we fiddled around with existing mappers — mostly MMC3 — until Dominic got around to looking at the Verilog source code for it on the PowerPak and gaining confidence that he could do the R&D necessary to fulfill my vision."
Still, source code for a Verilog implementation exists for the MMC5, so they at least have a way to compare Verilog implamentions to their mapper.
As for excluding the expansion audio code, that was in the blog post made back when they were going to make a version of the cart without expansion audio. " Feature 13 is also merely stubbed, because we are creating three different types of cartridges for Former Dawn — one with a genuine Yamaha YM2610 ASIC inside, one with simulated YM2610 audio synthesis coinhabiting the FPGA that implements MXM-1, and one without expansion audio entirely." So that exclusion made sense at the time. Also, limiting it to MMC5 complexity was a goal, but not an absolute "We reserve the right to end up at a place where MXM-0/MXM-1 is marginally more complex than MMC5, but will strive to be reasonable and keep it under control as we finalize the design."
For CD-ROM size, I think you're confusing CD-R capacity with what could be on a pressed disc. the PS1 had some game discs with over 700MB of data. Also, why they're programming the mapper to address up to 4x that amount, they state that the the game itself would "only need 239MiB" and the rest would depend on how much FMV they add. Also,. the MSU-1 mapper offers up to 4GB of data, even though that was nominally designed as an "SNES CD" type enhancement, so there's some precedent for having more than a "realistic" storage size from the era in a modern mapper.
Some of their limits are arbitrary, like with no co-processing that the NES itself can exploit for gameplay, since the MMC5 includes some multiplication co-processing, although that may be just to head off what they considered a slippery slope. Like, how much co-processing exactly is allowable? allowing co-processing of the data coming in is somewhat reasonable, since the SegaCD did that.
Finally, it's ultimately speculative, whatever new mapper chip is made, since it's a new mapper that wasn't made back then. They've put the constraints in that they think make sense, while allowing them to make the game they want. To me, some of the better changes seem more realistic for the era, like 8×1 attributes and 4 nametables.
@snaphat I found a blog post title "Unlocking the NES (for Former Dawn)" posted on January 31, 2022 on the blog on the dev studio's site that goes into their explanations and reasoning for nearly everything you touch on.
For the expansion audio, that's something built into the Famicom, and many Famicom games took advantage of it back in the day. However, when Nintendo made the NES, they moved the expansion audio pins from the cartridge port, and put them on the expansion port on the bottom. The speculation is that Nintendo planned to introduce a floppy disk system, and possibly other accessories, and wanted them to be able to take advantage of the expansion audio. This technically locked out NES carts from including expansion audio themselves. However, the NES carriage slot pinout includes pins to the expansion slot, so an add-on could communicate with a cart directly, but since no add-on was ever officially released, a bodge was later developed to map cartridge expansion audio to one of these connections to the expansion port, then bridge that pin to the pin for expansion audio, which the NES would then mix in. This has primarily been used for playing Famicom carts with expansion audio on an NES. However, when Nintendo released the top-loader NES, they dropped the expansion port, so now there's no easy way to bridge a cartridge pin to the audio system of the top-loader NES. You can still mod the top-loader to do it with some soldering skills, look up "Expansion (EXP) Audio Mod", but it's not as easy as providing a simple box to plug unto the expansion port on the bottom of the side-loader NES.
As for comparison of complexity with the MMC5, given that in this article they state they looked at the " Verilog source code," I'm guessing they're doing a LUT to LUT comparison, looking at the FPGA implementation of the MMC5. Now, granted, that FPGA implementation may differ from the MMC5 ASIC used back in the day, but it's probably pretty close, and comparing both in FPGA form does make it more apples-to-apples.
Comments 5
Re: Developer Of SNES DOOM Defends The Tech Behind Limited Run's 2025 Update
@BulkSlash Looking into it, it seems like the extra PINs some carts have aren't 100% necessary for expansion chips in carts. I found this old Reddit comment about those pins:
"Doom, Yoshi's Island, Star Fox and a few other games use Super FX chips, and the Super Game Boy has an actual Game Boy inside. The pins are there to connect them to the SNES's clock, but I think on Doom and Yoshi's Island they're not actually connected and the chips use their own clocks. I think every DSP chip had its own clock, so none of their boards were made with those pins."
Now, the pins aren't JUST the SNES clock. There's also PINs for Address Bus B lines, and audio input from the cart for any with additional sound chips. But it seems if the expansion chip doesn't need the SNES system clock, and doesn't need Address Bus B, then it can work without them. Doom maybe had them because it was developed using a modified StarFox cart, and it wasn't until this remaster that they figured out they could configure the game to run without those extra pins.
Re: Hands On: 30 Years On, DOOM's "Super FX 3" Upgrade Gives SNES Players A More Polished Way To Rip And Tear
@smoreon You can't just look at clock speeds when comparing different CPU architectures. While the Genesis/MegaDrive CPU has almost twice the clock of the SNES one, the SNES CPU takes half the clock cycles to perform many of the same instructions, so that can even things out in terms of pure number crunching. Then it gets into more complex issues like the bus, and the video processor. The main thing though is that the SNES isn't as "obviously" underpowered as it may seem just looking at clock speed.
Re: Hands On: 30 Years On, DOOM's "Super FX 3" Upgrade Gives SNES Players A More Polished Way To Rip And Tear
@smoreon "Wouldn't it have been much more practical to just spend $10-20 more on the hardware itself..."
The issue is that not only would the cost of the system increased (when it was already more expensive than the Sega MegaDrive/Genesis), and likely delayed the system to add more hardware to the design, but it could've potentially locked out chips like the SuperFX being included in carts later. The SuperFX simply didn't exist when the SNES launched, so we may have lost out on StarFox and even Doom on SNES if Nintendo had opted to make stronger base hardware at launch, instead of opting to allow for expansion chips in carts.
Also, just because the Pi is running at 150MHz doesn't mean the performance is drastically better than a SuperFX chip. Keep in mind that the Pi is EMULATING the SuperFX chip, so there's slowdown being introduced there. As the "SFX3" designation implies, it's likely more performant than an SFX2 chip, but it's possible Nintendo could've produced a real "SFX3" chip back in the day. LRG is going with Pi emulation because that's the cheaper option nowadays.
Re: Interview: How NES RPG Former Dawn Is Bringing CD-ROM Power To Nintendo's 8-Bit System
@snaphat My mistake, they don't say that they looked at the Verilog code for MMC5, but for MMC3, from the article: "we fiddled around with existing mappers — mostly MMC3 — until Dominic got around to looking at the Verilog source code for it on the PowerPak and gaining confidence that he could do the R&D necessary to fulfill my vision."
Still, source code for a Verilog implementation exists for the MMC5, so they at least have a way to compare Verilog implamentions to their mapper.
As for excluding the expansion audio code, that was in the blog post made back when they were going to make a version of the cart without expansion audio. " Feature 13 is also merely stubbed, because we are creating three different types of cartridges for Former Dawn — one with a genuine Yamaha YM2610 ASIC inside, one with simulated YM2610 audio synthesis coinhabiting the FPGA that implements MXM-1, and one without expansion audio entirely." So that exclusion made sense at the time. Also, limiting it to MMC5 complexity was a goal, but not an absolute "We reserve the right to end up at a place where MXM-0/MXM-1 is marginally more complex than MMC5, but will strive to be reasonable and keep it under control as we finalize the design."
For CD-ROM size, I think you're confusing CD-R capacity with what could be on a pressed disc. the PS1 had some game discs with over 700MB of data. Also, why they're programming the mapper to address up to 4x that amount, they state that the the game itself would "only need 239MiB" and the rest would depend on how much FMV they add. Also,. the MSU-1 mapper offers up to 4GB of data, even though that was nominally designed as an "SNES CD" type enhancement, so there's some precedent for having more than a "realistic" storage size from the era in a modern mapper.
Some of their limits are arbitrary, like with no co-processing that the NES itself can exploit for gameplay, since the MMC5 includes some multiplication co-processing, although that may be just to head off what they considered a slippery slope. Like, how much co-processing exactly is allowable? allowing co-processing of the data coming in is somewhat reasonable, since the SegaCD did that.
Finally, it's ultimately speculative, whatever new mapper chip is made, since it's a new mapper that wasn't made back then. They've put the constraints in that they think make sense, while allowing them to make the game they want. To me, some of the better changes seem more realistic for the era, like 8×1 attributes and 4 nametables.
Re: Interview: How NES RPG Former Dawn Is Bringing CD-ROM Power To Nintendo's 8-Bit System
@snaphat I found a blog post title "Unlocking the NES (for Former Dawn)" posted on January 31, 2022 on the blog on the dev studio's site that goes into their explanations and reasoning for nearly everything you touch on.
For the expansion audio, that's something built into the Famicom, and many Famicom games took advantage of it back in the day. However, when Nintendo made the NES, they moved the expansion audio pins from the cartridge port, and put them on the expansion port on the bottom. The speculation is that Nintendo planned to introduce a floppy disk system, and possibly other accessories, and wanted them to be able to take advantage of the expansion audio. This technically locked out NES carts from including expansion audio themselves. However, the NES carriage slot pinout includes pins to the expansion slot, so an add-on could communicate with a cart directly, but since no add-on was ever officially released, a bodge was later developed to map cartridge expansion audio to one of these connections to the expansion port, then bridge that pin to the pin for expansion audio, which the NES would then mix in. This has primarily been used for playing Famicom carts with expansion audio on an NES. However, when Nintendo released the top-loader NES, they dropped the expansion port, so now there's no easy way to bridge a cartridge pin to the audio system of the top-loader NES. You can still mod the top-loader to do it with some soldering skills, look up "Expansion (EXP) Audio Mod", but it's not as easy as providing a simple box to plug unto the expansion port on the bottom of the side-loader NES.
As for comparison of complexity with the MMC5, given that in this article they state they looked at the " Verilog source code," I'm guessing they're doing a LUT to LUT comparison, looking at the FPGA implementation of the MMC5. Now, granted, that FPGA implementation may differ from the MMC5 ASIC used back in the day, but it's probably pretty close, and comparing both in FPGA form does make it more apples-to-apples.