The times on this website assume that there are exactly 60 frames per second. However, the NTSC NES does not run at 60 FPS!
The NTSC NES runs at 60.0988 frames per second while the screen is turned on, and 60.09847 when the game turns the screen off.
NTSC TVs are flexible enough to handle the slightly off framerate.
Exact value of the framerate is (1789772.5 * 3 / (341*262-0.5)) FPS with screen on, and (1789772.5 * 3 / (341*262)) with screen off.
For instance, the 17912 frame SMB1 movie by klmz now clocks in at 04:58.04 instead of 04:58.53.
Then Adelikat's 464795 frame movie of Dragon Warrior 4 clocks in at
2:08:53.85, instead of 2:09:06.58.
Now, the emulators themselves may play the games at exactly 60FPS, and generate movies at 60FPS, but that is incorrect behavior.
NTSC NES runs at 60.0988 FPS, not 60FPS. All times are wrong
Sig figs, my friend, sig figs.
To add some content to this joke post, I would say that the times we use ARE accurate according to the platform they are made (emulators). The emulators are just inaccurate.
Movie times aren't wrong. The emulators are.
If a device or emulator is operating at more than 60.0fps but less than 60.1fps, at what point in the system's own output process are signifigant figures dropped to one, that allows us to accurately time a game based on frames / 60 = exact time?
This is purely theoretical and assuming you were trying to time a console or a device behaving like a console that was operating at the 60.0988 speed. The error would accumulate until it was significant enough to change the final time, no? And considering 60 has one significant figure, there isn't a time on this site expressed with less than 3 sig figs.
I'm probably missing something huge here, help me out.
The times on this website assume that there are exactly 60 frames per second. However, the NTSC NES does not run at 60 FPS!
You are correct on both accounts.
I can't really say why the FCM reading module uses 50.0 and 60.0 for PAL and NTSC respectively, instead of more correct number for NTSC and some other unknown number for PAL. Possibly because the right number wasn't known when the FCM reading module was written, and changing it later would have been cumbersome because all the movies should have been updated as well.
This same assumption plays on all other movie formats as well.
The NTSC NES runs at 60.0988 frames per second while the screen is turned on, and 60.09847 when the game turns the screen off.
Also, for the record, NTSC FCEU runs at 60.0998229384 FPS whereas NTSC NES runs at 60.0988138974 FPS. So it still wouldn't be correct :P
And Famtasia runs at 60.00000000 FPS.
units.dat wrote:
ntscnesframe 655171|39375000 s
palnesframe 66495|3325214 s
ntscfceuframe (16777216 | 1008307711) s
palfceuframe (16777216 | 838977920) s
famtasiaframe 1|60 s
snes9xframe 1|60 s
ntscsnesniframe 357366|21477272 s
ntscsnesiframe 358050|21477272 s
The times would be wrong anyway due to lag (even the slightest lag), so it really doesn't matter
um... what? It's not like lag is emulated incorrectly on the NES.
If I'm not completely mistaken, not all NES emulators emulate lag frames with 100% accuracy (IOW. the real NES might behave differently with regard to lag frames in the same situation).
If I'm not completely mistaken, not all NES emulators emulate lag frames with 100% accuracy (IOW. the real NES might behave differently with regard to lag frames in the same situation).
Not to mention that not every NES is going to operate with the exact same level of efficiency. There were so many changes to the hardware over the years that some degree of discrepancy is expected and all but guaranteed.
Since there are exactly 3 PPU cycles per CPU cycle (on an NTSC system), I don't think there could possibly be any variation in performance which would result in missing lag frames across different NES systems.
The only source of variation across different NES systems is possibly a different base clock not exactly equal to 1.7897725 MHz. But the ratio of CPU cycles to frames would never change.
There aren't too many for emulators to miss lag, mainly these conditions:
*failure to emulate the sprite 0 hit exactly
*failure to emulate DMC channel robbing clock cycles
*failure to emulate MMC3 scanline counter correctly
Lag happens when the number of instructions ran before the NMI occurs is less than the number of instructions the game wants to perform before the NMI occurs.
The number of clock cycles consumed by different instructions (including memory access delays etc), and the exact timing of NMI, can affect lag greatly.
I think that's one of the problems with trying to emulate such a system. Unless I'm completely off-track, I assume that the chip inside the NES which draws things on screen and launches NMIs for the CPU works independently, regardless of what the CPU does. In other words, the chip is most probably not synchronized in any way with the CPU clock. This means that an NMI launched by this chip may happen at any time, but the CPU can only handle it no sooner than at the next clock cycle.
What this means is that, given the right conditions, a lag frame may happen or not, depending on how the graphics chip happens to launch the NMI. This means that in the real NES the lag frame may happen or not even if the input was exactly the same. It all depends on when the graphics chip started drawing the screen, which may not be completely synchronized with the CPU clock (but most probably with the 50/60 Hz AC electric input of the system, while the CPU simply has its own clock chip which starts when the system boots).
Of course it's probably quite rare for this to happen, but it's quite possible.
An emulator, however, will always emulate the system in the exact same way (else the movie files would always desync), which means that it's not emulating the original NES system 100% identically. The emulated graphics chip and the emulated CPU are actually perfectly synchronized in the emulator (which causes a lag frame to appear every single time with the same input and the same conditions), which is something which probably doesn't happen in the original system.
The way I see it, what's in question is the fact that the site displays the wrong time. Technically speaking.
While the loss of a few seconds over time might be seen as bad, as far as I see it doesn't cause any serious confusion. All movies are off by a small factor, but it's a constant. It's not as if applying the new calculation might cause an old movie to suddenly become faster and a new movie to suddenly become slower, thus negating obsoletion for speed.
As for the discussion regarding lag, it means that all other things being equal (which they are not but let's go with it) FCEU would cause games to tend to lag more than an otherwise identical play in Famtasia which runs at exactly 60 fps.
All my most recent FCEU-based AVIs have the correct framerate of 60.0998.
I think that's one of the problems with trying to emulate such a system. Unless I'm completely off-track, I assume that the chip inside the NES which draws things on screen and launches NMIs for the CPU works independently, regardless of what the CPU does. In other words, the chip is most probably not synchronized in any way with the CPU clock. This means that an NMI launched by this chip may happen at any time, but the CPU can only handle it no sooner than at the next clock cycle.
What this means is that, given the right conditions, a lag frame may happen or not, depending on how the graphics chip happens to launch the NMI. This means that in the real NES the lag frame may happen or not even if the input was exactly the same. It all depends on when the graphics chip started drawing the screen, which may not be completely synchronized with the CPU clock (but most probably with the 50/60 Hz AC electric input of the system, while the CPU simply has its own clock chip which starts when the system boots).
In theory someone could create a hardware device and program interface that could read FCM (or other) files over a serial port and operate an accurate cycle to feed input into an NES controller port, thus effectively running a TAS on a console. In practice there are probably many more ways than all the ones mentioned so far in which such a setup could desync. Perhaps a bit irrelevant but I'm wondering if anyone else ever imagined that happening (ignoring for a moment all the complications that would arise).
I think that's one of the problems with trying to emulate such a system. Unless I'm completely off-track, I assume that the chip inside the NES which draws things on screen and launches NMIs for the CPU works independently, regardless of what the CPU does. In other words, the chip is most probably not synchronized in any way with the CPU clock. This means that an NMI launched by this chip may happen at any time, but the CPU can only handle it no sooner than at the next clock cycle.
The CPU and PPU run off the same 24MHz master clock, so they are perfectly synchronized. They just get different dividers.
Well, there are other things that could mess it up. Initial RAM and register contents shouldn't be a problem since most games initialize everything to known values at the beginning. But initial PPU counters could be random. I don't know if these are initialized in any way at reset. For example, the clock divider might not be reset and may be in any of its 3 states.
The CPU and PPU run off the same 24MHz master clock, so they are perfectly synchronized. They just get different dividers.
Maybe the PPU is, but the TV isn't, and the NMIs are launched at horizontal and vertical retraces, if I'm not completely mistaken. The NES has to send the TV video signal at 50/60 Hz (give or take some small fraction), regardless of the CPU clock, and the horizontal/vertical retrace interrupts must obviously be synchronized with the TV, not the CPU or PPU.
The NES sends its image to the TV at 60.0988 Hz, faster than the NTSC standard's 59.94Hz. The TV does not provide any kind of feedback back to the NES.
The NES sends its image to the TV at 60.0988 Hz, faster than the NTSC standard's 59.94Hz. The TV does not provide any kind of feedback back to the NES.
You know, I wonder if these numbers take into account parasitics like clock jitter/skew?
The NES has to send the TV video signal at 50/60 Hz (give or take some small fraction)
Dwedit wrote:
The NES sends its image to the TV at 60.0988 Hz, faster than the NTSC standard's 59.94Hz. The TV does not provide any kind of feedback back to the NES.
Technically, 60.0988 Hz is within that "some small fraction" of standard NTSC that pretty much all television sets are capable of rendering it properly.
* Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another
I think the biggest impact of this is that these times can't be achieved on NES hardware, and that should be the main reason to note this difference somewhere. Changing the movie rate to a hair more than 60 FPS might not be easy, and might cause other problems, so the simplest solution would be to post a conversion factor and perhaps show the "hardware" time in parenthesis. Too bad NES clock crystals don't vary a lot, then you could just claim to be emulating one with a slightly slow crystal. So there's no way around this difference, and it doesn't vary depending on any random variables either. BTW, some games use the "screen off" timing all the time, like Battletoads, because they disable the PPU during the beginning of the screen refresh.
No, it's because battletoads has the screen off for the first few scanlines (for more vblank drawing time). The extra cycle is only added to the first scanline (every other frame) if the screen is on at the first scanline.
