@sanmansan It being on an FPGA at that price does make sense.
@AJB83 It does indeed appear to be very very competently done
One of the things that impressed me with the footage was how they were able to animate the large sprites like they have in the video during battle. Later, I realized they are probably actually putting the sprite animations on the background layers and swapping the nametables on a per frame basis
@marsilies The 239 MiB claim is "even if the OST were 2 hours long and stored as raw 7-bit 33.1 kHz mono PCM, we would only need 239 MiB." This seems to apply to audio data, not game data. To my knowledge, they haven't specified the storage needed for the game itself. However, if the game data exceeded what could feasibly fit on the hardware, they would have needed a CD-ROM, even if it were just one disc.
The PS1, released in the mid-'90s (1994–1995), is from a different generation than the NES. Its CD-ROMs were initially 660 MB (629 MiB) with a 2x speed, which wouldn't meet the stated requirements. It's unclear to me if later PS1 discs held more than 700 MB, but that's irrelevant, since the PS1 came years after the NES. Back in the NES era, CD-ROMs had much lower capacities and slower speeds.
Regarding the MSU-1, the issue with the MXM1 mapper isn't whether it's theoretically possible to support 4GB of data with add-ons, but whether the technology of the time could realistically supported it. The MSU-1 wouldn't have been feasible back then. AFAIK, nobody claims that it could have. If the argument is that a mapper could theoretically support it, that's a separate point.
Regarding slippery-slope arguments, similar points can always be made for CD-ROMs or co-processing add-ons, but the key issue is what could have realistically been produced with the available technology of the era. If an add-on exceeds the speed or capacity limits of its era, or requires retroactive adjustments (ala non-existent CD-ROM technology), it's clear it wouldn't have been feasible at the time. And we know that the required data size exceeds both the SNES CD-ROM (which was never released) and technologies that emerged years later, so it's not realistic for that time.
Beyond that I make no claim. 8x1 attributes and 4 nametables may or not be realistic for the time period. I haven't looked into it.
@marsilies That's the blog post where the things I discussed came from. Regarding the expansion audio: noted, it makes sense then that their game wouldn't work with the NES2.
They don't claim to have implemented MMC5 in Verilog but instead mention learning Verilog to create their own mapper AFAIK. To fairly compare LUT usage, they would need to implement and synthesize both mappers. Even then, such a comparison is flawed—LUTs don’t directly correspond to gate counts, vary across FPGAs, and can suffer from underutilization or poor HDL design, leading to overuse of resources. Vendor IP cores could also skew results, making this kind of comparison unreliable and potentially misleading.
They excluded the audio and SD card implementations from their complexity comparison, claiming fairness because MMC5 audio was also excluded. However, the audio hardware in question is far more complex than MMC5's. As for the SD card, they argue that a theoretical CD-ROM add-on with equivalent functionality could have offloaded the work to an ASIC. This logic is inconsistent, as they reject a similar argument for coprocessor add-ons outside of the cart. Additionally, their scenario of a late 80s/early 90s 4-CD-ROM + cart game seems financially unrealistic.
Moreover, their assumptions about a CD-ROM add-on don’t align with historical constraints. They propose direct access to 768MiB, but CD-ROMs of the time maxed out at 650MB (619MiB). While 900MB (858MiB) CD-Rs existed in 1999, they lacked redundancy and weren’t reliable for critical data. They also assume >600KiB/s transfer speeds (quad-speed CD-ROM), yet quad-speed drives didn’t debut until 1994, and double-speed drives in 1992. Before 1992, Philips even held a patent limiting CD-ROMs to 1x speed (150KiB/s). (I checked all of the details for this information)
Unless they’re suggesting Nintendo would’ve released a CD-ROM add-on for the NES in 1994—two years after the SNES launched and well into N64 development—this timeline doesn’t make sense. Nintendo’s 1990 collaboration with Philips on an SNES CD-ROM drive failed to launch, and its specs were far below the requirements they propose. Additionally, if their CD-ROM assumptions include unrealistic data timing and reliability solved by SD cards, they overlook the challenges of using actual CD-ROM technology of the era.
@TransmitHim I looked the other day when I saw the project. For some reason it's important to them that the project be seen as legitimate NES project. They've been trying to push that narrative for years if you check their YouTube, reddit, and the nesdev forums. Seems like it's a big point of contention for the head guy.
It's pretty weird for them to try to claim like 35 years later with hindsight 20/20, modern tools, modern photolithography and process sizes, FPGAs, modern art tools, modern art tool, and software simulators that such a thing almost happened back in the day.
They are using pretty much unlimited memory (2.8gb) from the perspective of games of that time (with some argument about how because cd-roms existed back then they could have theoretically used something like that to store all the data)and have their own audio subsystem implemented in hardware requiring some expansion. (It doesn't work on the top loader nes for some reason because of this). They also have sdcard support for indirect memory access. Then they claim their mapper is simpler than the most complicated one that was made back in the day (MMC5). At one point they seemed to be counting FPGA usage for their HDL implementation as some sort of argument that their mapper was simpler. They purposely ignored the size of the sdcard and audio subsystem circuit usage though for some reason. Moreover, you can't use an FPGA LUT usage as an estimate for ASIC gate usage.
Unless they were able to implement all of their stuff using an 8um process ASIC and have it fit on a real standard cart (no flash cart), it's a pretty unbelievable claim
Comments 4
Re: Interview: How NES RPG Former Dawn Is Bringing CD-ROM Power To Nintendo's 8-Bit System
@sanmansan It being on an FPGA at that price does make sense.
@AJB83 It does indeed appear to be very very competently done
One of the things that impressed me with the footage was how they were able to animate the large sprites like they have in the video during battle. Later, I realized they are probably actually putting the sprite animations on the background layers and swapping the nametables on a per frame basis
Re: Interview: How NES RPG Former Dawn Is Bringing CD-ROM Power To Nintendo's 8-Bit System
@marsilies The 239 MiB claim is "even if the OST were 2 hours long and stored as raw 7-bit 33.1 kHz mono PCM, we would only need 239 MiB." This seems to apply to audio data, not game data. To my knowledge, they haven't specified the storage needed for the game itself. However, if the game data exceeded what could feasibly fit on the hardware, they would have needed a CD-ROM, even if it were just one disc.
The PS1, released in the mid-'90s (1994–1995), is from a different generation than the NES. Its CD-ROMs were initially 660 MB (629 MiB) with a 2x speed, which wouldn't meet the stated requirements. It's unclear to me if later PS1 discs held more than 700 MB, but that's irrelevant, since the PS1 came years after the NES. Back in the NES era, CD-ROMs had much lower capacities and slower speeds.
Regarding the MSU-1, the issue with the MXM1 mapper isn't whether it's theoretically possible to support 4GB of data with add-ons, but whether the technology of the time could realistically supported it. The MSU-1 wouldn't have been feasible back then. AFAIK, nobody claims that it could have. If the argument is that a mapper could theoretically support it, that's a separate point.
Regarding slippery-slope arguments, similar points can always be made for CD-ROMs or co-processing add-ons, but the key issue is what could have realistically been produced with the available technology of the era. If an add-on exceeds the speed or capacity limits of its era, or requires retroactive adjustments (ala non-existent CD-ROM technology), it's clear it wouldn't have been feasible at the time. And we know that the required data size exceeds both the SNES CD-ROM (which was never released) and technologies that emerged years later, so it's not realistic for that time.
Beyond that I make no claim. 8x1 attributes and 4 nametables may or not be realistic for the time period. I haven't looked into it.
Re: Interview: How NES RPG Former Dawn Is Bringing CD-ROM Power To Nintendo's 8-Bit System
@marsilies That's the blog post where the things I discussed came from. Regarding the expansion audio: noted, it makes sense then that their game wouldn't work with the NES2.
They don't claim to have implemented MMC5 in Verilog but instead mention learning Verilog to create their own mapper AFAIK. To fairly compare LUT usage, they would need to implement and synthesize both mappers. Even then, such a comparison is flawed—LUTs don’t directly correspond to gate counts, vary across FPGAs, and can suffer from underutilization or poor HDL design, leading to overuse of resources. Vendor IP cores could also skew results, making this kind of comparison unreliable and potentially misleading.
They excluded the audio and SD card implementations from their complexity comparison, claiming fairness because MMC5 audio was also excluded. However, the audio hardware in question is far more complex than MMC5's. As for the SD card, they argue that a theoretical CD-ROM add-on with equivalent functionality could have offloaded the work to an ASIC. This logic is inconsistent, as they reject a similar argument for coprocessor add-ons outside of the cart. Additionally, their scenario of a late 80s/early 90s 4-CD-ROM + cart game seems financially unrealistic.
Moreover, their assumptions about a CD-ROM add-on don’t align with historical constraints. They propose direct access to 768MiB, but CD-ROMs of the time maxed out at 650MB (619MiB). While 900MB (858MiB) CD-Rs existed in 1999, they lacked redundancy and weren’t reliable for critical data. They also assume >600KiB/s transfer speeds (quad-speed CD-ROM), yet quad-speed drives didn’t debut until 1994, and double-speed drives in 1992. Before 1992, Philips even held a patent limiting CD-ROMs to 1x speed (150KiB/s). (I checked all of the details for this information)
Unless they’re suggesting Nintendo would’ve released a CD-ROM add-on for the NES in 1994—two years after the SNES launched and well into N64 development—this timeline doesn’t make sense. Nintendo’s 1990 collaboration with Philips on an SNES CD-ROM drive failed to launch, and its specs were far below the requirements they propose. Additionally, if their CD-ROM assumptions include unrealistic data timing and reliability solved by SD cards, they overlook the challenges of using actual CD-ROM technology of the era.
Re: Interview: How NES RPG Former Dawn Is Bringing CD-ROM Power To Nintendo's 8-Bit System
@TransmitHim I looked the other day when I saw the project. For some reason it's important to them that the project be seen as legitimate NES project. They've been trying to push that narrative for years if you check their YouTube, reddit, and the nesdev forums. Seems like it's a big point of contention for the head guy.
It's pretty weird for them to try to claim like 35 years later with hindsight 20/20, modern tools, modern photolithography and process sizes, FPGAs, modern art tools, modern art tool, and software simulators that such a thing almost happened back in the day.
They are using pretty much unlimited memory (2.8gb) from the perspective of games of that time (with some argument about how because cd-roms existed back then they could have theoretically used something like that to store all the data)and have their own audio subsystem implemented in hardware requiring some expansion. (It doesn't work on the top loader nes for some reason because of this). They also have sdcard support for indirect memory access. Then they claim their mapper is simpler than the most complicated one that was made back in the day (MMC5). At one point they seemed to be counting FPGA usage for their HDL implementation as some sort of argument that their mapper was simpler. They purposely ignored the size of the sdcard and audio subsystem circuit usage though for some reason. Moreover, you can't use an FPGA LUT usage as an estimate for ASIC gate usage.
Unless they were able to implement all of their stuff using an 8um process ASIC and have it fit on a real standard cart (no flash cart), it's a pretty unbelievable claim