It is currently Wed Oct 18, 2017 10:42 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 96 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next
Author Message
PostPosted: Wed Aug 24, 2016 2:44 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
Just for the sake of completeness, I added the option to Mesen:

Image

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.


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 3:03 pm 
Offline

Joined: Fri May 21, 2010 4:10 pm
Posts: 260
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.


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 3:20 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6279
Location: Seattle
Sour wrote:
Setting both $70 and $6B to $FF will trigger the bug.
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%.


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 3:50 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
rainwarrior wrote:
Maybe I should think about adding such an option to FCEUX.

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...


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 3:57 pm 
Offline

Joined: Fri May 21, 2010 4:10 pm
Posts: 260
rainwarrior wrote:
rainwarrior wrote:
Maybe I should think about adding such an option to FCEUX.

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 :mrgreen: :beer: 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.


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 4:48 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
rainwarrior wrote:
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...

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?


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 4:50 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
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.


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 4:53 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
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!


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 5:00 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
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?)


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 5:22 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
Dwedit wrote:
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.

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


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 6:04 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
Myask wrote:
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?)

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.


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 6:23 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
Dwedit wrote:
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.

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...)


Top
 Profile  
 
PostPosted: Wed Aug 24, 2016 6:42 pm 
Offline

Joined: Fri May 21, 2010 4:10 pm
Posts: 260
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.


Top
 Profile  
 
PostPosted: Mon Aug 29, 2016 2:07 pm 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 257
Location: Russia
Code:
We also don't know what ultimately prompted emulators to think that the Dendy starts up with RAM pre-filled to $00

I'm also don't know why Martin assumed this :shock: 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.


Top
 Profile  
 
PostPosted: Thu Nov 17, 2016 9:35 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 96 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group