I still don't completely understand from our discussion of Who Framed Roger Rabbit. [...]I bought up a lot of $20 - $40 NES consoles from Ebay to see if I can find a good NES that will help him in this matter. I plan to clean and replace 72 pin connector and resell them.

There are several different sources of randomness available to an NES, but I believe only two were used by commercial-era games:* Value of RAM when it first turns on* Exact timing and values of user input

There are a few others that we've discovered since, but I don't think they're used even by any modern games:* Value of OAM RAM when it first turns on* Values returned from reading $2007 during rendering

Quote:

I must ask, if you happen to know, just before the ROM is loaded, does the PowerPak or Everdrive preset the RAM state to all 00 or FF or something similar in prep to load the ROM, or does it simply load the ROM over what was change only by the operating system from power on?

The PowerPak boot process involves loading a series of 1 KiB programs into NES RAM from $0400-$07FF.

I am still a bit confused about the retention of RAM addresses. If someone plays Metroid and then powers off and back on at a point when the address 002D is say 62, then wouldn't this be the value upon power on as long as it was not powered off for too long, in theory. IF this is so then I am having a hard time integrating the experience that people have with either having a consistently bad RNG or consistently good RNG. If 002D, which changes once per frame, is retained then this should be random and not yield consistency for anyone. But if someone powered off and this value was 62 but then defaulted to say 0 immediately, or 255 immediately, then that would explain the observation of these folks. What are your thoughts?

IIRC, there was discussion on this forum sometime in the past about different SRAM chips (brands) having different values on fresh power-on. It's certain that game developers didn't know this, nor did they really care (and nor should they) -- they either wrote their code based on behaviours they saw at the time on their own consoles, or the code was buggy (e.g. they forgot to zero or pre-initialise some particular RAM value, but didn't notice the bug because most of the time the game worked). There are plenty of cases of this, and that list is far from thorough!

Aside from weird edge cases, ex. games that rely on some pre-initialised values (i.e. these games are actually buggy -- this has been discussed before in this thread (warning: long and difficult to follow, cannot be reliably skimmed, is mainly with emulators in mind, and gets very technical very quickly; Metroid is mentioned, just not with regards to ZP/RAM but rather CHR-RAM), literally the only community that cares about this are speedrunners. I understand why, but the obsession starts to become excessive. Eventually said community will have to accept reality: there are going to be a small subset of games where, depending on their programming (WRT the subject we're discussing), variance in behaviour because of either bugs or intentional design happens. You can't have a truly "fair" competition if Person X ends up getting lucky with a power-on value that gives them an advantage, while Person Y gets screwed over. Solving this is easy: remove said game(s) from the competitive list. The technical users in speedrun and TAS communities are incredibly good at finding games that are subject to this type of thing, so if anything, they should be contributing to the Wiki to list off technical details of quirks/bugs they find of this type.

So from your first paragraph you seem to be saying that when you power off, this 002D address value is not retained but reverts to some kind of default value that is particular to the brand of chip used? And if so, why does it change or revert back this state, if it is power cycled quickly. Does it really bleed off so quickly?

Even the runners who have biased outcomes experience some variance. So maybe, if it is powered off for 10 or more seconds, it will go back to this natural raw state, but if you do 5 to 9 second wait time between power cycles maybe there is some retention. This would explain both a kind of consistency, and the variance.

So from your first paragraph you seem to be saying that when you power off, this 002D address value is not retained but reverts to some kind of default value that is particular to the brand of chip used? And if so, why does it change or revert back this state, if it is power cycled quickly. Does it really bleed off so quickly?

There's nothing special about "this 002D address" (meaning: $002D isn't anything unique, it's just a memory address) when talking about the NES. It may be unique for a specific game, but not the console. It's just an address located within the $0000 to $07FF memory region of the NES, which is mapped to a physical 2KByte SRAM chip within the NES console itself. The NES memory map is here: https://wiki.nesdev.com/w/index.php/CPU_memory_map

Nintendo used whatever SRAM chips were available on the market at the time (this is not uncommon even today, for any company). They didn't stick with just one company, but they probably used a set list of manufacturers (i.e. they probably didn't just go to Akihabara and buy random chips some shady guy on the street was selling ;-) ); I believe some companies/brands were mentioned in the past but I can't remember who they were. Anyway, unbeknownst to folks who weren't old enough to remember, during the 80s, particularly around the time of the Famicom and NES, there were IC shortages occurring (reference), which is why in a lot of electronics from that time period you'll find differences in IC manufacturer (ex. some expensive 80s gadget might have Sony chips, but the one your friend bought a month later might have Mitsubishi chips).

Different manufacturers' chips behave slightly differently. Yes, they're all SRAM, but power-on values and how fast values dissipate from SRAM once voltage has been lost vary. Voltage, timing/interval/duration, and overall manufacturing implementation all seem to matter. There was a StackExchange discussion about this very thing (warning: low-level hardware discussion). I'm not a hardware engineer -- there are many here better suited to talk about this behaviour in detail. My point is that there are several factors involved, and it's impossible to get a 100% reproducible test case that can be used reliably (re: for speedrunners).

rainwarrior writing a program that shows RAM contents on reset (particularly for power-on) is useful because possibly someone with a lot of time and money (i.e. possession of many variations of NES consoles, Famicom consoles, Dendy consoles, etc.) could potentially see if there is a common behaviour. At this time all that's known is what's been discussed here on the nesdev forum, and what's on the Wiki.

The one exception are devices like the PowerPak, which use sthe NES's RAM for several purposes (ex. menu interface, etc.), and as such, $0000-07FF may contain values that the PowerPak itself set/used (i.e. different than ones at power-on). I assume the EverDrive N8 is the same way. From a software (game developer) perspective, non-battery-backed RAM contents on power-on should be treated as unstable/unknown, so if a constant startup value is needed, the game code must initialise it. The NES (in software) does not have a way to differentiate power-on vs. pressing of the reset button. Common practise is for a game to zero $0000-07FF on reset, but some games didn't do this, while others *intentionally* don't zero certain addresses -- a good example is Zanac, where if you press Reset thirteen (13) times, you can get a stage select -- the way this works is that the game's reset handler increments a value in RAM every time reset is pressed, and has code to say if the value >= 13 then allow for a stage select. Could that RAM location used for storing how many times reset has been pressed happen to have a power-on value of, say, 11 due to SRAM variance, thus the person would only have to hit Reset 2 times? Sure, absolutely. That's just the reality (risk) of the programmer doing that. The same risk applies to games which tried to use "random power-on values in RAM" as a form of RNG seed -- it's a bizarre/faulty thought process, but it's what some did.

CLChambers00 wrote:

Even the runners who have biased outcomes experience some variance. So maybe, if it is powered off for 10 or more seconds, it will go back to this natural raw state, but if you do 5 to 9 second wait time between power cycles maybe there is some retention. This would explain both a kind of consistency, and the variance.

Does this seem to be a fair assessment?

Sure, I suppose. Just understand there's not going to be any kind of 100% reliable consistency to it, because there are just too many factors. Games which don't initialise RAM on power-on/reset are "dangerous" like that. The best you can do is tell all speedrunners to power off the NES units for some arbitrary time (10 seconds seems reasonable), power the systems on, and pray the values in RAM are all zero. If that's good enough for a tournament (I don't make the rules), then thumbs up!

If you can get permission from a game's publisher to perform a speedrun of its copyrighted game publicly in the stream or VOD of a tournament, why can't you get permission from the same publisher to produce and use a hack that fixes memory initialization errors?

Thanks again folks for helping me understand all this a little better. Thankfully, with several trials with a top loader, two front loaders, a Metroid cart, and an Everdrive, I have been able to gather some data and the power off for 10 seconds with the cart was very consistent, like 10 out of 10 consistent in getting a certain pattern. All the info here has helped me so I greatly appreciate all of your time, as usual!

Who is online

Users browsing this forum: No registered users and 13 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum