Simple ROM to test power on or reset RAM state

I found this ROM I made a while back for testing the RAM startup/reset state on my NES. Sharing it in case anybody would find it useful.

It clobbers the low 3 bytes of ZP, and also the top couple of bytes of the stack page, but otherwise just shows RAM on the screen, and you can press up/down to browse the 8 pages. (B and A fill the page with ascending or descending values, was used to test reset state.)

Edit: I think jroatch's coredump ROM is better than this, though, seems to manage not to clobber any bytes at all. Might as well use that instead.

I posted on the Wiki about this, but just in case it's useful to anybody here:

Your archive includes your build scripts but not the source code...

Thanks. Fixed.

I never expected the power up state of RAM to vary so much.

Yeah, I'm completely baffled by it. I'm surprised how often I seem to get repeating 4 bit or 8 bit patterns, in many different arrangements. Every now and then it looks completely random, but most of the time it's got patterned groups-- but what really surprises me is how the patterns change! Maybe it has to do with the physical organization of the chip itself, like it seems like often every 16th bit has mostly the same value, or every 16th or 32nd byte has the same group, etc, but not always! Sometimes it's a pattern in mosty columns and then one column or a few columns are completely random looking.

Previous relevant topics.

Two more

How do I put this or rom like it in an actual cart? Do you just scrap an NES cart, and load the rom on it? and what method do you recommend for putting such a rom on a chip, and where can I get a rom reader/writer and chips? Or does someone have one made or could be made for me for a price to be shipped to me. This is the rom I would like to use: viewtopic.php?f=22&t=11520#p157782

Would this show me the initial ram state of any Front Loader NES?

You can use an old NES board and remove/replace parts from it if you know what you're doing and want to destroy an old game, but I personally would prefer using a new board.

Myself, I had an old ReproPak board from RetroUSB that I soldered chip sockets into. I burned two EPROMs of appropriate size with an old TOP853 EPROM programmer, and put them in the sockets.

The ReproPak isn't available anymore but there are lots of people selling similar NES boards. There's a variety of inexpensive EPROM programmers as well. Old UV EPROM chips are pretty easy to get from eBay. Flash EPROM is easier to get new and can be erased more easily.

If you don't know how to solder, you can get a board with flash EPROM chips already on it, and an inexpensive programmer from INL:
http://www.infiniteneslives.com/nessupplies.php
http://www.infiniteneslives.com/kazzo.php

Thanks for the reply. Which specific item would I need on http://www.infiniteneslives.com/nessupplies.php

The item shown at http://www.infiniteneslives.com/kazzo.php is not available. And the TOP853 USB Universal Programmer is not being sold on Ebay at the moment, do you have another recommendation?

So basically I would buy one of these boards from INL, remove the chip and use a EPROM programmer on it, and then put the chip back in, no soldering needed. Very easy to do?

Also I just read what you wrote about seeing lots of variance on your RAM state at power on. I know with some games, Metroid in particular, which has at least one memory address value taken from the initial state that influences RNG, that some people can get a certain pattern from power on each time, which leads me to believe that this particular address seems to go back to a starting value instead of retaining its last value, though I don't understand how that can be.

This specific test is NROM.


For programming INL's flash boards, you need the kazzo specifically, so I guess wait for new ones to become available.

For programming EPROM generically, there are a lot of different EPROM programmers. Willem makes some popular ones. I can't recommend a specific one. The TOP853 I have is not a "good" one, but there's not really a difference in the end result between one programmer and another as long as they function correctly. I think some people have managed to build an inexpensive one using an arduino as a base.


With INL the boards are designed to be flashed via the carrtridge connector. There is no need to remove the chip.

With non-Flash boards, generally what you want to do is install (solder) a chip socket where the chips go so you can put the EPROM in and out without having to do any soldering between tests.

Here's one alternative board: https://www.game-tech.us/product/reprox/
Though the ReproPak is not being sold anymore, its manual may give you some idea of how these kinds of boards are used: http://www.retrousb.com/product_info.php?products_id=42
There's others too, just search for NES reproduction boards: https://www.muramasaentertainment.com/i ... -nrom.html
Or you can cannibalize an existing NES game: http://callanbrown.com/index.php/basic-nes-reproduction

They're all basically the same design and work the same way, so learning about one will gain useful information about the other.


I'll make a sort of simplified description, probably a little inaccurate but should give the idea:

Bits in RAM are a device that take an existing charge and continually amplify it to maintain it at 0 or 1. When you're powering it on, the signal is very weak, and the circuit is deciding whether a signal that's in a very questionable range should be driven toward 0 or 1.

This is a device with many thousands of those bits. They're made to be reliable within a certain tolerance, but it doesn't matter if the bit splits between 0 and 1 at 0.5, or if it split at 0.4 or 0.6, etc... that doesn't really matter whenever the input signal coming in is strong. To split at exactly 0.5 you'd need the two sides of the amplifier to be perfectly balanced, but in practice you only need them balanced well enough for tolerantly reliable behaviour, so it doesn't have to be that accurate. This difference only really has an effect at power-on, where some particular bits might have a tendency to power on in a 0 or 1 more often.

The weak starting signal is subject to all sorts of noise, existing static charges in the chip, temperature and ambient or interfering electromagnetic radiation in the environment, etc. When the signal is weak enough all sorts of things can be affecting it. When you power off and on an SRAM very quickly, it tends to retain most of the bits it last had in it. When you power it off for longer, the charges tend to drain out and balance into a potentially more consistent starting state. The longer it's powered off, the closer you'll get to the chip's natural starting equilibrium and have the best chance of powering on with a consistent value. (Still only a chance though.)

Not all RAM is created equally, some have stronger tendencies than others. The contents at power-on aren't something the chip has to do anything consistent with, by design it doesn't matter, so there's a ton of variation here. Some might tend tend to have mostly 0, or mostly 1 bits, for example, if the bias is consistent.


Anyhow, this test ROM was designed to to take a look at this kind of thing. The results I found were that mine are indeed pretty random. I didn't even see much tendency when they were powered off for longer times.

As for looking at specific games, you should know that this program initialized a few bytes of RAM in order to operate, but you could easily rebuild it to move those bytes elsewhere if by bad luck they overlap the bytes the games you're interested in use for their uninitialized behaviour that you're trying to target. (This is one reason why it's useful to have a socketed board, or use a flashable one that you can rewrite the chips for. You may need to try different tests. You could also use it to try other mapper-compatible games and experiments as well.)

I don't know about uninitialized behaviour in Metroid, but I do know that it gathers some randomness from how many frames it spends on the title screen, so even if it was a consistent startup value it might need frame perfect input to be consistent after that anyway.

Doing everything I can to get new manufacturing of new programmers ramped up and released by end of this month (March 2018). I failed to get board files out before CNY which caused me to fall short of this goal last month.. If you sign up for the newletter on my homepage you'll get email notification when new products release including the new inlretro/kazzo programmer.

Thanks for the response. It was very informative and good enough to read again in the future to deepen my understanding of it.

Also, I will sign up for the newsletter.

Additionally, for whatever reason the japan release of Metroid was better programmed because the US release seems to have broken its RNG. In the Japan version the RNG is calculated each frame yielding different results per frame. But in the US version, I am told, that the RNG is broken in that the first comparison of these two ram addresses sets the RNG, and no matter all subsequent comparisons the same outcomes is the result. This is how people have been able to get the same Ridley fireball pattern every time based on this phenomenon with certain consoles.

What has really interested the Metroid speedrunning community is that one of these memory addresses is initialized while the other is not, which gives some people a default good pattern or bad pattern. The present world record holder has a top loader that always gives bad pattern on power on, with slight change of good due to power on variance, which 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.

We have also been discussing the influence of PowerPak and Everdrive on this one RNG related uninitialized memory address. Some have reported that they can get a good pattern from power on with their PowerPak and so the discussion has gravitated to the legitimacy of using a flash cart for Metroid since it is "modifying" this address, instead of reliance upon what value is attained through original hardware alone.

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?

Also, speaking of Everdrive, I wonder if there is a way to determine precisely how it compiles its save state file. If someone could find this, and figure out how to convert it to a save file for use with say Bizhawk, we could hypothetically do a save state with the Everdrive of Who Framed Roger Rabbit at the earliest possible moment, and then load this up in Bizhawk with a Lua Script to map out the results we could get from original hardware and confirm that there are actually 4 distinct RNG paths for that game, based on what I read from our other discussion that even if I pressed start on the same frame I would still only have a 25% chance of getting the right RNG.

PowerPak and Everdrive both need to initialize at least some of RAM (if not all of it) to run their menu programs, etc. You could check the source code for their menus to be sure, or run this test ROM to investigate.

I don't think either of them explicitly leaves it cleared as 00s or FFs before running the game, it just boots the game with whatever was leftover. Probably you would have filenames and stuff scattered across it.

So, no, the RAM values at boot from a flash cart are going to be completely different than what you'd get at power-on directly. Probably you'd get the same result every time if you used the same CF/SD card contents and booted from the menu in the same way, not dependent on the underlying NES.

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

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.

Does this seem to be a fair assessment?

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.


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?

"Too long" can have very different meanings for a human and for a computer. One second is a very short time for a human, but an eternity for a computer.

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!