My thing is if $FF was taken from someones console at one point and now this fix has been implemented, theoretically this proto would not work on the nes the $FF values were derived from, correct?

Specifically, the LH5116 16k SRAMs that are used on (at least my) NES -CPU-07 tend to power up with all FFs. And the comment in the lede matches...

Different SRAMs will power up with different values, or (as in the one that Rainwarrior measured) some SRAMs are made such that all values are fairly random.

There was an interesting article on hackaday about a year ago that pointed out that almost all RAMs have a few bits like this, where the two halves of the inverter that makes up each SRAM bit are perfectly balanced that they can be used as a source of a few random bits each time power is applied.

interestingly enough I wonder what other little oddities this may fix with nestopia loading games, (as I think ive already seen it fix something else) and puNES if it gets implemented or was this a weird quirky case for the f-1 proto?

Sorry for the double post, I went back and decided to look at some reading about the 0xFF and 0x00 and came across this post:

"The pirate dump came from a multi-cart, which apparently allowed the user to set the world number to start on before beginning the game. The ROM code was hacked to prevent the world number from being initialized. Since this dump of the game does not initialize the world number, it is at the mercy of what that spot of memory is set to on power-up. Accurate emulators set RAM to 0xFF, which in equivalent to world 0, while inaccurate emulators (including RockNES) set RAM to 0x00, equivalent to world 1. (There are a few games that expect RAM to 0xFF at startup, or so I remember hearing, so an emulators really doesn't have much flexibility in this area.)"

So with that said, what games rely on 0XFF at startup? 0x00 is not accurate? 0xFF is? Whats the best way to handle this, have random numbers generate each time the emulated console is powered on? Tis confusion!

Whats the best way to handle this, have random numbers generate each time the emulated console is powered on?

It's kind of up to you. If you want "authentic" hardware behaviour, yes probably some randomization is what you want, allowing users to hit power a billion times until a badly programmed game starts up in a state that works for them.

If you want consistent behaviour, either all 0s or all 1s is a good choice. You could even make it an option in the menu, if you like.

I think most users were prefer consistent behaviour from an emulator, but I don't speak for everybody. I don't think I've seen an emulator that has the option for 0s or 1s, but it would be pretty useful for this kinda thing... (e.g. "Want to play this Dendy pirate game that doesn't initialize RAM? Set it to 0.")

Yes, we've been sort of discussing this in the recent Nestopia fix I submit (which has been merged). I explain the complication and problem verbosely in this comment of mine. It goes over what I feel would be needed for games that need these one-offs.

There really isn't a universally "good" default value, and sadly there are games which (obviously) need quirky one-off fixes to "behave as originally intended". I've phrased this paragraph carefully. :P

In going for authenticity, it would be great to have some sort of generator that cycles between a few values on startup, doesn't have to be millions and millions, but a few 0xwhatever numbers we know.

We could call it a startup ram generator. Indeed some games used this to "randomize" enemies..see river city ransom i think. I am quite surprised this has not been attempted yet. I also think startup ram may influence what medusa drops in castlevania 1 for nes. (though i could be wrong)

I guess theres no way to have the said emulated game decide which one it needs, is there?

koitsu, which games were you referring to in particular? I know you had to word it correctly..

In going for authenticity, it would be great to have some sort of generator that cycles between a few values, doesn't have to be millions and millions, but a few 0xwhatever numbers we know.

We could call it a startup ram generator. Indeed some games used this to "randomize" enemies..see river city ransom i think. I am quite surprised this has not been attempted yet.

I strongly believe this already exists: look into emulators that implement "glitching". I have several friends who enjoy emulators that implement "glitch tools", and one who streams his stuff on occasion (there are lots of people who like doing this though). I think you might be surprised at the extent of which their tweaking goes; I believe they use either a) modified emulators that offer said features, or b) use tools that "mangle" ROM images in advance (obviously (b) is not applicable here). Pre-initialising memory to random values (and even "what type" of randomness!) is certainly in that list.

This is why I think, at least in the case of Nestopia, NstDatabase.xml would be suited for games which need "different" values set in RAM prior to running code out of the reset vector. But as my comment in the pull request says: I simply don't know how to implement this in Nestopia given the complexity and "mess" of the code.

Last edited by koitsu on Wed Aug 24, 2016 12:55 pm, edited 1 time in total.

Certainly Thefox has instrumented NintendulatorDX to pay attention to when the game reads a byte before it's initialized that byte. A "clever" emulator could keep track and allow the user to change initialization.

But I have this hunch, without any evidence, that any given game that accidentally relies on RAM power up values will specifically require either all 0s or all FF, and not anything more complicated.

We also don't know what ultimately prompted emulators to think that the Dendy starts up with RAM pre-filled to $00, but as my pull request comment states, I believe it to be an effect of the particular SRAM used in the particular Dendy console that someone tested. I wouldn't be surprised if there are other Dendy consoles which default to "mostly $FF". In other words: I don't see how the Dendy is any different than the NES/Famicom in this regard.

But I have this hunch, without any evidence, that any given game that accidentally relies on RAM power up values will specifically require either all 0s or all FF, and not anything more complicated.

I would agree with this hunch, and feel either $00 or $FF makes a good default.

That said: I don't want to diminish the usefulness of "fill RAM with random values". That type of behaviour has already proven itself useful in the SNES homebrew community with higan/bsnes, where on at least 1 occasion it helped a developer track down a bug in their code (it either worked right on a physical console but not in higan/bsnes, or vice-versa; the person's code didn't pre-initialise some variables or registers (I forget which)). rainwarrior considering implementing this in FCEUX (as a toggleable runtime feature) I think is worthwhile.

But I have this hunch, without any evidence, that any given game that accidentally relies on RAM power up values will specifically require either all 0s or all FF, and not anything more complicated.

Here's one exception I know of. The last two levels of Cheetahmen II are inaccessible normally (you get stuck at the end of level 4), but people have reported being able to get to them by repeatedly power cycling until the game starts up in Level 5.https://www.youtube.com/watch?v=bkQgl66xrD4

Neither all 0s or all 1s appears to accomplish this in emulators. (Though obviously there are easier solutions to this problem than power cycling your NES.)

There's a bunch of variations commented out with some remarks. It looks like it's been modified a lot of times over the years, also probably is merging comments from different forks.

Code:

// excerpt from fceux.cpp::PowerNES

//dont do this, it breaks some games: Cybernoid; Minna no Taabou no Nakayoshi Daisakusen; and maybe mechanized attack //memset(RAM,0xFF,0x800); //this fixes the above, but breaks Huang Di, which expects $100 to be non-zero or else it believes it has debug cheats enabled, giving you moon jump and other great but likely unwanted things //FCEU_MemoryRand(RAM,0x800); //this should work better, based on observational evidence. fixes all of the above: //for(int i=0;i<0x800;i++) if(i&1) RAM[i] = 0xAA; else RAM[i] = 0x55; //but we're leaving this for now until we collect some more data FCEU_MemoryRand(RAM, 0x800);

Anyhow, let this be evidence that at least some people aren't satisfied with all 0s or all 1s. Also evidence of why options are important instead of trying to find some magic RAM startup state that somehow works for everything.

If that 8-byte pattern sounds stupid and arbitrary to anybody, I might point out that it's actually similar to the dominant patterns I get in my Famicom, so I don't think it's quite as stupid as it looks.

(FCEUX is such a bizarre and wonderful codebase. I'm always amazed how well it actually works despite its code being this giant katamari ball of garbage.)

Last edited by rainwarrior on Wed Aug 24, 2016 1:48 pm, edited 2 times in total.

A common bootleg version of the ROM relies on RAM being initialized with $00, otherwise you start in world 0-1. (You can still press A+Start to start in 1-1).The real game doesn't care about uninitialized memory, although it does check for values in RAM to see if it has already booted or not. (see Tennis swap trick)

Who is online

Users browsing this forum: No registered users and 11 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