PPU powerup/reset behavior
Moderator: Moderators
Well, also all those findings are true for NTSC U.S. NES, but they may differ greatly for a Japanese Famicom and European PAL NES.
Also, some results may very from unit to unit, for exemple it's well known that the initial palette values are proper to a NES, because they all flashes in different colors.
Also, some results may very from unit to unit, for exemple it's well known that the initial palette values are proper to a NES, because they all flashes in different colors.
Yeah, it's too bad I don't have a second US NES, perhaps even a top-loader. I do have a PAL NES and hope to test on it soon. I predict what tepples predicts, that the times will correspond to particular scanlines. Today I'm going to find whether the timing is the same if power is left off for a while between tests, down to a single PPU clock. I'm hoping that the variation was just due to not powering off long enough. If this is the case, it would allow for reliable movie recording and playback between the emulator and NES (either direction), which would be really cool.
Just tested a bunch of Famicom games on an emulator. Following fail to work on it if writes are ignored for a while after reset:
3E785DC3 Air Fortress
8BCDE59A Athena
2B462010 Balloon Fight
DC75732F Cosmic Epsilon
A5E6BAF9 Dragon Slayer 4 - Drasle Family
77DCBBA3 Eggland - Meikyuu no Fukkatsu
240C6DE8 Elysion
E0604F76 F-1 Race
73921674 Family Computer - Othello
79698B98 God Slayer - Haruka Tenkuu no Sonata
8DCD9486 Jumbo Ozaki no Hole in One Professional
D0EB749F Lord of King
D8748E0A Magic John
805F81BC Metal Gear
E2A79A57 Rollerball
8E62D229 Sansuu 1 Nen - Keisan Game
892CBBC2 Sansuu 2 Nen - Keisan Game
98DC1099 Sansuu 3 Nen - Keisan Game
8B4A2866 Sansuu 4 Nen - Keisan Game
Shouldn't come as a big surprise I guess since it most likely works differently on Famicom consoles. Just tought it I'd list them anyway in case someone finds this useful.
Edit: added CRCs
3E785DC3 Air Fortress
8BCDE59A Athena
2B462010 Balloon Fight
DC75732F Cosmic Epsilon
A5E6BAF9 Dragon Slayer 4 - Drasle Family
77DCBBA3 Eggland - Meikyuu no Fukkatsu
240C6DE8 Elysion
E0604F76 F-1 Race
73921674 Family Computer - Othello
79698B98 God Slayer - Haruka Tenkuu no Sonata
8DCD9486 Jumbo Ozaki no Hole in One Professional
D0EB749F Lord of King
D8748E0A Magic John
805F81BC Metal Gear
E2A79A57 Rollerball
8E62D229 Sansuu 1 Nen - Keisan Game
892CBBC2 Sansuu 2 Nen - Keisan Game
98DC1099 Sansuu 3 Nen - Keisan Game
8B4A2866 Sansuu 4 Nen - Keisan Game
Shouldn't come as a big surprise I guess since it most likely works differently on Famicom consoles. Just tought it I'd list them anyway in case someone finds this useful.
Edit: added CRCs
Last edited by Marty on Sat Mar 15, 2008 3:09 pm, edited 1 time in total.
In my emulator at least, Air Fortress (J) works at power but fails at reset, while Air Fortress (U) works after both. The init code has been changed for the US version, inserting 2 extra VBL wait loops. Since VBL could be set at reset, the first might not wait at all. The second would then wait for the first flag setting, where the registers still wouldn't work. The second two loops are needed, and a read of $2002 before them, which the first loop provides. Their loops also wait until the flag becomes unset, maybe just to be on the safe side, having been bitten by this.
Air Fortress (J)
Air Fortress (U)
Metal Gear (J) fails after reset, but (U) works. Same for Rollerball and God Slayer (Crystalis).
Air Fortress (J)
Code: Select all
INC $C000
[memory clear loop was here]
LDA #$00
STA $2001
LDA $2002 ; wait for VBL
BPL *-3
CLD
LDX #$FF
TXS
INX
STX $2001
...
Code: Select all
INC $C000
LDA #$00
STA $2000
STA $2001
[MMC1 bank selection]
[memory clear loop was here]
LDA $2002 ; wait for VBL
BPL *-3
LDA $2002
BMI *-3
LDA $2002 ; wait for VBL
BPL *-3
LDA $2002
BMI *-3
LDA $2002 ; wait for VBL
BPL *-3
LDA $2002
BMI *-3
CLD
LDX #$FF
TXS
INX
STX $2001
...
Well, that's somewhat fun. Also, all games that have a lda $2002 - bmi loop, the only way this branch can be taken more than once is in Nesticle. I wonder why they waster ROM to put this.
Also I've noted the Reset code of many commercial games is somewhat messy. A lot of games does write zero to $2000 and $2001 many times (I now understand that to be sure 2 times are needed, one at reset and one after a couple of frames in cases if the original writes were ignored). However, many games also do stuff like init the stack pointer, set the i flag, clear the d flag up to 3 times (usually each Reset code jumps to a secondary Reset code with redudency tasks, etc...).
Also I've noted the Reset code of many commercial games is somewhat messy. A lot of games does write zero to $2000 and $2001 many times (I now understand that to be sure 2 times are needed, one at reset and one after a couple of frames in cases if the original writes were ignored). However, many games also do stuff like init the stack pointer, set the i flag, clear the d flag up to 3 times (usually each Reset code jumps to a secondary Reset code with redudency tasks, etc...).
They fail only when reset is pressed. On power I'm taking the off-for-more-than-20-secs route, allowing writes go through immediately. The emulator passes your tests in ppu_power_reset3.zip.blargg wrote:Hmmm, do you mean these fail if writes are ignored after power, or only after game is powered up normally, then reset is "pressed" in the emulator? Are those all non-US releases?
AFAIK, all of them are (J) releases but I've edited my post to include their CRCs in case anyone wants to double check. The (U) and (E) versions (including Balloon Fight) work fine.
Some tests fail when I press reset for a second time. Is this "normal"?
Example: the VBlank flag. The wiki says "unchanged" on reset. By pressing reset one time, it passes; if I press a second time, it says "should be zero". The 2003h is the same.
Example: the VBlank flag. The wiki says "unchanged" on reset. By pressing reset one time, it passes; if I press a second time, it says "should be zero". The 2003h is the same.
Zepper
RockNES author
RockNES author
Once a test has reported pass/fail, it's done until you power down the (emulated) NES. If you press reset again, it could give erroneous results. The same goes if it tells you to press reset AFTER the message disappears and you instead press it while the message is still displayed (tests that do this must have PPU rendering off while reset is pressed).
Could you have the program detect a wrong soft reset?blargg wrote:Once a test has reported pass/fail, it's done until you power down the (emulated) NES. If you press reset again, it could give erroneous results.
"Press reset after the tone", then turn off rendering and play a tone on square 1.The same goes if it tells you to press reset AFTER the message disappears and you instead press it while the message is still displayed (tests that do this must have PPU rendering off while reset is pressed).