nesdev.com

Just for the sake of completeness, I added the option to Mesen:



Random values typically cause the F-1 Race prototype to have the same behavior as setting everything to $FF - I only saw the menu once in over 40 power cycles, which could imply the console used by whoever was coding this prototype probably usually initialized its ram with 0s.

I tested out river city ransom and it indeed does rely on startup ram to "randomize" enemies.

On nestopia (when the ram was 0xFF) you will ALWAYS get the frat boys

on nestopia (with the new changed 0x00) now it will ALWAYS will be the generic dudes.

So definitely adding an option like the way sour just did would be a good way to go. Up until now i had no idea that startup ram had an influence on these things.

Specifically, it checks if both [$70] and [$6B] are nonzero. Look at $C998 through $C9AC ...

Hence why "random values" looks like same as all $FF; the odds of either of two bytes being zero is roughly 1%.

I have added an option to FCEUX now: https://sourceforge.net/p/fceultra/code/3275/

1. default (the 00 00 00 00 FF FF FF FF pattern it's been using for years)
2. FF
3. 00
4. random

That's probably enough. I don't think there's much reason to offer other things like that "FF except 4 particular values" nonsense, or "here's a set of values that runs every game the way I expect".


WRAM initialization is thornier, FCEUX seems to do it on a board by board basis. (Ugh!) A lot of them use the same code to prepare the memory but I'd have to spend a bit of time working out the ramifications of changing something upstream like that...

Nice work Nestopia and others who implement this should without a doubt follow this setup. Seems to make the most sense!

It will be fun to try the cheetahmen power cycling trick, HAHA. prob for about 5 minutes.

Good point about WRAM, I had forgotten about it. Technically speaking, VRAM/CHR RAM/Sprite RAM would also be the same right? It sounded like palette ram has fixed values that vary from one unit to the other, though?

My main worry is saved RAM though - I just tested Zelda 2 with random saved ram values when no battery file exists, and it seems to work as expected.
Would save ram really be in a random state on a cartridge after putting in a battery, though? (I am mostly clueless about the hardware side of things)
If so, I imagine most games try to read a specific signature inside the saved RAM to ensure the rest of the data is valid?

Yes, WRAM is the exact same problem. It's generally still the same kind of SRAM devices as the NES internal RAM. The battery doesn't make things very different, putting in a battery is the same as powering on the NES.

Then there's Metroid which refuses to boot unless CHR-RAM is initialized properly. FCEUX for a while did not initialize CHR-RAM to anything, leaving it as uninitialized computer memory. So Metroid would boot fine if you opened it from the file menu, but wouldn't boot if you ran it from the command line.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

Might want to add in a "All this byte [input]" setting, for simple tests.

More complicated ones, one would want a "Load from file…" (FCEUX has memory dump-to-file already, I hope?)

Odd, Metroid seems to work fine with random values in CHR-RAM on my end..

Enh, I don't really see the point of a custom byte; I doubt "fill with copies of the same arbitrary byte" is a plausible characterization of any real SRAM, and I also doubt it would be of significant use for debugging.

If you want something specific, you can just:
1. Hit pause.
2. Cold reset.
3. Debug > hex editor
4. Type or paste whatever you want in there.

There's no load file option, but you can paste hex data from the clipboard. (A load from file feature might be nice, though...)

If you want to initialize battery backed RAM, that's pretty simple with a lot of emulators. Just make the 8k save-RAM file and replace the one that gets automatically saved/loaded.

CHR-RAM is also affected by the RAM init option I just added. I see no problems runnin Metroid with randomized RAM. ?

As far as leaving any emulated RAM as uninitialized memory returned by malloc, well that's just a bad idea. (It does indeed look like FCEUX used to do that, but has progressively been sterilized with a bunch of memsets stuck in there over the years...)

I filed a ticket for nestopia to add a menu option, im hoping it can be implemented like rainwarrior's way! Great work!

I think this is the hotspot if im not mistaken though, correct:

In NstCpu.cpp

void Cpu::Ram::Reset(const CpuModel model)
{
std::memset( mem, 0x00, sizeof(mem) );
}

I'm currently messing with it now myself, but I'm sure this would be the area.

I'm also don't know why Martin assumed this Only i gave him info about dendy those days (~2008)
Maybe he wanted to solve dendy bugs (see #2) this way in 1.40, because most of them disappear after reset.
But, finally FHorse had found real source of these old problems, nothing related to start RAM values, it was Vblank and NMI flags problem.

I just stumbled on another game that relies on the RAM being initialized to random values: "Apple Town Story" for the FDS.

With a FDS image that is "clean" (i.e the disk was dumped before ever running the game on a FDS), the game will randomly assign a name to the game's character at the very start of the game and save the result on the disk.

If ram is initialized to 0, the name will always be "Cathy" (キャシー). When initializing ram with random values, a different name is assigned on each attempt (63 different names exist in the code)