Error in F-1 Race (1984)
Moderator: Moderators
Re: Error in F-1 Race (1984)
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.
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.
- *Spitfire_NES*
- Posts: 306
- Joined: Fri May 21, 2010 4:10 pm
Re: Error in F-1 Race (1984)
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.
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.
Re: Error in F-1 Race (1984)
Specifically, it checks if both [$70] and [$6B] are nonzero. Look at $C998 through $C9AC ...Sour wrote:Setting both $70 and $6B to $FF will trigger the bug.
Hence why "random values" looks like same as all $FF; the odds of either of two bytes being zero is roughly 1%.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Error in F-1 Race (1984)
I have added an option to FCEUX now: https://sourceforge.net/p/fceultra/code/3275/rainwarrior wrote:Maybe I should think about adding such an option to FCEUX.
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...
- *Spitfire_NES*
- Posts: 306
- Joined: Fri May 21, 2010 4:10 pm
Re: Error in F-1 Race (1984)
Nice work Nestopia and others who implement this should without a doubt follow this setup. Seems to make the most sense!rainwarrior wrote:I have added an option to FCEUX now: https://sourceforge.net/p/fceultra/code/3275/rainwarrior wrote:Maybe I should think about adding such an option to FCEUX.
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...
It will be fun to try the cheetahmen power cycling trick, HAHA. prob for about 5 minutes.
Re: Error in F-1 Race (1984)
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?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...
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?
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Error in F-1 Race (1984)
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.
Re: Error in F-1 Race (1984)
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!
Re: Error in F-1 Race (1984)
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?)
More complicated ones, one would want a "Load from file…" (FCEUX has memory dump-to-file already, I hope?)
Re: Error in F-1 Race (1984)
Odd, Metroid seems to work fine with random values in CHR-RAM on my end..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.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Error in F-1 Race (1984)
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.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?)
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.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Error in F-1 Race (1984)
CHR-RAM is also affected by the RAM init option I just added. I see no problems runnin Metroid with randomized RAM. ?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.
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...)
- *Spitfire_NES*
- Posts: 306
- Joined: Fri May 21, 2010 4:10 pm
Re: Error in F-1 Race (1984)
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 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.
Re: Error in F-1 Race (1984)
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
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.
Re: Error in F-1 Race (1984)
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)
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)