Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NES: UNROM-512, GTROM self-flashing support #200

Open
asiekierka opened this issue Sep 14, 2023 · 1 comment
Open

NES: UNROM-512, GTROM self-flashing support #200

asiekierka opened this issue Sep 14, 2023 · 1 comment
Labels
enhancement New feature or request p2

Comments

@asiekierka
Copy link
Contributor

Both cartridge boards can feature an SST39SF040 flash chip for storing the game's data, which allows the game to reflash parts of itself - for instance, using some unused bank area for save data storage.

See this for UNROM-512 docs, and this for a GTROM addendum.

@mysterymath mysterymath added enhancement New feature or request p2 labels Sep 14, 2023
@asiekierka
Copy link
Contributor Author

Due to the peculiarities of self-flashing, code that performs flash operations must live in WRAM.

There's two approaches here:

  • My preferred approach is to use the stack to load a small piece of code (for example, an ASM routine to write a byte of flash), then jump to it. This way, the memory cost is not paid throughout the entirely of the game's execution (and the NES doesn't exactly have a lot of RAM) - however, is the soft/compiled stack capable of ensuring that?
  • Put the code into WRAM always.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request p2
Projects
None yet
Development

No branches or pull requests

2 participants