Since you're addressing specific points, let's see if anything productive can come out of this. I just don't want to be part of a pointless "my way is better" discussion.
rainwarrior wrote:tokumaru wrote:...failing to (re)initialize memory you do use is another (type of bug)...
I don't understand how this is related to randomizing unallocated areas of RAM. I'm not saying this rhetorically, I'm trying to imagine the process where you have made a mistake in your code and having randomized RAM helps you, and I'm having trouble thinking of the steps where it would make a useful difference. Could you illustrate an example?
Say I just finished coding my title screen state and I want to test it. If I do a few consecutive tests randomizing the RAM using a different seed each time, I have better chances of noticing something I might have forgotten to initialize for that code. Is this technique perfect? No, I might try 10 different seeds and get "lucky" enough for the logic to work (or appear to work) with 10 different random values in a variable I forgot to initialize, but the chances are still greater than if I always tested using the same value ($00).
If your static memory allocation is contiguous, it's not a "huge list", it's just two ranged breakpoints, one for ZP and one for the rest of RAM. Do you have heavily fragmented static allocations?
The NES has very little RAM, so not all projects will allocate RAM linearly and just leave some of it unused at the end. I have a system where memory is shared between modules that don't run concurrently (i.e. the bonus stages and the main game use much of the same memory for completely different purposes), so while an address might be unused from the point of view of one module, it's used from the point of view of another. The memory map looks different as the program runs. But even if you do use RAM in a mostly linear way, you might still have holes if you feel the need to align large arrays so they don't cross page boundaries, for timing reasons or whatever.
What's do you mean by false? If you initialize RAM to 0 those values will be 0. This is completely reliable.
The false sense of security comes from the fact that it's reliable the very first time a piece of code runs, but may not be on subsequent times the same code runs (because you corrupted the variables on the first run). Say I coded the tile screen for my game, booted up the ROM and it works. Yey! Let's move on to something else. Then, weeks later, you're still feeling very confident about your title screen, after all you've been using it for weeks and it never failed. Then you implement the game over functionality that sends you back to the title screen and *BAM*, it's glitched. Your first reaction will probably be to think you screwed up something you coded more recently, and it might take you longer to realize that the bug actually lies on code written weeks ago, code you might not even be particularly familiar with anymore since it's been a while since you coded it.
However, if you do the "randomize RAM a few times" approach while still testing the title screen for the first time, you increase your chances of caching any initialization bugs it might have while all the logic of that part is still fresh in your head, meaning it might even be easier for you to deduce what variable could be causing the undesired behavior you're experiencing. When you finally move on to code something else, the robustness of the title screen will be more real, since you put it to the test under different memory configurations and it survived all of them. Again, not 100% failproof, but better than testing under a single configuration.
I definitely felt it necessary to state my opinion about it in the context of advice to a newcomer.
Believe me, I'm all against giving newcomers bad advice. Every time I see code with that dreadful
STA $2003 ; set the low byte (00) of the RAM address comment that comes straight from the Nerdy Nights tutorials I cringe. On the topic of memory initialization in particular, I just happen to think things aren't as black-or-white as you seem to think. I do understand that zeroed out memory provides a consistent environment for your programs all across the board, but games aren't short-lived linear programs that do their job and end, they're very dynamic and do lots of state changes, so what good is it to provide a consistent environment in the beginning, if the same modules are going to run again after the RAM will have already been trashed since power up?
I'm not opposed to clearing the RAM as an extra safety measure on your release build, but during development, it may give you the false sense of security that your modules are robust when they're actually not, if they neglect to initialize something that just happens to work if it starts out as 0, but fails with other values and you won't know it until you happen to re-run that module after that variable was left in a "bad" state.