For the life of me, I can't quite figure out how the NES renders it image on an interlaced screen. The PPU sends out 240 line frames 60 times per second to an NTSC monitor. The NTSC standard draws 262.5 lines 60 times per second, odd lines first, even lines next, and so on. It is designed to show a 525 line image at 30 frames per second. Of those lines, 480 are visible while some of the excess are used for sychronization. The NES every frame uses 22 lines for this, and sends 240 lines 60 times per second. But the NES can draw all of its graphics on the odd lines. So what does it do to the even lines?

On a TV, the NES appears to cover the whole of the visible screen. In fact, on most average CRT screens the NES image even displays outside of the visible screen. The NES cannot simply only draw to the odd lines. While scanlines are relatively approximated on a TV monitor because the phosphor dots do not line up horizontally, all the scanlines are used. Yet the picture should be sandwitched in the middle of the screen. (Still talking NTSC here.) Since the ratio of a NES frame is 1.06:1, the screen stretches the horizontal pixels. It does not have the resolution to split up the images to combine them into one full frame like other devices that can display 480i. Is there some form of line doubling going on here like on a VGA monitor?

So what is going on here? How does the NES show a full screen on an NTSC device? I think its essentially widening the beams, using scanlines as wide as possible so that the odd and even fields of a NES frame take up the full screen. Am I right?

> The PPU sends out 240 line frames 60 times per second to an NTSC monitor.

This is partially correct. The PPU actually sends out a total of 262 scanlines per frame, but only 240 of them are visible (the others are part of VBLANK)

> The NTSC standard draws 262.5 lines 60 times per second, odd lines first, even lines next, and so on.

Nearly all NTSC television sets are capable of rendering a non-interlaced image consisting of only 262 scanlines per frame (312 per frame for PAL); if you look closely, you can see the gaps between the scanlines.

--
Quietust
P.S. If you don't get this note, let me know and I'll write you another.

Ok, I think I get it. For the low resolution devices, there seems to be two choices, either you get 240(262.5)p or 480(525)i NTSC / 285(312.5)p or 570(625)i for PAL. So, there are no odd lines or even lines to worry about. And I also assume that when the TV is sending the beams to draw the whole screen in one pass instead of two the beams are widened so that it doesn't look like the image is missing half the lines. (Lines in the interlaced mode are thinner than the lines in the lower resolution progressive mode?) But we still see scanlines due to the spacing between the beams. (On my 27" TV, they are really not noticeable from a foot away unless the screen is using a solid background color.)

But if the NES is sending out 60 frames per second and the TV is also drawing 60 frames per second (and not 30 interlaced frames per second), then why do NES emulators exhibit visual tearing? The tearing is because the framerate of the monitor and the NES are out of sync. But a computer monitor can sync down to 60Hz, which should be adequate, and yet I still get tearing unless I activate the emulator's sync function, which usually brings its own set of problems.

>But a computer monitor can sync down to 60Hz, which should be adequate, and yet I still get tearing unless I activate the emulator's sync function, which usually brings its own set of problems.

The reason this happens is because the author has not implemented double-frame buffering. This basically seperates the video memory being read to output pixels to the monitor, from the video memory being written to by the rendering device, and is swapped every frame. Triple-buffering has some performance advantages to double-buffering. Using multi- video-buffers is the only way source frames can be rendered out of sync with the rate that destination frames are read at, without creating visual tearing. Generally a person would want to do this, if they want fancy features like fast-forwarding (increasing NES frame rate) or slow motion (decreasing NES frame rate). You can also do these things with a double-buffer technique.

Since these buffering techniques require the programmer to be aware of the vertical retrace, they are hardly ever implemented in emulators which were developed without tools for scheduling frames to the video card (for windows programers, directx should provide all this control. For DOS, VBE 3.0 (1998 or 99) has frame scheduling functions).