Error in F-1 Race (1984)

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Error in F-1 Race (1984)

Post by Sour »

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.
User avatar
*Spitfire_NES*
Posts: 306
Joined: Fri May 21, 2010 4:10 pm

Re: Error in F-1 Race (1984)

Post by *Spitfire_NES* »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Error in F-1 Race (1984)

Post by lidnariq »

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%.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Error in F-1 Race (1984)

Post by rainwarrior »

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...
User avatar
*Spitfire_NES*
Posts: 306
Joined: Fri May 21, 2010 4:10 pm

Re: Error in F-1 Race (1984)

Post by *Spitfire_NES* »

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

Re: Error in F-1 Race (1984)

Post by Sour »

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?
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Error in F-1 Race (1984)

Post by rainwarrior »

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.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Error in F-1 Race (1984)

Post by Dwedit »

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!
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Error in F-1 Race (1984)

Post by Myask »

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

Re: Error in F-1 Race (1984)

Post by Sour »

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..
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Error in F-1 Race (1984)

Post by rainwarrior »

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.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Error in F-1 Race (1984)

Post by rainwarrior »

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...)
User avatar
*Spitfire_NES*
Posts: 306
Joined: Fri May 21, 2010 4:10 pm

Re: Error in F-1 Race (1984)

Post by *Spitfire_NES* »

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.
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: Error in F-1 Race (1984)

Post by Eugene.S »

Code: Select all

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

Re: Error in F-1 Race (1984)

Post by Sour »

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)
Post Reply