@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 2
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.