chronicleroflegends
Member
So, a long time back I asked about the possibility of saving with Nesmaker.
The general consensus was that it was too far off, though Kasumi linked me to a library to get started in the right direction.
http://nesmakers.com/viewtopic.php?t=867
In the time since then, I have had a lot more practice with ASM, and I am not so scared to experiment a bit. That being said,
I still feel this is out of my skill level. There are quite a few things I still do not understand.
I have been digging around in the scripts, and it looks like Joe started to implement a save system starting from the same library that Kasumi linked.
You can find the necessary variables defined but disabled in the Zero Page Ram.
Joe may bring us an implementation of this in a future update, but it is not likely to be a priority for a while. I thought we may be able to figure it out through discussion
and experimentation.
Here is what I know so far:
- We have a set of variables defined but disabled in the Zero Page ram that are used to point to a target bank, and specific addresses to write to one byte at a time.
- Based on comments around these variables, it appears that the empty bank 18 was intended to be used for saving, whether it was to store the saving code there or the
save itself I do not know.
- The library that Kasumi linked from the nesdev wiki has macros and subroutines for:
- Check if the cartridge supports saving
- Verifying a byte at a specific memory location (Checking to see if the byte we are writing has the same value as one already written, so we can skip writing it)
- Write a byte to a memory address.
- It seems to depend on a subroutine I do not recognize. 'FlashRamPage'. I am not sure if this is a subroutine already defined in Nesmaker somewhere else, or if it is
a missing piece that needs to be made.
- Flash saving seems to depend on having the code that handles it executed from RAM.
Here is what I am guessing:
- Bank 18 was left blank either for the purpose of storing the code that handles saving, or to have space for the save itself (or both?)
What I know about saving (serialization) from working with other game engines:
- With a lot of emulators, you can save your games 'state'. This saves a snapshot of ALL the games data, usually allowing you to start back from the moment you saved. An NES cartridge, and most games do not work that way.
- To save your game you must 'serialize' its important data.
- An exact snapshot of everything that exists in your game is unreasonable and unnecessary.
- Instead you want to save only what data is necessary to appear to save your progress ex:
-Screen player is on
-Screen position
-Player health
-Player Score (and any other stats)
-Screen Triggers
-Any other necessary user variables you have created that their value needs to be saved.
So, in Nesmaker if we can get the saving working, I think this is the way we would go about it.
Go through and write all the necessary bytes (screen triggers will take up a lot of space at 32) to the memory location designated for saving.
When we load, through a menu option or whatever, we read each of these values from their location in the save data and store them back in their original variables. Then warp to the screen.
The general consensus was that it was too far off, though Kasumi linked me to a library to get started in the right direction.
http://nesmakers.com/viewtopic.php?t=867
In the time since then, I have had a lot more practice with ASM, and I am not so scared to experiment a bit. That being said,
I still feel this is out of my skill level. There are quite a few things I still do not understand.
I have been digging around in the scripts, and it looks like Joe started to implement a save system starting from the same library that Kasumi linked.
You can find the necessary variables defined but disabled in the Zero Page Ram.
Joe may bring us an implementation of this in a future update, but it is not likely to be a priority for a while. I thought we may be able to figure it out through discussion
and experimentation.
Here is what I know so far:
- We have a set of variables defined but disabled in the Zero Page ram that are used to point to a target bank, and specific addresses to write to one byte at a time.
- Based on comments around these variables, it appears that the empty bank 18 was intended to be used for saving, whether it was to store the saving code there or the
save itself I do not know.
- The library that Kasumi linked from the nesdev wiki has macros and subroutines for:
- Check if the cartridge supports saving
- Verifying a byte at a specific memory location (Checking to see if the byte we are writing has the same value as one already written, so we can skip writing it)
- Write a byte to a memory address.
- It seems to depend on a subroutine I do not recognize. 'FlashRamPage'. I am not sure if this is a subroutine already defined in Nesmaker somewhere else, or if it is
a missing piece that needs to be made.
- Flash saving seems to depend on having the code that handles it executed from RAM.
Here is what I am guessing:
- Bank 18 was left blank either for the purpose of storing the code that handles saving, or to have space for the save itself (or both?)
What I know about saving (serialization) from working with other game engines:
- With a lot of emulators, you can save your games 'state'. This saves a snapshot of ALL the games data, usually allowing you to start back from the moment you saved. An NES cartridge, and most games do not work that way.
- To save your game you must 'serialize' its important data.
- An exact snapshot of everything that exists in your game is unreasonable and unnecessary.
- Instead you want to save only what data is necessary to appear to save your progress ex:
-Screen player is on
-Screen position
-Player health
-Player Score (and any other stats)
-Screen Triggers
-Any other necessary user variables you have created that their value needs to be saved.
So, in Nesmaker if we can get the saving working, I think this is the way we would go about it.
Go through and write all the necessary bytes (screen triggers will take up a lot of space at 32) to the memory location designated for saving.
When we load, through a menu option or whatever, we read each of these values from their location in the save data and store them back in their original variables. Then warp to the screen.