It is known that there are 340/341 PPU cycles each scanline, with 256 cycles producing rendered pixels, and 84/85 cycles "horizontal blanking".
If you look at video-captured screenshots, you'll see there's some picture visible to the left and to the right of the 256 rendered pixels (overscan), which doesn't appear as black, but as whatever bg palette color 0 is set to.
This area must be taken into account when doing aspect ratio correction --- the stretching factor would not be 320/256 (if one wants to correct for a 320x240 surface), but more like 320/272 or a something like that.
It's also relevant for proper composite dot-crawl emulation.
So, how many of the 84/85 hblank cycles are occupied by this overscan area?
The "color clock" is the period of the NTSC color subcarrier, or 3.5795̅4̅ MHz.
CCIR specifies that the NTSC picture area is 176 color clocks wide by 240 pixels tall. Now, one CPU clock = 2 NTSC color clocks = 3 pixels, so 176 color clocks is 264 NES pixels. The picture area of a field is still 240 lines tall, so the area that you have to stretch to 4:3 is 264x240.
Quote:
CCIR specifies that the NTSC picture area is 176 color clocks wide by 240 pixels tall
What specific document would that be? The CCIR 601 recommendation, now renamed to ITU-R BT.601-05 (recent version), makes no mention of 176 color clocks; it mentions 720 horizontal samples for the luminance and 360 for each chrominance channel for the active area. I have seen no mention of the 'left and rightmost 8 pixels being blank, thus reducing the horizontal resolution to 704' in this 16-page document. That 704 might be the "effective" horizontal resolution in the same sense that 224 might be the "effective" vertical resolution of the NES (because of what the TV cuts off) is probably true, but shouldn't matter for the aspect ratio.
If I start from 720 pixels rather than 704, using your calculation method, the proper stretching would be from 270 pixels, not from 264.
NewRisingSun wrote:
Quote:
CCIR specifies that the NTSC picture area is 176 color clocks wide by 240 pixels tall
What specific document would that be?
I had originally posted references at some web board that I'm now completely banned from (even reading gives a 403 Forbidden).
Quote:
The CCIR 601 recommendation, now renamed to ITU-R BT.601-05 (recent version), makes no mention of 176 color clocks; it mentions 720 horizontal samples for the luminance and 360 for each chrominance channel for the active area.
I looked at
this document and maybe neither of us is 100% right. The 720 pixel area sampled under CCIR 601 is wider than the actual picture area in order to provide enough headroom on the sides to capture the whole scanline even if the sync signal is wobbly. It turns out that an actual 4:3 picture is 710.85x486. (True NTSC has 486 scanlines, not 480, but digital systems usually work with only the center 480 of those lines.)
VCD runs at a resolution called CIF, which is 352x240 pixels wide in NTSC. DVD runs at CIF, interlaced CIF (352x480), cropped CCIR 601 (704x480), or full CCIR 601 (720x480). In the prior analysis, I had assumed that the CIF screen's aspect ratio was 4:3, leading to a 10/11 (0.90909) pixel aspect ratio and a width of 264.00 pixels for the NES picture. But the document seems to indicate that 4320/4739 (0.91158) is the correct pixel aspect ratio for DVD, VCD, Apple II, Sega Genesis, and other devices that run at a half-601 pixel clock rate. This means a 4:3 picture whose height is 480 pixels has a width of 480*(4/3)*(4739/4320) = 702.07 pixels.
On NTSC, 1 CPU clock = 2 color clocks = 3 NES pixels = 8 CCIR 601 pixels. This means a 4:3 picture whose height is 480 pixels has a width of 480*(4/3)*(3/8)*(4739/4320) = 263.28 NES pixels. But given that it's this close, the 264 that I got before should still be good enough, especially that we're now probably well within the tolerances of consumer TV set calibration.
And we still haven't touched on overscan. The TVs popular in the NES era did not have square edges like those of modern flat screen TVs. For instance in
Super Mario Bros., the "WORLD" in the center might show up cleanly with about 4 pixels of margin, but the very top of "MARIO" might get partly cut off. Let's just assume that overscan simulation will be provided by a textured quad to be drawn over the emulated TV signal, which is another textured quad resized from a 264x240 texture to 640x480.
Quote:
The 720 pixel area sampled under CCIR 601 is wider than the actual picture area in order to provide enough headroom on the sides to capture the whole scanline even if the sync signal is wobbly.
No. The 720 pixel area is the "active area". The "headroom" you mention is the "back porch" and the "front porch". Back porch, front porch and sync pulse are the blanking area. Rec. ITU-R BT.601-5 captures 858 pixels horizontally, with 720 pixels for the active (visible) area and 138 for the blanking area, including the sync pulse and that "headroom".
You don't need to take additional headroom from the active area so that the whole scanline is captured even if the sync signal is wobbly, because in Rec. ITU-R BT.601-5 the sync signal itself is captured, which is why you have 858 pixels total and not 720.
I have read that document you linked to, I have never ever heard of anything like that. Maybe one day I'll read through all of his documents and look into it a little bit closer.
As for now and the NES, it doesn't stand the
empirical test either:
If the NES has 264 pixels (assuming 704 NTSC luma pixels and 176 color cycles), you need to add 8 pixels, presumably 4 to the left and 4 to the right. Stretching these 264 pixels to 640 gives you this:
However, if the NES has 270 pixels as I claimed (assuming 72 NTSC luma pixels and 180 color cycles), you need to add 14 pixels, presumably 8 to the left and 6 to the right. Stretching these 270 pixels to 640 gives you this:
I
am operating my TV in underscan mode, and while that may not be as accurate as I need (it's still a consumer set after all), the colored border is at least as wide as in the 270 picture, not as slim as in the 264 picture. Also, if you look at the video-captured SMB1 shot on MobyGames, you'll find that it's much closer to the 270 shot than to the 264 shot:
http://www.mobygames.com/game/nes/super ... tId,31489/
A lot of consumer and even prosumer video capture devices are not close to CCIR 601 compliant.
Want me to put Balloon Fight in my NES, connect it to my TV, and use a tape measure?
Quote:
A lot of consumer and even prosumer video capture devices are not close to CCIR 601 compliant.
Closer than that page you linked to certainly. And again, those screenshots are only an illustration of the relevant point, that the active horizontal area is 720 pixels wide --- just as the ITU 601 states, not 704, 710 or anything else.
NewRisingSun wrote:
And again, those screenshots are only an illustration of the relevant point, that the active horizontal area is 720 pixels wide --- just as the ITU 601 states, not 704, 710 or anything else.
True, there may be 720 pixels, but are you sure that the 720x480-pixel area is exactly 4:3? If it were, the pixel aspect ratio under 601 would be 480/720*4/3 = 8/9 = 0.88889, and the NES pixel aspect ratio would be 480/720*4/3*4/3 = 32/27 = 1.18519.
EDIT: I connected my NES to the family's main TV, turned on an NES game, and measured a 144x144 pixel area. It ended up as 11+15/16 inches by 10+5/8 inches on one TV. This implies a pixel aspect ratio of 191/165 or 1.15758, which is even narrower than the ratio suggested by your calculation.
On the same TV, a Game Boy Player (which runs in a GameCube video mode intended by Nintendo as a square-pixel mode) produces a 240x160 pixel image measuring 17+1/2 inches by 11+3/4 inches. This implies a pixel aspect ratio of 160/240*280/188 = 0.99291. As all inch measurements in this post are plus or minus 1/16 inch, this is close enough to 1.
Finally, I tried a test pattern in Mario Paint. (The NTSC Super NES in non-"hi-res" video modes has the same pixel clock rate as the NTSC NES.) I made a filled rectangle 96 pixels tall and 80 pixels wide. Then I made a 1x16 pixel stamp, used it to extended the box in 16-pixel-tall bands to 81, 82, 83, 84, and 85 pixels wide, and saved it to the game's SRAM. Then I plugged it into different TVs, loaded, and measured. On a TV that follows 720x480 = 4:3, the 81-pixel-wide row would be as wide as the box is tall.
On one TV I got somewhere around 85x96 pixels for a square; on another, 80x96 pixels. This indicates that there's a pretty big margin of difference among the aspect ratios of actual television sets.
Conclusion: It might be best to render to a texture whose size is 256x240 pixels (or multiples thereof) and then let the user adjust the horizontal scale factor between, say, 1.15 and 1.25, using a "horizontal size" knob.
That probably is a very good solution for the aspect ratio problem. Unfortunately, I need to get this right for another reason: unless I get the horizontal resolution properly nailed down, I won't get the composite dot crawl pattern right.
I just fiddled around with the horizontal centering of my Sony TV, shifting the picture so I can actually see the sync pulse, back porch and color burst.
First of all: it's very interesting to see the color burst "crawl" upwards whenever the BG is turned off, then suddenly stop crawling once the game turns the BG back on. Just as Bregalad described!
But more importantly: This area left and right of the rendered 256 pixels, where color 00 is displayed (let's call it "overscan area" for lack of a better word) is even wider than I thought: after the back porch ends (which seems to be at the same spot where it ends for a normal NTSC TV picture by the way), there's a gray line, about one to two NES pixels thick, then about 16 pixels of color 00 (I'm going by eyesight here), then the 256 playfield pixels, then about 8-10 pixels of color 00 again, then the front porch begins. That would make 16+256+8=280 horizontal pixels in the 720-pixel active area... that doesn't seem right.
Quote:
Conclusion: It might be best to render to a texture whose size is 256x240 pixels (or multiples thereof) and then let the user adjust the horizontal scale factor between, say, 1.15 and 1.25, using a "horizontal size" knob.
This is the one reason why I still have FCE Ultra installed on my computer, it allows you to scale integrally in custom resolutions. My LCD has a native resolution of 1280x1024 and by using the 1280x960 with a 5:4 pixel ratio, I get a picture thats sharp as a knife and reasonably close to the NES's pixel aspect ratio on a TV.
NewRisingSun wrote:
Unfortunately, I need to get this right for another reason: unless I get the horizontal resolution properly nailed down, I won't get the composite dot crawl pattern right.
Dot crawl has absolutely nothing to do with the aspect ratio. Instead, the dot crawl is synchronized to color burst.
The color subcarrier of NTSC is 3.579545 MHz. The NES system clock is six times color, or 21.47727Mhz. But because the NES PPU's color generator actually uses a double-pumped counter to generate 12 phases (hues) out of 6 cycles, you have to sample at twice this, or 42.95455 MHz. As the NTSC pixel clock is 1/8 of this (5.36932 MHz), each pixel will be spread across 8 phases. After a low-pass filter at about 4.5 MHz, this is the signal that the NES outputs on the composite video RCA connector at the side of the toaster. At this point you're allowed to downsample the composite signal by a factor of 6 to CIF (7.1591 MHz).
Now you have to do a TV emulation. Converting composite to RGB takes three steps:
- Convert to S-video by using a a low-pass filter (0 to 2.7 MHz) to get the luma signal and a band-pass filter (2.7 MHz to 4.5 MHz) to get chroma.
- Convert to component video by QAM-decoding the U and V channels. Use the color burst and the tint control to find the starting phase of U.
- Optional: Run a comb filter to clean up the chroma signal. It's a weighted sum of the chroma signal in the previous, current, and next scanlines.
- Convert to RGB by running through a decoder matrix. As TVs in USA and Japan are tweaked to make each region's typical flesh tones look better, it'd be a good idea to provide standards-compliant, USA, and Japan settings for the decoder matrix.
Only after you have the signal in RGB do you need to worry about pixel aspect ratio.
Quote:
But more importantly: This area left and right of the rendered 256 pixels, where color 00 is displayed (let's call it "overscan area" for lack of a better word) is even wider than I thought: after the back porch ends (which seems to be at the same spot where it ends for a normal NTSC TV picture by the way), there's a gray line, about one to two NES pixels thick, then about 16 pixels of color 00 (I'm going by eyesight here), then the 256 playfield pixels, then about 8-10 pixels of color 00 again, then the front porch begins. That would make 16+256+8=280 horizontal pixels in the 720-pixel active area... that doesn't seem right.
Because the NTSC NES dot clock is exactly 3/8 of the 601 pixel clock, the 720-pixel area of 601 will have 270 NES pixels by definition. What you're seeing is that the NES might not actually blank the signal for the entire horizontal-blanking time.
Quote:
Dot crawl has absolutely nothing to do with the aspect ratio. Instead, the dot crawl is synchronized to color burst.
... relative to the NES' pixel clock, yes. I already have it finished except for the exact color burst shift between odd/even fields.
Quote:
What you're seeing is that the NES might not actually blank the signal for the entire horizontal-blanking time.
Yes, I think the colored overscan area extends into the back porch area.
NewRisingSun wrote:
Quote:
Dot crawl has absolutely nothing to do with the aspect ratio. Instead, the dot crawl is synchronized to color burst.
... relative to the NES' pixel clock, yes. I already have it finished except for the exact color burst shift between odd/even fields.
That would be 1/3 color clock worth of shift.
Quote:
That would be 1/3 color clock worth of shift.
That's what I thought too, but it doesn't look right. Maybe I'm doing something else wrong. If you want to take a look:
even field
odd field
Obviously you need to look at them in 60 Hz succession... aside from the colors (I'm just guessing the four luma offsets and the chroma amplitude for now) and the aspect ratio (I'm sticking with 720 for this purpose), the dithered pattern at the bottom of the vitamin pill does have the same "diagonal" look as on my TV; all in all however, there seems to be less artifacting on my TV.
NewRisingSun wrote:
but it doesn't look right. Maybe I'm doing something else wrong. If you want to take a look:
even field
odd field
Combined:
Quote:
Obviously you need to look at them in 60 Hz succession... aside from the colors (I'm just guessing the four luma offsets and the chroma amplitude for now)
The color signal for $x1 through $xC is thought to alternate in a square wave between the value for $x0 and $xD.
Quote:
and the aspect ratio (I'm sticking with 720 for this purpose), the dithered pattern at the bottom of the vitamin pill does have the same "diagonal" look as on my TV; all in all however, there seems to be less artifacting on my TV.
That's due to your TV's "2D comb filter". More expensive TVs will use a weighted average of the previous, current, and next scanlines' chroma signals.
Quote:
The color signal for $x1 through $xC is thought to alternate in a square wave between the value for $x0 and $xD.
Yes, I have read the docs. Unknown are the actual values for $x0 and $xD, or more importantly, the difference between the two, which would be said chroma amplitude --- captured palettes are no good indicator, as for every set of x0/xD values, at least one is clipped ---, and of course the "linear DC voltage offset" for each level $0x-$3x, which is luminance.
Quote:
That's due to your TV's "2D comb filter". More expensive TVs will use a weighted average of the previous, current, and next scanlines' chroma signals.
That TV doesn't have a comb filter. From what I know from reading comb filter patents, comb filters depend on the color burst being shifted by 180 degrees, or half a color clock, from scanline to scanline/field to field. The NES PPU can't shift by half a color clock, only thirds, therefore, comb filters can't work with the NES.
NewRisingSun wrote:
Unknown are the actual values for $x0 and $xD, or more importantly, the difference between the two, which would be said chroma amplitude --- captured palettes are no good indicator, as for every set of x0/xD values, at least one is clipped ---, and of course the "linear DC voltage offset" for each level $0x-$3x, which is luminance.
In other words, someone needs to
scope this out and settle it once and for all. But at least $0D is known to be sync level.
Quote:
Quote:
That's due to your TV's "2D comb filter".
That TV doesn't have a comb filter.
TVs without a comb filter may have even smaller effective luma and chroma bandwidths than a high-quality set. Remember that the separation of a composite signal into S-video is done by a crossover. Setting up the crossover correctly involves a tradeoff between color fringing (luma bleeding into chroma) and dot crawl artifacts (chroma bleeding into luma). To improve the image without an expensive comb filter, TV engineers may place a "guard band" of filter rolloff between the luma (below 2.7 MHz) and chroma (2.7-4.5 MHz) bands. This will have the effect of blurring the Y, U, and V signals horizontally, which may reduce the dot crawl artifact.
Quote:
From what I know from reading comb filter patents, comb filters depend on the color burst being shifted by 180 degrees, or half a color clock, from scanline to scanline/field to field.
So the comb filters that you read about work in the composite or S-video domain. It's also possible to make comb filters that work in the component domain, working directly on U and V after they've been demodulated from the S-video signal.
Here are the NTSC PPU's two artifact patterns compared:
Three-stage pattern, if the background was off during line 20:
field 0:
field 1:
field 2:
When viewed 0-1-2-0-1-2-... at a rate of 60 Hz, the dots will appear to be crawling upwards.
Two-stage pattern, if the background was on during line 20:
field 0:
field 1:
When viewed 0-1-0-1-... at a rate of 60 Hz, the dots will appear to tremble. Obviously, this is basically the three-stage pattern with field 1 skipped.
On the PAL NES, all fields are exactly the same, with the background on or off.
Animated at 20fps:
3 fields, dot crawl goes up
2 fields, dot crawl jitters
I can't get over how cool NewRisingSun's screenshots look. How computationally expensive is this full NTSC simulation? Is it something that's feasible to do in real time in an emulator?
I've just arrived at the answer: yes. I've optimized NewRisingSun's code about 25x and gotten my NES emulator to run full-speed on my 400MHz PowerMac using a reduced screen size (source size: 219x225 PPU pixels).
I had to sacrifice the quality a bit, but it should run full-speed, size, and quality on a modern GHz PC. Only about 4% of CPU time is spent doing actual emulation; the rest is spent on this NES->NTSC->RGB algorithm. I'll release the code once I'm done with this last round of optimization. I've also got one more idea for an approximation that might be many times faster.
The algorithm is
very intensive. It converts source NES pixels to the raw NTSC signal, then converts that to RGB. The most difficult speed drain to eliminate is the filtering to extract the luminance and chrominance information. I was able to find an
IIR-based gaussian filter (
C implementation) that achieves symmetricality by being run in both directions, which gave the last major speedup.
how about one for PAL now ?
Awesome achievement NewRisingSun, blargg !
Will this mean that you can emulate the NES PPU NTSC peculiarities on a PC? I'd like to be able to see the dotcrawl on my computer before putting my code into an EPROM. I'd like to figure out what's behind the dotcrawl on my sprite movements.
hap wrote:
how about one for PAL now ?
My pal TV doesn't have that scrolling dots at all. However, horizontally, a pixel seems to have a lot of sustain color from the precedent pixels. If you look very cloose to the screen, you'll notice that on some line the susained colours aren't the same, sometimes it's rather blue and sometimes rather red.
I think a "real" emulated PAL screenshot wouldn't tremble, flicker or what knows, but such gliches apears only on a scrooling screen. However, I didn't mean to say stupid things, because I didn't understand that stuff very well. It that dot crawl due to the NES or due to the TV ? If it's due to the NES, there is none on PAL, because the problem I say above does appear as well with other signels than the output of a NES.
After more research, what was previously written must be revised.
I was incorrectly using the ITU 601 resolution of 720 active horizontal pixels as a starting point. That resolution is the result of sampling the analog signal at 13.5 MHz, resulting in 858 total horizontal pixels, or 720 pixels in the active area.
However, in order to facilitate filtering in the spatial domain, the algorithm represents one color clock using four pixels; that means, the signal must not be sampled at 13.5 MHz, but at four times the color clock, 14.31818 MHz. This results in a horizontal resolution of 910 total horizontal pixels, or 768 pixels in the active area, according to documents describing this sampling ratio as the "4 Fsc" ratio, as opposed to the "601" ratio.
Since the PPU clock is 6/4 the color clock and 6/(4*4)=3/8 our pixel clock, multiplying the 910 total horizontal pixels by said factor 3/8 results in ~341, which as we know is the number of PPU clocks per line. Multiplying the 768 active horizontal pixels by said factor 3/8 results in 288, which therefore is number of NES pixels in the horizontal area, a common resultion in arcade games. This means that the NES produces 288-256 = 32 overscan pixels among the 85 h-blank pixels, painted as background palette color 00.
To get the correct aspect ratio, the correct stretch factor from 288x240 to 320x240 is 320/288 ~ 1.11, which is close enough to 11/10, the aspect ratio of NTSC pixels.
However, if one goes by that Jukka Aho page (the one that takes headroom from the active area), going by his calculations, the active area would be 14.3181818 MHz x (52+59/90) = ~754 active NTSC pixels, or ~282.75 NES pixels, resulting in a stretch factor of 320/282.75 = 1.13.
Either way, we're way lower than the original 1.212 or whatever it was.
OK, I'll ask the federal government:
47 CFR 73.699 (PDF). Figure 6.3 of page 5 states that horizontal blanking time lasts for z = 0.18 times total horizontal scanning time. This implies that the TV sees a ratio of 82% picture and 18% hblank, or (in NES or Super NES pixel clocks) 279.6 pixels draw and 61.4 pixels hblank. So now the picture is 256x240 window within a total canvas of 280x240. This makes each NES or Super NES pixel 8:7 if the total canvas is 4:3. Under this ratio, a 4:3 area that's 256 pixels wide will be 220 pixels tall, which probably corroborated the "256x224" rumor.
The ultimate solution is to make an NES program that can be used with a ruler. It would display a box with a constant height (200px) and a variable width (144px to 200px). Then everybody with a devcart could measure their TVs once and for all to establish what ratios are found in the wild. Or even without a devcart, use Mario Paint, whose platform has the same display timing.
tepples wrote:
The ultimate solution is to make an NES program that can be used with a ruler. It would display a box with a constant height (200px) and a variable width (144px to 200px). Then everybody with a devcart could measure their TVs once and for all to establish what ratios are found in the wild.
This should work:
http://www.qmtpro.com/~nes/demos/square.zip
Quote:
Figure 6.3 of page 5 states that horizontal blanking time lasts for z = 0.18 times total horizontal scanning time. This implies that the TV sees a ratio of 82% picture and 18% hblank, or (in NES or Super NES pixel clocks) 279.6 pixels draw and 61.4 pixels hblank.
Figure 6.3 says "0.18H
MAX.", which doesn't mean z = 0.18, it means z <= 0.18.
According to that Jukka Aho page, the total scanning time is 63+5/9 µs with the active part being 52+59/90 µs, which is 4739/5720 ~ 82.8% which again results in ~282.5 pixels. Other sources claim 16% hblank, which yields ~286 pixels. I don't have the ITU BT.470 document at hand at the moment, but that one reportedly has some exact numbers as well.
It seems that there is some variation with regards to the amount of "active picture" among the horizontal scanning time depending on who you ask. As explained above, the 1953 FCC NTSC spec only specifies the maximum, not the exact duration.
Also, one should be careful not to rely on the 1953 FCC NTSC specifications on everything, as several of its elements (for instance, phosphor chromaticities) are already deprecated (replaced with SMPTE-C in the case of phosphor chromaticities), with others (decoding matrix) being quietly violated in common implementations.
More importantly, since the NES PPU doesn't conform 100% to the NTSC spec with regards to its vertical refresh rate (60.1 vs. 59.94) and line rate (Fsc*6/4 / 341 = 15745.8 vs. 60/1.001*262.5 = 15734.3), it's entirely conceivable that the active area isn't 100% up to spec, either. I could imagine that "NTSC-J" also cooks its own pot there.
For now, I'll go with 288 because it has some nice mathematical properties not only with regards to the NES/arcade resolutions/the 11:10 ratio, as explained in my previous post, but also with the CGA and Apple II.
I expect consumer TV sets to be all over the place, especially considering that old-style CRTs are not perfectly planar, which also affects the perceived aspect ratio. Do you bend your ruler according to the round CRT tube, or are measuring flat distances?
NewRisingSun wrote:
I expect consumer TV sets to be all over the place, especially considering that old-style CRTs are not perfectly planar, which also affects the perceived aspect ratio. Do you bend your ruler according to the round CRT tube, or are measuring flat distances?
First TV measured was a flat CRT. Second, I bent the ruler.
Will this new NTSC emulation have any benefit for PC's hooked up to CRT based NTSC televisions, or is it only useful for emulating on a PC's CRT? This looks like NES emulation as taken another leap in accuracy. Is anything like this necessary for audio?
After this, what is the most lacking aspect of best of breed NES emulation? Yes there will always be obscure pirate mappers that still need to be emulated, but what about stuff like controller input port latency? How cycle accurate is that? It seems like PC USB input devices would introduce latency that doesn't exist in a real NES, but what can an emulator do about it?
Quote:
After this, what is the most lacking aspect of best of breed NES emulation?
Output voltage levels, required for accurate colors (and to a lesser extent, dot crawl).
Jagasian wrote:
Will this new NTSC emulation have any benefit for PC's hooked up to CRT based NTSC televisions, or is it only useful for emulating on a PC's CRT? This looks like NES emulation as taken another leap in accuracy. Is anything like this necessary for audio?
This seems like it's heading offtopic and should move to another thread instead of continuing here further. I'll reply for now though.
The audio possibility is something I thought of too while reading this thread but I was going to wait until the video stuff is released before mentioning it. Yes, this kind of thing could be done for audio too, and it'd probably be cool to eventually see the video and audio together for super-authentic emulation. People have already done that kind of audio processing before, though perhaps not in emulation, and I don't remember exactly where (I remember seeing the proper processing as part of a set which also included an option to encode to telephone encoding and back again). Finding someone's implementation which takes a wav file may be as easy as doing a search for both the particular spec which the NES uses to send audio to the TV (those kind of jibberish standards body numbers) and source.
As for connecting to a TV.. Though I'm not an expert, I suspect that if you hook up high-quality outputs to a high-quality TV you could get a result which is worth using. There's no benefit over the PC though (Edit: A non-composite interlacing mode would be best to use on TV's. I think TV's would have an advantage there). It's worth pointing out that you'd want to avoid using a composite connection, because otherwise you'd be applying an extra layer of artifacting that would further mess with the emulation's output. Unfortunately I'm not aware of any way to bypass a PC's (or any console's) video output hardware and output your own raw values (perhaps this is what you were thinking?). If you're very hardcore, you could in theory create a hardware/software solution which could output your own software-processed NTSC signal from the PC
.. but I think it'd be difficult and not usable by many people.
I'll add that the video processing screenshots look insanely cool
Using S-Video or better interconnects between the PC and the video monitor/TV, then the image should be 99% accurate to a real NES - the only visual difference will be that the PC outputs an interlaced signal while the real NES is noninterlaced. I don't know of any way to force a TV-out to skip the extra half-scanline that triggers sets to interlace, so that sounds like the best one could get.
I used the composite NTSC video output from my Mac and a standard NES emulator looked pretty good on a TV. I was expecting horizontal scrolling to result in the "comb" effect due to interlace, but didn't see any, though it might be due to the flicker-reduction filter that the video output has. I don't have a TV with S-Video inputs so I can't try that with my modified NES emulator that does NTSC emulation. I'm hoping to post a Win32 build of it and source code sometime soon.
Interlace combing is rarely visible on a true interlaced display, since each field has already started to fade by the time the other field is drawn. I haven't done it in a while, but I used to play NES games using TV-out all the time, and I never saw any combing artifacts. You see those mostly when capturing interlaced signals.
Quote:
I haven't done it in a while, but I used to play NES games using TV-out all the time, and I never saw any combing artifacts.
But that's the point, the TV outputs on PCs usually include a "flicker reducer" filter since computer graphics with their crisp images would otherwise flicker badly on an interlaced display.
AdvanceMAME is able to mess with your video card registers to output a 15.75Khz signal. I run the DOS version on a MAME cabinet I have, and hacked a TV for RGB input.
Original I used an AD723 to get S-Video/Composite NTSC for use on a regular TV.
It works quite well, and you can get non-interlaced output out of a PC. I think windows/dos/linux ports exist.
blargg wrote:
Quote:
I haven't done it in a while, but I used to play NES games using TV-out all the time, and I never saw any combing artifacts.
But that's the point, the TV outputs on PCs usually include a "flicker reducer" filter since computer graphics with their crisp images would otherwise flicker badly on an interlaced display.
Right, but I always turned that crap off. I never noticed any excessive flickering with NES emulator output.
blargg wrote:
the TV outputs on PCs usually include a "flicker reducer" filter since computer graphics with their crisp images would otherwise flicker badly on an interlaced display.
So does the GameCube. In the case of the GameCube, the game can turn on and off a [1 2 1]/4 line convolution kernel that the RAMDAC applies to each component before encoding it in video.
LocalH wrote:
Interlace combing is rarely visible on a true interlaced display, since each field has already started to fade by the time the other field is drawn. I haven't done it in a while, but I used to play NES games using TV-out all the time, and I never saw any combing artifacts.
All NES games and almost all Super NES games ran in 240p (NTSC) or 288p (PAL), not 480i or 576i.
Quote:
All NES games and almost all Super NES games ran in 240p (NTSC) or 288p (PAL), not 480i or 576i.
This mini-discussion was about displaying emulator output on a TV using PC video cards that only output an interlaced signal, and how negatively it affected the result as compared to the non-interlaced output of a NES.
Wouldn't the ideal accurate NES emulator try to get video output to a TV to look the same as the NES's video output to the same TV? Does anybody have the ability to capture the NES's video output and compare it against the video output coming out of the TV out of a computer? Would a TV tuner card be an accurate way to capture clips of video or do TV tuner cards introduce too many artifacts of their own, to be able to be a tool for objectively measuring the accuracy of video emulation?
What I am getting at is, lets get straight to the point and start posting screen captures of emulation video sent out on, composite, S-video, and component, side-by-side compared to the NES's composite video. That way everybody can see how close emulation can get the video to look like when displayed on a TV.
You have identified two main targets for emulation: casual emulation using the PC monitor and speakers, and hard-core emulation using a TV. The main point of this thread has been the former, making the image on a computer monitor look close to what you see on a TV.
Hard-core emulation on a TV can be taken as far as generating the raw NTSC composite signal using a high-speed DAC. On the old boards someone was talking about taking this route. This seems the best way to go if you want to use a TV, since otherwise it might be very difficult to ensure that your emulator->RGB->PC video card->NTSC->TV matches NES->TV, due to the PC video card unknowns.
I think you can reach sufficient results for 90% of people by having the emulator able to use either 640x480 or 720x480 mode for NTSC fullscreen, disabling scanlines (otherwise it will flicker like hell), weaving emulated fields together into a frame, and offering an option for PC or TV color so that the user can choose what looks best on their TV. Higher resolutions can be offered in fullscreen, but they're pretty much useless for TV-out. Sure, it won't be 100% accurate, but with S-Video or better, you won't have any additional artifacts on top of the emulated NES artifacts.