Ram initialization values

[UNHchabo]

So I'm curious about the Low Entropy setting, and how to potentially improve it to model actual hardware behavior -- but I'm a software engineer, and have a limited knowledge of how DRAM works on the circuit level.

To be clear, it would be in my interest as a speedrunner for these values to be less randomized, but most of all I want it to be hardware accurate, I don't want to disable entropy to have an advantage over hardware, but I don't want a disadvantage from excessive randomization either.

I understand that DRAM can keep a charge for some time after it's powered off: https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Data_remanence But if I really wanted to make sure my RAM was completely cleared, and powered off my console for minutes or even hours, what value does the RAM hold at startup? Do the cells trend towards a voltage of 0 over time, just at different rates?

byuu's commit notes say that the values are biased towards 0x00 and 0xff, but this only happens 1 out of every 8 calls, and 75% of the time the "stripes" will have completely random values. I'm curious if this bias should be adjusted, especially given his previous checkin that would always use stripes of 0x00 and 0xff. https://github.com/higan-emu/higan/commits/b38a657192a50aa045c3fdba6424e8eaa885e415/higan/emulator/random.hpp

[Screwtapello]

The most rigorous investigation of power-up memory state I've found is Power-up SRAM State as an Identifying Fingerprint and Source of True Random Numbers (from about 2008), although it's specifically about SRAM rather than DRAM. Since the process described is about the chemical structure of silicon, rather than anything specifically about SRAM circuitry, I assume the basic ideas hold true.

As I understand it, it works like this:

• pure silicon is not a very good semiconductor
• to make silicon useful, it is "doped" with small amounts of specific impurities to change its electrical behaviour
• Those impurities make it more or less likely for electrons to gather in a particular area
• Because adding impurities is a physical process, it's not completely even; some areas will get more impurities than others, and therefore some areas of the chip will naturally have more electrons floating around than others
• The effect is not great, it's not enough to overpower the actual voltages the chip is designed to handle, but at power-on there can be enough electrons pooled together to read as "1" instead of "0"
• So every cell has different "preferred" level of charge that it returns to over time, depending on how much impurity there is in that particular chunk of silicon
• If a cell prefers to be 11% charged, it will probably decay to something that reads as "0" pretty quickly, so it's almost certainly going to be 0 at power-on
• If a cell prefers to be 53% charged, it may take a long time to decay to that value - if it starts at zero and makes it all the way up to 49% it may still read as 0 at power-on despite getting most of the way to its preferred value

The paper I linked to groups every bit of RAM into one of three categories: "always 0 at power-on", "always 1 at power-on", and "random at power on". The exact map of which bits fall into which categories is consistent for every RAM chip, and different between them, so you can use the consistent bits to fingerprint a specific physical chip, and the random bits to generate true random numbers (since they're determined by quantum mechanics).

As for the patterns:

• Again because adding impurities is a physical process, it's geographical - the silicon where the impurities were added will be less pure than the silicon further away
• RAM cells on a chip are laid out as a grid, so cells near the centre are more likely to be 0 (or 1, depending on the impurity) than the cells further away
• We do not read RAM cells by their grid-coordinates, we read them by their address, which is probably related to their grid-coordinates but not identical
  • For example, consecutive RAM cells might be laid out in tiles or a zigzag or a Hilbert curve or something
• Therefore, we should expect to see bytes that are always 0x00 (all the bits of each byte will be clustered together, so we can expect they'll have about the same level of impurity and hence decay to the same value), bytes that are always 0xFF, and bytes that are pretty random
• Probably, all the 0x00 bytes are physically close together on the chip, all the 0xFF bytes are physically close to each other but far from the 0x00 bytes, and the random bytes are all the ones in between

To be clear, it would be in my interest as a speedrunner for these values to be less randomized, but most of all I want it to be hardware accurate

As far as I know, you could pick a state for a few choice bytes in RAM and there's a chance that somewhere out there (possibly in a parallel universe) there's a real, physical SNES that happens to set those bytes to those values at power-on nearly every time, just down to manufacturing tolerances. At this point, "hardware accuracy" is as much a matter for philosophers as electronics engineers.

But if I really wanted to make sure my RAM was completely cleared, and powered off my console for minutes or even hours, what value does the RAM hold at startup?

No idea. If you experiment on your console repeatedly, you'll see patterns emerge, but those are just the patterns for your console, they'll be different for every other console ever made.

Do the cells trend towards a voltage of 0 over time, just at different rates?

Nope. As described above, they trend towards a voltage determined by the quantum randomness of a physical process at the atomic level during the manufacturing process. At different rates.

I'm curious if this bias should be adjusted...

Normally, a memory cell holds a 0 or a 1, but at power-on cells may (I believe) be anything inbetween, and when you read out a voltage something has to decide whether it's "really" a 0 or a 1. That mechanism is probably what produces the bias in question. You could probably do a bunch of investigation, gathering a bunch of power-on states and averaging them, trying to build up a statistical distribution for each bit in the memory map... but then you'd only know about one chip in one specific SNES unit.

I'm not sure we want to go there. It's hard enough to hardware-verify behaviour that's common across all SNES units, never mind trying to verify behaviour that's unique to a specific unit.

[UNHchabo]

Thank you for the very thorough explanation, and for the link to that paper. That's fascinating.

I am interested to see if there's a pattern that would emerge if we did look across a number of consoles -- instead of a flat distribution with spikes at either end, maybe it would be a bathtub curve, for instance.

To gather that data we could make a rom that could run on sd2snes, and save the WRAM state to an SRAM image on the flash card. This is done on the Super Metroid Practice Rom to implement save states, and the main impediment I can think of is the unknown degree to which the sd2snes writes to WRAM from power-on until the rom is loaded. Though this might be found out by overwriting WRAM, exiting out to the sd2snes menu, then loading the rom and writing the WRAM state again.

Feel free to close this, as I don't actually have a feature request. I don't want to request a change without data to back it up. Thanks again for the insights on the subject!