nesdev.com

I feel like this is a "I'm asking about X but really I should be asking about Y" situation. And, will naturally evolve into a S.O. style answer of..."don't do X, you should be doing Y".

Can you describe the actual problem that you need solved. Do you need self-modifying code? Could this be done with a simple conditional if/else?

_________________
nesdoug.com -- blog/tutorial on programming for the NES

You wouldn't modify flash for self-modifying code, especially with how slow writing to flash is, not to mention you'd be wearing the flash down.
They meant using the flash to save things without needing to use the battery and extra RAM the Action 53 volumes don't have.

An XY problem is likely, and I encourage FrankenGraphics to describe the goal.

My first guess is that FrankenGraphics wants to write the state of the player's campaign to the cartridge because the game is longer than can be completed in one sitting. The description page for Study Hall brags of "On board flash memory for saving all your high scores/initials and your achievement progress!" This is made possible through the self-flashable variant of the so-called UNROM 512 board.

If this is the case: What all makes up the campaign's state? If it be condensed to 32 bits, an 8-character password becomes practical. The state in The Curse of Possum Hollow is 18 bits (3 for chapter, 6 for bought moves, and 7 for found moves), allowing use of a 5-character password (which provides 25 bits, the rest used for check).

NovaSquirrel and Tepples are correct; We "need" a biggish array to do what we want, which is storing the state of numerous items in One Big Level that's open ended/backtraceable. Unlike a linear sequence of levels, this means we can't just keep track of for example how many keys the player has collected, but rather which specifically which ones has been collected. Same goes for chests and locked doors, maybe boss/es. Not obligatory but neat: health and special status of player character/s. If we're going with switchable characters, they might have different max healths determined by who picks up a container. Even the rooms themselves have theoretically modifiable links which dictates what room leads to another, which enables at least in theory modified duplicates given a switch condition is set or cleared.

If not technically viable, we'll find a way or make do; perhaps downsizing.

_________________
http://www.frankengraphics.com - personal NES blog

"How long a piece of string do you need?" I hope you're bitpacking "collected/destroyed" bits; you can go far without much memory that way. The dynamic room linkages, however, would add up very fast; depending on how often they're used you might want to only linked-list the alterations to the default grid.

As an approximation, a single character of a password can hold 5 bits of information, or one out of 32 values. This means five 2-state variables (key owned or not), three 3-state variables (key not picked up, key in inventory, key transported to corresponding lock), two 5-state variables (this might be your "special status"), or one of each. But if you end up with more than about 70 bits or 14 characters of data that you need to track, it becomes unwieldy to enter the password at the start of the session. If you run a block cipher over the password followed by a consistency check on what doors can be unlocked before others, you might be able to get away with one or two fewer check digits because the consistency check will pick up more invalid passwords, but that's it.

For more specific information, we will need how many is "biggish".

Yeah, we don't want to be the guys with a 104-character password who include a (hidden) apology therefor.

Golden Sun and Zelda Oracle passwords were mighty long, but those were only used once, after completing one game and starting another.

We don't want a 104-string for sure, but we do want the freedom to pack in a multitude of items and also some other states. A password system is going to be a tough act of balance.

Bitpacking, yes.
Exact final number of items: Unknown at this point - we're in the process of defining this feature set.
Please treat everything below as hypothesis, not a list of promises:

Some items (examples: finding a weapon, piece of armour, magic trinket, maybe a tri-force like collectible) are rather easy to compress: if chest n is opened, player has its contents in inventory, and a corresponding key can be assumed to have been removed from inventory.

Some items (examples: consumables: lucky clover, garlic, sage, mushroom, potion of y, potion of x, bombs, iron keys, brass keys, silver keys, gold keys) are inherently complex. They might've been in chests. They might've been on the ground or carried by enemies or hidden in breakable metatiles. Assume 0-9 in inventory.

Each opened door lock will imply a key removed from inventory, just like a chest.

Certain save/password rooms may narrow down the needed info. But sequences of rooms/gauntlets that assume a zero-sum economy (like some passages in zelda) where you get a key, spend a key, get a key, spend a key - are relatively boring and we've agreed on a "No True Path" design.

The theoretical dynamic room linking can actually be just one bit per dynamic link; refering to which pointer to use. Dynamic room linkage (in a few select places) is tempting because it would make the most out of the level storage system, which of course relies on reusing portions. 2 versions of the "same" room may change just the reference of a few portions between version a and b, for quite the dynamic effect - Suddenly, a platform has been lowered or a stair has appeared, or a well has been emptied, a hole in the ground has appeared, an item has 'fallen down' from a room above, and so on.

That makes for a whole other experience alltogether, insofar it's implemented.

Considering all this, we are weighing our options:
1) Make a condensed game that's playable in one sitting; cutting content and making paths short.
2) Balance a feature vs ease of use Password System
3) Make an initially long game where the players' memory substitutes a password system/storage method by learning shortcuts. Example: Solstice, which you basically can't beat in one sitting the first 30 something times, but speedrun once you've figured it all out.

4)Ask if there could be a method for storage other than passwords on the compo cart in this year's compo. Hence the original question.

I want all paths explored to be able to make an assessment on features vs hard truths. I'm italizing the fourth since i'm still interested in what the answer might be.

_________________
http://www.frankengraphics.com - personal NES blog

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

A split might be good, though preferably after Rahsennor has flagged your post as read if that's ok?

I'm thinking about how your chr-ram idea would play out interface-wise.

Basically, the game would be responsible for either:
1) loading the checkpoint into chrram at every important change of states
2) do the same in a 'save room' or 'save menu'.
-either way, somehow declare with sufficient clarity that the player must hit reset for the game to be permanently stored.
-but also make sure the player doesn't mistake it for needing to reset everytime s/he wants to create a checkpoint.

To what effect can the whole package/presentation help getting the message across?

Battery wram:
At least battery backed WRAM would be separate from prg-rom. If you can't write to prg-rom (if it's not flash or somehow in a read mode that disables writing), the only thing save data can corrupt is other save data. Which it simply must not do, but worst case scenario...



This does sound very good. Is there any other caveat, apart from limiting save space?

_________________
http://www.frankengraphics.com - personal NES blog

I feel like it's sleazy to change the mapper rules halfway through for the benefit of one entrant. That's not fair to all the people who have started their programming without feature X.

Also, it is my belief that 64K without extra RAM is a really healthy limit for our contest, and I'm against adding anything extra.

Do the 1 sitting version now, then an expanded version later.

Damn, i didn't even think about it being a competition. If one entrant finds it objectionable, i won't push for it being part of the compo.

I'd be perfectly fine with staying out of the compo (entering as category 2), but:
-if this hypothetical new hardware feature was reserved for non-competing entries only, it'll probably see less use.
-if it sees less use, it's hard to motivate its inclusion in case it adds any extra cost to either r&d or material reproduction; and/or means hours of extra work for infiniteneslives.
-we're two in this project and i can only speak for myself at this point.

The "third way" i can think of is that as far as the compo is concerned, noone assumes saving: Fully implemented saving (be it score boards, campaign status, level unlocks) is subject to disqualification. Non-functional remnants (like having a save room with no function) is not subject to score setting. Then post-compo, implement anything you want saved in your entry. Games that'd be geared for saving would actually have a disadvantage this way, because the saving isn't implemented for judging although the design might be dependent. I don't feel i have a clear overview if that sort of thing would be interesting enough, though. What do you think?


That would at any rate be easier in regards to workload. It'll probably be this or some password related compromise.


I agree that an upper limit of 64k is quite golden. For future compos though, isn't the ability to store letting people be more creative/making content of higher polish with roughly the same workload/constraints?

_________________
http://www.frankengraphics.com - personal NES blog

I don't see any of this as changing the rules. As mentioned the entry should be able to work without save data on the cart. Perhaps via password (however long), maybe even requiring the entire game to played in one sitting.. The entry would be subject to the same rules as everyone else. At this point, we can't promise that saves will be made available on the released hardware. There's lots of work to do in order to get to that point, so don't rely on it being there.

It's notable that there is significant benefit of a long password system paired with save data on cartridge. It makes it much simpler for the average user to transfer save game progress between carts, emulators, etc. Dumping hardware is not required to make backups even if it takes a couple mins to enter in the password. Maybe the password system is a manual hex dump directly into CHR-SAVE-RAM..?

Asking for new useful features, and then being willing to put the effort forth to be the guinea pig is how improvements like this become a reality. As always any number of improvements and feature/content additions are more than welcome in the ~2 months that are between submission deadline, and rom finalization. If we get the ball rolling now, it's much more likely for addition of support for save data on the cart to see reality. That also paves the way to expand the rules for future compos if such a feature is desirable.



Not really on a general hardware basis. Keep in mind that the entirety of this idea is just that, an idea. Lots of work to do in order to realize this idea on functional hardware. I may have more specific caveats you're asking for when hardware development is underway. The other challenge with unconventional features like this is that current emulators don't yet support these features complicating your development and testing.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers