nesdev.com

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.

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.

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.


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.


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

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

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.

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.

_________________
Life is complex: it has both real and imaginary components.

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.

This should work: http://www.qmtpro.com/~nes/demos/square.zip

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

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?

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?