So the option of including save data on the final compo cart is entirely possible. The challenge is in actually accessing the flash memories on board, coming up with that interface, and having a means to test it during development.
Until we release a volume with saves enabled any entry looking to utilize save data is subject to being the guinea pig. At this point it's best to not rely on the ability to save data to the cart. Assume it won't be available and provide a password system to supplement the cart save data. Then if we're able to collectively pull of cart save data it'll be a bonus.
Not knowing what the compo turn out will end up looking like it's hard to look into the crystal ball and know what the final hardware will look like. Prior to this year's cart we easily fit on 512KByte flash rom, but this year we broke that boundary and had to step up to 1MByte. That jump fundamentally changed how save data would be stored on PRG-ROM flash due to migrating from 5v flash to 3v flash with differing flash algorithms. On top of that, it's possible/likely that a game will see a future release on a future compilation where all volumes are included on on cart. What will the final hardware look like in that cartridge??? Really hard to know, and there may not be motivation to modify your game's code to support saving onto the new hardware design.
Beyond that, it could be potentially dangerous for a single game to be making flash write/erase commands directly to the flash chip. So I'm wondering if there's a better solution we can come up with that abstracts the save process away from the game's code. One way of abstracting things away would be to have some sort of software helper functions provided by the menu boot rom. But that becomes a challenge as well complicating the development of the menu code which is also subject to hardware changes as mentioned previously.
I do have one idea that might be easier to manage from a software standpoint. There being a total of 32KByte of CHR-RAM on board, perhaps a portion of CHR-RAM could act as the buffer save data space. The game would load it's desired save data into CHR-RAM along with some sort of header/signature to denote the data as valid and what game the data is for as the game is played. The user would have to hit reset when done playing, this hands control back over to the menu code. At boot time the menu code could check the designated area of CHR-RAM for the save data signature. If found, the menu would be responsible for copying the CHR-RAM save data into PRG-ROM flash. It could also display some message to the user "game X data saved successfully". On a subsequent power cycle, when the game is selected in the menu system, the menu code would be responsible for loading save data into CHR-RAM before handing control over to the game.
I have other ideas that takes the burden off of the menu code by performing the abstraction mostly via hardware. One option is to simply splurge on including battery backed PRG-RAM with multiple pages/sections games are allowed to utilize. There might not be a great way to prevent games from corrupting other game's save data though.. A more unconventional method would be to add mapper registers with some sort of read/write request structure that interfaces with the CIC. My asynchronous
CICOprocessor idea would be much easier to pull off with dedicated mapper hardware, allowing save data to be stored in the CIC's eeprom/flash. Something like that would likely limit the amount of total save data to a few KByte tops, but takes the burden from the menu software, and provides great protection from bricking the cart with a PRG-ROM flash save gone awry.
If we'd like to take the discussion further, perhaps it's best to branch off to a new thread..? Kinda feel like I should have done that with this post..
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers