PPU Startup Time Test ROMs

PPU Startup Time Test ROMs
by on (#30815)
http://disch.arc-nova.org/starttime.zip


After the madness of this thread, it hit me that we still don't know when in the frame the PPU starts up to. We have a rough idea because of games like Time Lord and Ironsword.... but still no real conclusive tests.

So I slapped together this ROM to test such a thing! However I have no way to test it on an NES myself, so I am posting it here in the hopes that someone else can test it and report the results.


The readme:
Quote:
These are very ghetto test ROMs I made to try and narrow down where in the frame the PPU
starts up (and resets) to.


startrom.nes and startram.nes are the same, except startrom uses 8K CHR-ROM, and
startram.nes uses CHR-RAM. Each ROM uses 8K PRG at $E000 -- but in the .nes file
that 8K is mirrored at $C000 as well (because 16K is the minimum iNES headers allow)


Running the ROM will just print a hex string to the screen. This number is a
*VERY ROUGH* approximation of the number of CPU cycles that passed between Reset and
the first NMI. I figure I could be off by maybe 10 or so CPU cycles in either direction.
But this will give us a good idea of how many cycles have to pass before VBlank -- and
thus where in the frame the PPU is starting at.



The ROM does the following:
- basic prepwork and other setup crap
- wait around for about 70000 cycles (PPU warm up time -- I can't poll $2002 because
that would mess up the cycle count)
- enable NMIs
- start using X,Y as a 16-bit up counter until NMI is reached
- on NMI, performs math on X,Y to calculate cycles passed
- prints that number to the screen
- draws CHR-RAM (in RAM version)


I anticipate very different results on NTSC and PAL. Since I have no way to test this
on an NES myself... I'm hoping someone else can test the following on NTSC and PAL
and find out some stuff:

- Is the value consistent/predictable on powerup? Or does it vary?
- Is it predictable on soft reset?
- Do soft reset and powerup have at different times?
- And of course, what values do you get for each powerup/reset?





Regarding the source:
* I used x816
* My source is messy
* I don't comment
* I don't even use variable names
* Sorry

by on (#30818)
Disch: While we were on IRC you mentioned that this would be better tested on an NROM RAM cart after our discussion due to the fact that this would bypass PowerPak code.

Does this still stand?

by on (#30819)
Yes

To my knowledge PowerPAK has additional code that gets run before it hands control over to the ROM. This would defeat the entire point of these tests, since running any additional code would disrupt all the timing involved.

by on (#30820)
UPDATE:

Big, huge thanks to jsr, who ran these tests on his NTSC Famicom and PAL NES, and had the following results:

NTSC Famicom
Unpredictable output for both hard and soft resets. Approximate range of $11700-$18A91... putting startup time potentially anywhere in the frame.

PAL NES
Predictable and consistent output of $1682D for both hard and soft reset.

EDIT: My math before must've been wrong. In my emu I get the expected value of $1682D when I start anywhere between dot 21-27 (inclusive) of the first rendered scanline (scanline 0)

This is weird because iirc, blargg confirmed that $2002.7 is high immediately on powerup. Perhaps $2002.7 gives a false reading for the first frame.

EDIT AGAIN: of course with values in that range, that wAMMA demo linked in the previous thread fails. Perhaps it's unpredictable after all?

I can get both the wAMMA demo and the above linked ROM working by starting in that range with the VBlank flag initially clear ($2002=0). But doesn't that contradict earlier findings?


NTSC NES
??? still need someone to test. I'm betting it ends up being around the same time as the PAL NES. I doubt it's unpredictable like it is on the FC. If anyone can test and report results, it'd be very appreciated!

by on (#30836)
Remember that $2002.D7 is set on power-up and, if not cleared by the CPU reading the register, will remain set for the duration of the frame. This means that the PPU cannot begin execution within V-Blank, for if it did, the bit would be cleared at the start of the pre-render line. Therefore, the PPU must start some time after the pre-render period begins. The fact that the bit is high on power-up is a hardware quirk and has nothing to do with where the PPU begins executing.

The fact that the Famicom's PPU startup position is unpredictable is not surprising. If I'm not mistaken, in the NES the CPU and PPU are synced upon reset, but in the Famicom they aren't (don't remember how the wiring goes, however).

by on (#30899)
PAL startup time of $1682D
with vblank flag set: Pac-Man [!] (E) won't boot.
with vblank flag clear: Ironswor(d) ;) [!] (E) and Cobra Triangle (E) get stuck.

by on (#30901)
Ugh... you're right x_x

Well wtf. Now I'm confused.

by on (#30915)
- I suspect the first frame IRQ could be analysed as well as the 2002h:80, specially about "warming" the PPU.

by on (#31169)
I have a test ROM that reads $2002 at the following times, with the indicated result on the left column. Times are relative to reset, where the first instruction has a time of +0.

00 +32
00 +27383
80 +27387
00 +57164
80 +57168

The time between the two reads that find bit 7 set is 29781 clocks, so it's just the first frame that's shorter. I get the same timing for power-up and reset. Your test of course was doing NMI timing, so these results might not be directly comparable.

by on (#31170)
Has it ever been verified that frame IRQ's are enabled by default on the PAL NES? Has the state of the V-Blank flag been verified at power-up on the PAL NES?

It's possible that Nintendo was informed (by other developers) of the strange quirks in the CPU/PPU initial states (IRQ's on by default, V-Blank flag set outside of V-Blank). They might have decided to correct these issues when they made the PAL version of the console.