Error in F-1 Race (1984)
Moderator: Moderators
Re: Error in F-1 Race (1984)
Just a wild guess. Initial RAM values maybe?
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Error in F-1 Race (1984)
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.
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.
- *Spitfire_NES*
- Posts: 306
- Joined: Fri May 21, 2010 4:10 pm
Re: Error in F-1 Race (1984)
Thanks for posting that up rainwarrior. 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...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.
So its possible these values are causing the f-1 proto to skip the menu screen and go straight to the race?
Re: Error in F-1 Race (1984)
RockNES also do that. All RAM is set to $FF, except those 4 locations.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.
- *Spitfire_NES*
- Posts: 306
- Joined: Fri May 21, 2010 4:10 pm
Re: Error in F-1 Race (1984)
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?
Re: Error in F-1 Race (1984)
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.
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.
Re: Error in F-1 Race (1984)
Thanks everyone -- this helps. Nestopia does the following (code reference):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.
* 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
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Error in F-1 Race (1984)
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?koitsu wrote:* If the system type is Dendy, initialises $0000-07FF to $00
Re: Error in F-1 Race (1984)
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).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?
- *Spitfire_NES*
- Posts: 306
- Joined: Fri May 21, 2010 4:10 pm
Re: Error in F-1 Race (1984)
Thanks for putting that up koitsu!
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?
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?
Re: Error in F-1 Race (1984)
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…)
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…)
Re: Error in F-1 Race (1984)
..........
dendy,pal-d ram is 0x00
ntsc,pal ram is 0xFF
dendy,pal-d ram is 0x00
ntsc,pal ram is 0xFF
Re: Error in F-1 Race (1984)
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.
EDIT: Or perhaps by "pal ram" you meant PAL (as in 50 Hz) as opposed to palette.
- *Spitfire_NES*
- Posts: 306
- Joined: Fri May 21, 2010 4:10 pm
Re: Error in F-1 Race (1984)
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?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).
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Error in F-1 Race (1984)
Info at: http://wiki.nesdev.com/w/index.php/CPU_power_up_state*Spitfire_NES* wrote:Thanks for putting that up koitsu!
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?
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.
Could you explain what this statement is based on?zxbdragon wrote:..........
dendy,pal-d ram is 0x00
ntsc,pal ram is 0xFF