pedantic nerd:
The NES does indeed spit out video at a little over 60Hz. Frames are 341*262 PPU cycles, give or take one cycle every other frame. That's 89342 cycles/frame. The PPU runs at 21MHz/4, or 5.369MHz, so frames take 16.639ms a piece, or 60.098 fps.
/nerd
How exactly does that work with monitors that are locked at 60Hz?
Also, was the NTSC signal 60.098FPS also?
I always just encode as XVID, and everything just works. Except you are running the picture through a 1/2 chroma filter, so everying just looks bad.
To answer the Reapers:
The NES signal has 341 dots per line (340 occasionally) and 262 lines. It runs at 60.10 Hz. The true NTSC signal has 341.25 dots per line and 262.5 lines. It runs at 59.94 Hz. NTSC monitors aren't locked to 60 Hz; their analog electronics have quite a bit of slop.
My recommendation, if your AviSynth must output at 60.00 or 30.00 Hz: Use
AssumeFPS with sync_audio turned on. This will decrease the audio frequency by an imperceptible 3
cents so that audio and video remain in sync. And I second Dwedit's recommendation of Xvid.
I once tried capturing NES video using my DV camcorder, and since the framerate of the resulting file was standard NTSC the video and audio got out of sync. I had to manually increase the famerate or slow down the audio.
Do other videogame system have a framerate slightly higher than 60 fps?
NTSC encodes color on a QAM subcarrier whose frequency Fsc equals 39375000/11 Hz or roughly 3.5795 MHz. A standard NTSC scanline is exactly 227.50/Fsc or about 63.556 µs. These values were chosen such that Fsc/227.50 = 15734 Hz would evenly divide into the 4.5 MHz audio carrier. There are exactly 262.5 lines per field, making each field 59718.75/Fsc long, and there are 59.94006 of them in each frame.
But most of the old consoles output 262 lines per field, and their line periods tend to be a tad short or long.
The Atari 2600 has 228 dots per line, with dot rate equal to Fsc. The Apple II has 65 1/7 CPU cycles per line (the CPU is frozen for that last 1/7 cycle), and in 40-column text mode or standard hi-res, there are 7 dots in a CPU cycle, or 65*7+1=456 CPU cycles per line. Each dot is half a period, also resulting in lines of 228/Fsc. TMS9918-family VDPs, such as those of the ColecoVision, MSX, Sega Master System, and Sega Genesis, have 342 dots at a rate of 3/2 Fsc, also producing a scanline period of 228/Fsc. All these have a field rate of 39375000/11/228/262 = 59.9228 Hz, which is pretty close to spec.
The NES and Super NES, on the other hand, output 341 dots per line at the TMS9918 rate. One dot is omitted so that color encoder artifacts line up diagonally instead of vertically. This means the line is 227.333/Fsc long, resulting in a field rate of 39375000/11*3/2/341/262 = 60.0985 Hz.
I don't think that answered my original question of how do emulators output a 60.1Hz signal on a 60Hz (usually) display.
Reaper_Man wrote:
I don't think that answered my original question of how do emulators output a 60.1Hz signal on a 60Hz (usually) display.
They drop frames as the error accumulates.
tokumaru wrote:
Reaper_Man wrote:
I don't think that answered my original question of how do emulators output a 60.1Hz signal on a 60Hz (usually) display.
They drop frames as the error accumulates.
I wonder if any slow emulation down to match the framerate?
Yeah, I'm not sure. Slowing them down would be perfectly acceptable, nobody would be able to tell the difference.
But still, not everyone has their monitors set to 60Hz, I for example used 85Hz back when I used a CRT, and emulators always worked fine, so they must have means of dropping/repeating frames as necessary.
I wouldn't be surprised if they didn't care about the refresh rate at all, and used the the sound or other available timers to control the speed of the emulation, leaving all the frame dropping/repeating to the video card.
tokumaru wrote:
Yeah, I'm not sure. Slowing them down would be perfectly acceptable, nobody would be able to tell the difference.
But still, not everyone has their monitors set to 60Hz, I for example used 85Hz back when I used a CRT, and emulators always worked fine, so they must have means of dropping/repeating frames as necessary.
I wouldn't be surprised if they didn't care about the refresh rate at all, and used the the sound or other available timers to control the speed of the emulation, leaving all the frame dropping/repeating to the video card.
it would be really cool to set the monitor refresh rate to 60.098... mmmm...
(don't think it's possible with LCD screens...)
tepples wrote:
The NES and Super NES, on the other hand, output 341 dots per line at the TMS9918 rate. One dot is omitted so that color encoder artifacts line up diagonally instead of vertically. This means the line is 227.333/Fsc long, resulting in a field rate of 39375000/11*3/2/341/262 = 60.0985 Hz.
I read in some doc, a number of years back, that the last scanline of the SNES display is 1 pixel shorter than the rest.
On a side note, byuu had a doc that stated the interlaced mode of the SNES was alternating 262/263 scanlines per frame. Is there any truth to this? I ask, because the PCE can be set to display 262 or 263 scanlines. And if you manually change/toggle this during vblank, you get an interlaced display on SDTV sets (but my HD TV set doesn't like this or show it exactly like my SD sets do).
Kevtris and a few others (I forget who now) were discussing this last night on IRC. If someone brought this thread to their attention, they might be able to answer.
ps- The thread title has little to do with emulator / scanline /vblank timing. Might be a good idea to fork it.
tomaitheous wrote:
I read in some doc, a number of years back, that the last scanline of the SNES display is 1 pixel shorter than the rest.
Only in every other frame. The NES does that too if rendering is turned on around the time the scroll position is copied to the VRAM address. My bad; I forgot to account for that. Then the field rate becomes 39375000/11*3/2/(341*261+340.5) = 60.0988 Hz.
Quote:
On a side note, byuu had a doc that stated the interlaced mode of the SNES was alternating 262/263 scanlines per frame. Is there any truth to this? I ask, because the PCE can be set to display 262 or 263 scanlines. And if you manually change/toggle this during vblank, you get an interlaced display on SDTV sets (but my HD TV set doesn't like this or show it exactly like my SD sets do).
A proper interlaced display has the vertical sync pulse a half scanline later in the "long" field, so that the sync pulses are 262.5 lines apart.
clueless: Thanks for PMing me the split point.