nesdev.parodius.com

[NewRisingSun]

[tepples]

[NewRisingSun]

Here are the NTSC PPU's two artifact patterns compared:

Three-stage pattern, if the background was off during line 20:
field 0:
[img][/img]
field 1:
[img][/img]
field 2:
[img][/img]
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:
[img][/img]
field 1:
[img][/img]
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.

[Dwedit]

Animated at 20fps:

3 fields, dot crawl goes up


2 fields, dot crawl jitters

[Guest]

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?

[blargg]

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.

[hap]

how about one for PAL now ?

Awesome achievement NewRisingSun, blargg !

[Lloyd Gordon]

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.

[Bregalad]

[NewRisingSun]

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.

[tepples]

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.

[Quietust]

[NewRisingSun]

[tepples]

[Jagasian]

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?