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:
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
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