NTSC pattern torture test ROM

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
NTSC pattern torture test ROM
by on (#182409)
I found myself a little bit interested in the pattern of colour artifacts the NTSC NES produces. I decided to make a test ROM that shows off the patterns easily. Most of the shapes are arranged in groups of 3 pixels so they tend to align with diagonal 3-pixel groupings the artifacts seem to have.

Basically it's just a screen with some dot patterns. You can scroll it around with the D-pad. Press select to modify the background or foreground colours. Press start to reset.

Attachment:
File comment: comparison picture captured from my NES
ntsc_torture_compare.png
ntsc_torture_compare.png [ 276.88 KiB | Viewed 14206 times ]


Of particular interest I think is the square of dots at the top right, and the stripes at the top left. Both of these will appear as a single "colour", which you should be able to see three distinct states of depending what pixel they are scrolled to. As expected, I also notice that the phase changes when I reset my NES (there are two groups of states with red/green/blue vs cyan/magenta/yellow patterns). These effects aren't really new information or anything, but I thought a good visual demonstration might help understand the nature of these patterns.

(Note: the image is just a raw capture from my cheap capture device. It is an interlaced image, so it represents two consecutive frames. The specific colour depends on the startup alignment of the PPU, and the sharpness/definition of various things is highly specific to this capture device. It's not meant to represent any kind of ideal target for emulation.)
Re: NTSC pattern torture test ROM
by on (#185516)
I decided to have a stab at implementing bisqwit's NTSC filter code (the one he posted earlier this year with integer math).

This is what it ends up looking like at full resolution (the top left part makes me wonder if the coloring is correct - it doesn't match neither your screen capture nor blargg's filter, but any change I make produces the wrong palette in games).
Attachment:
File comment: ntsc_torture (2048x1920)
ntsc_torture.png
ntsc_torture.png [ 642.5 KiB | Viewed 13266 times ]

I'm not completely certain my implementation is correct though - the old tvfailpass/tv.nes test doesn't look that great compared to blargg's filter.
Though I can't test on an actual console/TV, so I have no way to know.
Attachment:
tvpassfail.png
tvpassfail.png [ 101.23 KiB | Viewed 13266 times ]

And this is what it looks like on an actual game:
Attachment:
smb3.png
smb3.png [ 2.36 MiB | Viewed 13266 times ]

Performance-wise, the code is pretty mean (although I'm sure my code is far from optimal). Between creating the NTSC signal from the palette output, converting it to RGB, and resampling the height to 1920px, it takes 2 threads to run the filter at 70fps (on my 7-year-old i5) while a 3rd core is running the emulation.
At quarter resolution though (1024x960), it's not that bad (approx 140fps)
Re: NTSC pattern torture test ROM
by on (#185645)
Sour wrote:
the top left part makes me wonder if the coloring is correct

There are six possible colourings depending on the phase of the PPU at time of reset.

On any given reset, you should be able to see three of the six possibilities by using the d-pad to move the screen around in 1 pixel increments.
Re: NTSC pattern torture test ROM
by on (#185646)
Here are some sample pictures of what my QuickBASIC NES emulator produces for this test ROM:

Image Image Image
The horizontal lines in the bottom left of the screen (border region) disappear if I scroll it upwards (00 EF or lower).

The QuickBASIC code has a newer version of the filter that runs much much faster than the C++ version does (if the language difference is ignored), because it updates a running variable only once per channel per pixel, instead of doing 12 or 24 multiplications per pixel. But it is also less accurate, because it rounds to integers. It is unique compared to (probably) every other NES emulator in the world in that it simulates a full frame of television signal, with borders, syncs, colorbursts and all, with the NTSC decoder knowing absolutely nothing about what is happening inside the PPU (things like current scanline number, etc). The only interface between the NTSC decoder and the rest of the emulator is the 1 integer that represents the current voltage level of the NTSC signal that changes about 5 million times in a second.

The older and more accurate C++ version (the one that is documented in the Wiki) flickers between these two (click to zoom):
Image Image Image

The third picture is produced if the code merges all three fields.

Note that any possible hardware screen captures depend entirely on what ever postprocessing your television set / composite decoder happens to do with the signal.
If I change my (C++) emulator to merge two fields into one (which a television is certainly not required to do), here is one of the outcomes:

Image
It is quite a close match to the first sample posted by rainwarrior, if we ignore saturation differences.
Re: NTSC pattern torture test ROM
by on (#185651)
MESEN implementation:

feos want to modify this algorithm for PAL-Filter in near future.
But sines must be recalculated.
Re: NTSC pattern torture test ROM
by on (#185660)
I'd be really grateful if someone modifies the constants to the PAL standard.

Bisqwit wrote:
The QuickBASIC code has a newer version of the filter that runs much much faster than the C++ version does (if the language difference is ignored), because it updates a running variable only once per channel per pixel, instead of doing 12 or 24 multiplications per pixel. But it is also less accurate, because it rounds to integers. It is unique compared to (probably) every other NES emulator in the world in that it simulates a full frame of television signal, with borders, syncs, colorbursts and all, with the NTSC decoder knowing absolutely nothing about what is happening inside the PPU (things like current scanline number, etc). The only interface between the NTSC decoder and the rest of the emulator is the 1 integer that represents the current voltage level of the NTSC signal that changes about 5 million times in a second.

Is it here?
Re: NTSC pattern torture test ROM
by on (#185666)
Bisqwit wrote:
The horizontal lines in the bottom left of the screen (border region) disappear if I scroll it upwards (00 EF or lower).

Is there some explanation as to why they appear at all in your emulator? The ROM isn't doing any kind of raster manipulation, it's just a static screen.
Re: NTSC pattern torture test ROM
by on (#185667)
feos wrote:
I'd be really grateful if someone modifies the constants to the PAL standard.

That depends on someone with a PAL NES being willing to run test patterns on hardware on short notice. Are you such a someone?
Re: NTSC pattern torture test ROM
by on (#185668)
I meant the constants in the Bisqwit's filter, and yes, myself and Eugene.S will run any tests that are needed.

We don't exactly have PAL NES, but this thing that we have should work very well, since Dendy uses a clone of PAL PPU:
viewtopic.php?f=9&t=14861
Re: NTSC pattern torture test ROM
by on (#185669)
feos wrote:
I'd be really grateful if someone modifies the constants to the PAL standard.

It is not only the matter of modifying the constant.
You have to reverse the phase of the colorburst for every other scanline, too (or something like that, I don't remember the specifics).

feos wrote:
Bisqwit wrote:
The QuickBASIC code has a newer version of the filter that runs much much faster than the C++ version does (if the language difference is ignored), because it updates a running variable only once per channel per pixel, instead of doing 12 or 24 multiplications per pixel. But it is also less accurate, because it rounds to integers. It is unique compared to (probably) every other NES emulator in the world in that it simulates a full frame of television signal, with borders, syncs, colorbursts and all, with the NTSC decoder knowing absolutely nothing about what is happening inside the PPU (things like current scanline number, etc). The only interface between the NTSC decoder and the rest of the emulator is the 1 integer that represents the current voltage level of the NTSC signal that changes about 5 million times in a second.

Is it here?

Yes, that would be it.

rainwarrior wrote:
Bisqwit wrote:
The horizontal lines in the bottom left of the screen (border region) disappear if I scroll it upwards (00 EF or lower).

Is there some explanation as to why they appear at all in your emulator? The ROM isn't doing any kind of raster manipulation, it's just a static screen.

I can't offhand think of any explanation. The border color is determined by the address internally accessed by the PPU during the border rendering (i.e. if it's 3Fxx...), and/or the background color from the palette, so there may be a bug somewhere in that processing.


Eugene.S wrote:
<video attachment>

The video is chroma-supersampled (YUV 420p colorspace). It rather completely defeats the purpose of trying to show something where colors of individual pixels matter.
Re: NTSC pattern torture test ROM
by on (#185693)
I took a video capture of the ROM running in my real NES, and the capture is surprisingly faithful to what I saw on my TV screen :

https://youtu.be/l-y9gaU-pR4

When you watch this in 60fps, you can see some that combinations of colors cause the upper left square to visibly flicker, which I thought weird. I would have lingered longer, but I couldn't see it on the capture device's viewer, so I thought the effect was lost. When I converted the video to 60fps, it reappeared.
Re: NTSC pattern torture test ROM
by on (#185696)
Great Hierophant wrote:
When you watch this in 60fps, you can see some that combinations of colors cause the upper left square to visibly flicker, which I thought weird. I would have lingered longer, but I couldn't see it on the capture device's viewer, so I thought the effect was lost. When I converted the video to 60fps, it reappeared.

My captured picture is actually an interlaced image. If you look closely at the top left square, you can see that it is two alternating fields of magenta and yellow, i.e. the output is alternating frames this way.

I didn't intend for the capture image to be a thing to verify your emulators against, just a sample image demonstrating some of the colour artifacts that can be produced. For instance, the edges of white text via the capture card show a lot of rainbow stripes there, but a different decoder, like the one in my TV, produces much cleaner definition on that. A lot of this stuff varies significantly from device to device. (Also don't forget there are 6 possible alignments of the PPU!)
Re: NTSC pattern torture test ROM
by on (#185704)
Bisqwit wrote:
It is not only the matter of modifying the constant.
You have to reverse the phase of the colorburst for every other scanline, too (or something like that, I don't remember the specifics).

Yes. Here's what I used in my FCEUX attempt (with a lookup table and 768 pixel long line):
Code:
const  float   phasex  = (float) 5/18*2;
const  float   phasey  = (float) 1/ 6*2;
const  float   pi      = 3.14f;

float alpha = (x*phasex + y*phasey)*pi;          // 2*pi*freq*t
if (y%2 == 0) alpha = -alpha;                    // phase alternating line!
moire[x+y*18] = Y + U*sin(alpha) + V*cos(alpha); // modulated composite signal


EDIT:

The 768-pixel approach was bad, because it matched neither tuner result, not TV result, because of oversampling of YUV. But I was generating too little versions of each color: tuner output (640 pixel wide) shows about 17 versions of each color, which is how pixel freq alignes with Luma sample freq. The end value is a direct average of the Luma samples present in that pixel:

Image
Re: NTSC pattern torture test ROM
by on (#185749)
rainwarrior wrote:
My captured picture is actually an interlaced image.

I was wondering why the per-scanline color alterations appear to be twice as thin/frequent as in my screenshots.
Thanks for explaining.

EDIT: Hmm, I wonder if you can generate composite video in real time with e.g. Raspberry Pi GPIO DAC (or some ARM Nucleo board), for testing different outcomes.
Re: NTSC pattern torture test ROM
by on (#185757)
Does not work here.

---------------------------
Mesen
---------------------------
Mesen não pode iniciar pois foi incapaz de carregar MesenCore.dll devido a falta de dependências.
---------------------------
OK
---------------------------

"Mesen cannot start because it was unable to load MesenCore.dll due to the lack of dependencies".
Re: NTSC pattern torture test ROM
by on (#185760)
Zepper wrote:
Does not work here.
Are you trying to run Eugene's build?
It's probably dynamically linked against MSVC's standard library. "Official" builds are statically linked, so that shouldn't happen.
You can grab Mesen 0.7.0, it has the filter & should work.
Otherwise, you can also install the VC++ 2015 x86/x64 runtime on your PC and it should fix the problem, too.
Re: NTSC pattern torture test ROM
by on (#185763)
Got the official version, worked fine. Btw, blargg's NTSC version looks better.
Re: NTSC pattern torture test ROM
by on (#189090)
I did some tests of my own on an NTSC TV with some dither patterns...kind of interesting, I think.

Attachment:
DitherB.jpg
DitherB.jpg [ 566.5 KiB | Viewed 5063 times ]


Original, much larger picture...

http://dl.dropboxusercontent.com/s/y0ty ... Dither.jpg
Re: NTSC pattern torture test ROM
by on (#189091)
dougeff wrote:
I did some tests of my own on an NTSC TV with some dither patterns...kind of interesting, I think.

It would be interesting if you posted the pixel-perfect image for comparison.

Quote:
http://dl.dropboxusercontent.com/s/y0tyq4w45hdv1ak/Dither.jpg

Today's lesson: Don't ever use dither patterms on the NES. :wink:

In all seriousness, I guess there are a few legitimate reasons to use dithering, but the basic notion that you can create uniform colors definitely doesn't apply here, specially if the image is supposed to scroll. The only time I absolutely needed to use dithering was on my raycaster, but the big software pixels and lack of scrolling really helped.
Re: NTSC pattern torture test ROM
by on (#189093)
dougeff wrote:
http://dl.dropboxusercontent.com/s/y0tyq4w45hdv1ak/Dither.jpg


Ooh, carpet tiles.
Re: NTSC pattern torture test ROM
by on (#189099)
This is what it looks like in FCEUX...

Attachment:
dither.png
dither.png [ 2.51 KiB | Viewed 5016 times ]


Here is the ROM. I added scroll left and right function. You can see it pretty good in Nestopia with the NTSC filter on. (didn't test any others)

Attachment:
dither.nes [24.02 KiB]
Downloaded 193 times


I think the clear winner is the horizontal striped bars. They don't change or flicker or get weird diagonal patterns when scrolling. (in the picture, not the top left, but just to the right of that).

Further investigation...
I did some tests with very similar colors, and I find that dithering with a slightly lighter shade of the exact same hue (15 with 25) produces smoother look, even on NTSC. Still getting diagonal lines on most of the patterns though.
Re: NTSC pattern torture test ROM
by on (#189104)
Interesting how the worst offender (i.e. the one that results in diagonals with the highest contrast) is the basic checkerboard pattern that many inexperienced artists would try.
Re: NTSC pattern torture test ROM
by on (#189148)
dougeff wrote:
I did some tests with very similar colors, and I find that dithering with a slightly lighter shade of the exact same hue (15 with 25) produces smoother look, even on NTSC. Still getting diagonal lines on most of the patterns though.

Pictures?
Re: NTSC pattern torture test ROM
by on (#189156)
Here's a picture. NTSC CRT TV. Colors 15 25, 1a 2a, 11 21, 05 15

I'm going to try to make a video.

Attachment:
dither2.jpg
dither2.jpg [ 309.04 KiB | Viewed 4936 times ]


Attachment:
dither2.png
dither2.png [ 2.52 KiB | Viewed 4927 times ]
Re: NTSC pattern torture test ROM
by on (#189158)
Right, and the source (aka plain emulator output)?
Re: NTSC pattern torture test ROM
by on (#189159)
Stripes in dither patterns are caused by chroma spilling over into frequencies associated with luma (0-3.0 MHz). This happens when the signal is high or low for significantly longer or shorter than half a cycle of the color subcarrier, particularly when switching between different hues. But when the hue is the same (e.g. $15 vs. $25), that just changes the luma level, and the TV successfully separates out the changes in luma from the (lack of) changes in chroma. You see some faint stripes in the checkerboard pattern with $05 and $15 (row 7, column 3) because the chroma is stronger (more saturation) in $15 and $25 than in $05 and $35.

feos: In each case, the plain emulator output resembles the white portion of the original attachment.
Re: NTSC pattern torture test ROM
by on (#189160)
Video

https://youtu.be/bD7mNw5McBs

Also, edited above post to include 'emulator output'.

I probably need to adjust mt TV's color. $15 is coming out purple.
Re: NTSC pattern torture test ROM
by on (#216641)
Here is hi-quality capture via Canon 700D
on Famicom AV and Philips 20GX8552/59R CRT
(*ntsc_torture2 = dither.nes)

http://hwm.us.to/famimusic/CAPTURE/
(warning: HUGE SIZE)