NES counterpart to this Super NES question:
Essentially every volatile RAM in an NES Game Pak is a 6264 (8Kx8 SRAM) or equivalent. NesCartDB queries:
Many such games, including Super Mario Bros. 3 and M.C. Kids, use the extra RAM to cache a decompressed copy of the entire level. This allows the level to be destructible, such as ability to break blocks or collect items. Without extra RAM, the program would need to re-decompress parts of levels that the camera enters each time they're entered. "Programming M.C. Kids" explains how this limits destructibility, as does an older topic here about RAM requirements of destructibility.
I haven't debugged into them, but I'm guessing Qix and Hatris (both SNROM) use it for a frame buffer, as objects in their playfields don't align well to tile boundaries.
Ports from FDS, such as Metroid, Kid Icarus, and Super Mario Bros. 2, needed 8K of extra RAM to substitute for the 32K RAM of the FDS.
Some games have two 8K RAMs, only one battery-backed. These include everything on SOROM and ETROM, all Koei simulations. The memory that is not battery-backed is used as working memory, holding the state of the simulation and scratch memory for the simulator (conjectured to have been translated from a high-level language), and the battery-backed one to hold a saved campaign.
psycopathicteen wrote:
...and how much and for what reason?
Essentially every volatile RAM in an NES Game Pak is a 6264 (8Kx8 SRAM) or equivalent. NesCartDB queries:
- All games with WRAM that isn't battery-backed (61)
- SNROM without a battery (12)
- SKROM without a battery (6)
- TSROM (30)
- JSROM or NES-BTR (1)
- SOROM (3)
- ETROM (5)
Many such games, including Super Mario Bros. 3 and M.C. Kids, use the extra RAM to cache a decompressed copy of the entire level. This allows the level to be destructible, such as ability to break blocks or collect items. Without extra RAM, the program would need to re-decompress parts of levels that the camera enters each time they're entered. "Programming M.C. Kids" explains how this limits destructibility, as does an older topic here about RAM requirements of destructibility.
I haven't debugged into them, but I'm guessing Qix and Hatris (both SNROM) use it for a frame buffer, as objects in their playfields don't align well to tile boundaries.
Ports from FDS, such as Metroid, Kid Icarus, and Super Mario Bros. 2, needed 8K of extra RAM to substitute for the 32K RAM of the FDS.
Some games have two 8K RAMs, only one battery-backed. These include everything on SOROM and ETROM, all Koei simulations. The memory that is not battery-backed is used as working memory, holding the state of the simulation and scratch memory for the simulator (conjectured to have been translated from a high-level language), and the battery-backed one to hold a saved campaign.