There was some discussion on the irc today about certain SNES JRPGs (like Tales of Phantasia) having different initial RNG configurations based on whether BizHawk or lsnes was used. After doing some digging, it turned out that the source of the discrepancy was that the game seeds its initial RNG state with values of the RAM prior to initialization. lsnes sets its uninitialized RAM to all 0x55s, while BizHawk apparently uses some fixed pseudorandomly generated RAM state.
This brings up the question of what counts as a "proper," "valid," or "acceptable" initial WRAM configuration. I could not find any documentation on this topic so I thought that I would make a thread for people to discuss their philosophy with regard to this issue and perhaps even some actual data (if anyone has it)!
After some contemplation, I justified the "legitimacy" of my BizHawk run to myself by arguing that since the random number generation only depends on two bytes, the entropy is low enough (65536 states) that it is possible for a snes to power on with the RNG seed that BizHawk generates for it.
But that begs the question, why is it the case that adjusting the initial RAM values is not allowed by site rules? Why is the particular set of random values generated by BizHawk (which more likely than not do not correspond in any way to the values that a physical console would produce) preferred over some customized starting configuration?
Just wondering what people's thoughts are on this matter.
My point exactly. We are giving arbitrary preference to some literally random configurations (which is what both BizHawk and lsnes do; there is no rationale that I can find behind setting everything to 0x55 either) without any good reason for it (as far as I can tell).
Some bits are correlated, some are anti-correlated. This might be true of groups as well. We don't know enough to demonstrate which power on states are valid and which are not.
In order to get sufficient statistical power, as much as a few hundred or few thousands cold power-ons can be be required.
Once this work is complete, the plausibility and possibility of various power on states can be evaluated. Until then, taking the conservative route is prudent.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
But what is the "conservative route?" Taking one (or two) specific strings of RAM and declaring them to be the "legitimate ones" (even though we have no idea whether or not they are actually valid)?
In the absense of information about what RAM configurations are more statistically likely than others, it is acceptable to pick a RAM configuration that is not particularly absurd and does not particularly favour any particular game or TAS above another (should allow for as many games that rely on uninitialized RAM to function as possible, for example).
Almost all TASes on TASVideos are based on emulator specific quirks that might not exist on the hardware (even stuff as subtle as an instruction taking the wrong number of cycles). This is a necessary evil to allow TASes to be published. If all TASes were unpublished except console verified ones, the site would be very bare indeed!
In SNES case, different consoles will have different likely states, different correlations... it will not be universal. One console cannot give us the answers here.
While I don't have a solution to this problem, at a minimum I think it should be noted if a game is known to use uninitialized RAM for any routine that can change the outcome of the game.
Something else to note: console-verified inputs that cannot be played on emulator are also not allowed.