Error in F-1 Race (1984)

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
Gilbert
Posts: 399
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: Error in F-1 Race (1984)

Post by Gilbert » Mon Aug 22, 2016 6:27 pm

Just a wild guess. Initial RAM values maybe?

User avatar
rainwarrior
Posts: 7843
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Error in F-1 Race (1984)

Post by rainwarrior » Mon Aug 22, 2016 6:42 pm

Yes, Nestopia and puNES both initialize RAM to a very specific set of values: wiki

These were determined from some particular person's particular NES once, and were kind of stupidly propagated as some "authentic startup values for RAM" (as if such a thing exists). Those two emulators implemented it. Don't ask me what compelled them to do so.

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* » Mon Aug 22, 2016 6:45 pm

rainwarrior wrote:Yes, Nestopia and puNES both initialize RAM to a very specific set of values: wiki

These were determined from some particular person's particular NES once, and were kind of stupidly propagated as some "authentic startup values for RAM" (as if such a thing exists). Those two emulators implemented it. Don't ask me what compelled them to do so.
Thanks for posting that up rainwarrior. :beer: So that could be the culprit. Should the startup values be changed for these 2 emulators then? Ive always thought those values were the end all, be all correct ones...

So its possible these values are causing the f-1 proto to skip the menu screen and go straight to the race?

User avatar
Zepper
Formerly Fx3
Posts: 3220
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Error in F-1 Race (1984)

Post by Zepper » Mon Aug 22, 2016 7:22 pm

rainwarrior wrote:Yes, Nestopia and puNES both initialize RAM to a very specific set of values: wiki

These were determined from some particular person's particular NES once, and were kind of stupidly propagated as some "authentic startup values for RAM" (as if such a thing exists). Those two emulators implemented it. Don't ask me what compelled them to do so.
RockNES also do that. All RAM is set to $FF, except those 4 locations.

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* » Mon Aug 22, 2016 7:45 pm

so zepper, your emu should also have the same issue as puNES and nestopia then if you are following those start up values with the f-1 proto right?

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

Re: Error in F-1 Race (1984)

Post by Sour » Mon Aug 22, 2016 9:13 pm

I did a quick test with Mesen:

Ignoring dummy reads done by the CPU, the game reads $51, $55, $70, $A4 and everything from $200 to $2FF (via sprite DMA) without ever initializing them by the time it gets to the menu. When initializing everything to $FF, the uninitialized read patterns change a bit. Setting both $70 and $6B to $FF will trigger the bug.

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Error in F-1 Race (1984)

Post by koitsu » Mon Aug 22, 2016 11:48 pm

Sour wrote:I did a quick test with Mesen:

Ignoring dummy reads done by the CPU, the game reads $51, $55, $70, $A4 and everything from $200 to $2FF (via sprite DMA) without ever initializing them by the time it gets to the menu. When initializing everything to $FF, the uninitialized read patterns change a bit. Setting both $70 and $6B to $FF will trigger the bug.
Thanks everyone -- this helps. Nestopia does the following (code reference):

* If the system type is Dendy, initialises $0000-07FF to $00
* Otherwise, initialises $0000-07FF to $FF, and $08=$F7, $09=$EF, $0A=$DF, and $0F=$BF

In the code, "mem" refers to a byte mem[RAM_SIZE]; allocation (see NstCpu.hpp); RAM_SIZE is declared as 0x800.

The fix for this should be incredibly easy. I'll submit an Issues via GitHub alongside a pull request.

Edit: Pull request submit (no need for an Issues): https://github.com/rdanbrook/nestopia/pull/196

User avatar
rainwarrior
Posts: 7843
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Error in F-1 Race (1984)

Post by rainwarrior » Tue Aug 23, 2016 12:06 am

koitsu wrote:* If the system type is Dendy, initialises $0000-07FF to $00
That's a really curious one. Why would it do the opposite for Dendy? Is there something special about Dendy's SRAM? Or is this yet another cargo-cult thing?

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Error in F-1 Race (1984)

Post by koitsu » Tue Aug 23, 2016 12:29 am

rainwarrior wrote:That's a really curious one. Why would it do the opposite for Dendy? Is there something special about Dendy's SRAM? Or is this yet another cargo-cult thing?
I wondered that too. Sadly, the git commit history doesn't have it, i.e. it's something that was decided upon prior to September 2012 (initial commit): https://github.com/rdanbrook/nestopia/b ... NstCpu.cpp -- gut feeling says your latter guess is most likely (Occam's razor and all 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* » Tue Aug 23, 2016 5:22 am

Thanks for putting that up koitsu! :beer:

So in terms of an actual nes, there are really no correct start up values right? It can differ and be random from one nes to another, correct?

User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Error in F-1 Race (1984)

Post by Myask » Tue Aug 23, 2016 5:43 am

As I heard it, the values reached on a sufficiently "cold" boot are fairly consistent; this is what makes consistent routing of Final Fantasy 1 encounters [which use uninitialized memory] for a speedrun viable (or, if less speedrun-oriented, what made the GP-rich Kyzoku "always" come up first as sea-encounter after poweron).

Though, from what Feasel said, how reliably this state comes up (and how long to let the RAM "settle" to it) is machine-dependent. (Though, this seems anecdotal…)

zxbdragon
Posts: 488
Joined: Mon Dec 12, 2011 8:15 pm

Re: Error in F-1 Race (1984)

Post by zxbdragon » Tue Aug 23, 2016 6:45 am

..........
dendy,pal-d ram is 0x00
ntsc,pal ram is 0xFF
:mrgreen:

tepples
Posts: 22055
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Error in F-1 Race (1984)

Post by tepples » Tue Aug 23, 2016 7:41 am

I've owned two front-loading NES (NTSC U/C) consoles. One had $00 (dark gray) in CGRAM, visible when no cartridge was inserted or when the CPU bus wasn't making a good connection. The second had $28 (yellow).

EDIT: Or perhaps by "pal ram" you meant PAL (as in 50 Hz) as opposed to palette.

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* » Tue Aug 23, 2016 8:29 am

tepples wrote:I've owned two front-loading NES (NTSC U/C) consoles. One had $00 (dark gray) in CGRAM, visible when no cartridge was inserted or when the CPU bus wasn't making a good connection. The second had $28 (yellow).
So, why does nestopia and puNES have ff? Does this affect games in any kind of way? SO basically, there is no accurate be all value, it varies from console to console. 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?

User avatar
rainwarrior
Posts: 7843
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Error in F-1 Race (1984)

Post by rainwarrior » Tue Aug 23, 2016 10:33 am

*Spitfire_NES* wrote:Thanks for putting that up koitsu! :beer:

So in terms of an actual nes, there are really no correct start up values right? It can differ and be random from one nes to another, correct?
Info at: http://wiki.nesdev.com/w/index.php/CPU_power_up_state
Commentary at: http://wiki.nesdev.com/w/index.php/Talk ... r_up_state
Test ROM and some commentary at: viewtopic.php?f=3&t=13334

In my testing, no there is no consistent startup state, whether the boot is "cold" or not. (Though I did not try literally freezing the NES before booting, which might actually affect it...)

I can't even vouch for a "mostly 1s" or "mostly 0s" startup state. My Famicom tends to start with about half 0s and half 1s, distributed mostly in columns of the same value, but with occasional "noise" values spread throughout. It's not the same columns every time, either, though there may be tendencies. My NES behaves similarly but it has slightly different tendencies (I think more 1s, but not all 1s). You can run my test ROM to see for yourself on your own hardware (but not on PowerPak/Everdrive).

Probably many people's machines do have a tendency to be mostly 1s or mostly 0s. I would expect some people to find this if they test it, but I'm also certain it varies a lot from system to system.
zxbdragon wrote:..........
dendy,pal-d ram is 0x00
ntsc,pal ram is 0xFF
:mrgreen:
Could you explain what this statement is based on?

Post Reply