It is currently Sun Oct 22, 2017 2:14 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Thu Dec 29, 2005 3:45 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 29, 2005 10:41 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 30, 2005 7:17 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
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.


Last edited by NewRisingSun on Fri Feb 10, 2006 6:13 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 30, 2005 1:20 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
Animated at 20fps:
Image
3 fields, dot crawl goes up

Image
2 fields, dot crawl jitters

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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 01, 2006 8:41 pm 
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?


Top
  
 
 Post subject:
PostPosted: Mon Jan 02, 2006 9:17 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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).

Image

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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 03, 2006 6:44 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
how about one for PAL now ? :wink:

Awesome achievement NewRisingSun, blargg !


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 04, 2006 8:48 am 
Offline
User avatar

Joined: Mon Nov 07, 2005 11:32 am
Posts: 150
Location: Toronto
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 04, 2006 2:01 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7234
Location: Chexbres, VD, Switzerland
hap wrote:
how about one for PAL now ? :wink:


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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 06, 2006 3:54 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
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.


Top
 Profile  
 
PostPosted: Sat Jan 07, 2006 1:42 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 07, 2006 2:35 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
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

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


Last edited by Quietust on Fri Nov 14, 2008 7:31 am, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 07, 2006 11:17 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 283
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 07, 2006 3:21 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 08, 2006 11:14 am 
Offline

Joined: Wed Feb 09, 2005 9:31 am
Posts: 418
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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group