NTSC color palette emulation, with the square wave modulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Bisqwit
Posts: 248
Joined: Fri Oct 14, 2011 1:09 am

Post by Bisqwit » Thu Oct 20, 2011 12:30 am

That is kind of a valid point. I presume there are two kinds of mishaps that may happen to the perfectly good square wave signal:
  • Emphasis of spikes at edges
  • Trailing bias towards average (appears as smoothing and slanted lines)
Possibly a mixture of both. An of course, addition of a DC offset.
Aside from the DC offset, I am not sure how to precisely model these mishaps. I.e. how do I write a capacitor in code. Sure I have done all the R-C-τ calculations when I was in engineering school, but it has been years. I still remember R = 1÷√(2πFC)… But not what it was used for.
Perhaps someone could contribute a good square wave function that models these effects with parameters, like:

Code: Select all

float GetSquareWaveSample(
    float wavelength /* the signal repeats at these intervals*/,
    float offset /* offset into the signal; if wavelength=2, then offset 0..2 represents a single and complete wave with the top and the bottom, and 2..4 repeats it */,
    float spike_emphasis /*Some measure how much the transitions are over-emphasized. */,
    float smoothness /* A value of 0 produces a perfect squarewave (assuming no spikes), a large value produces a signal that slowly approaches the desired signal level, with the edges starting a bit closer to the middle-level than they should */
);
In hardwareguy's oscilloscope dump, it appears that there is no spike overshooting effect, but the signal level settles to the desired level in a perfect RC curve, as in every 10th of the wavelength it changes by 70% of the difference of the current and intended signal level or something like that (rather than the 100% currently simulated by my algorithm).
Now, the question is, at which step(s) does the degradation happen? This is particularly important with the de-emphasis bits: If the signal controlling the effect of the de-emphasis bits is analog rather than digital, the problem of how to decide the de-emphasis attenuation level is back and stronger than ever.

The current model does reflect accurately the color signal as it is in some stage internal to the NES PPU. I am not sure whether the goal of accurate emulation should be to emulate the purest source signal as it is generated or all the myriad of possibilities it can get damaged on various hardware. I tend to lean on the side of the former, but that may be just laziness.
Last edited by Bisqwit on Thu Oct 20, 2011 1:12 am, edited 9 times in total.

Kinopio
Posts: 34
Joined: Tue Mar 15, 2005 10:34 am

Post by Kinopio » Thu Oct 20, 2011 12:33 am

lidnariq wrote:
Kinopio wrote:I was under the impression that not enough is known about exactly how the PPU generates colors to correctly emulate it?
We know exactly how the PPU generates color. The problem is that every television parses the output slightly differently, and so there isn't one correct palette.
I know and this is often stated, but surely there is a standard way to decode/parse the video signal?
Dwedit wrote:That problem with that approach is that you're at the mercy of how your video capture device encodes the colors.
And why I don't like that approach. I did it mostly for fun and to get palettes that matched my tv's output. I would prefer a really good palette generator instead, but it seems that they also have problems if there isn't any standard ("correct") way to decode colors. And probably no way(?) to get them to generate palettes that match my captured palettes without knowing how my video card/tv decodes colors.

The NES palette is really frustrating. Couldn't nintendo used an 8- or 9-bit RGB palette instead? ;)

Bisqwit
Posts: 248
Joined: Fri Oct 14, 2011 1:09 am

Post by Bisqwit » Thu Oct 20, 2011 12:35 am

Kinopio wrote:So I'm wondering if you Bisqwit or someone else can tell me what settings I should use in a palette generator to match my captured palettes (PAL and NTSC)?
If you can provide me your palette as a .PAL file I can try to see which settings in my generator result in the best match to it.

EDIT: And oh, there is then another, far more serious problem if you seek accuracy: RGB without color management is <insert negative attributes here>. To quote Wikipedia: RGB is a device-dependent color model: different devices detect or reproduce a given RGB value differently, since the color elements (such as phosphors or dyes) and their response to the individual R, G, and B levels vary from manufacturer to manufacturer, or even in the same device over time. Thus an RGB value does not define the same color across devices without some kind of color management.

User avatar
HardWareMan
Posts: 206
Joined: Mon Jan 01, 2007 11:12 am

Post by HardWareMan » Thu Oct 20, 2011 1:41 am

ReaperSMS wrote:In theory, the phase shift should cancel out. Yes, the colorburst is shifted, but the color is determined by the phase relationship between the colorburst and the mid-line chroma signal, which should be hit with the same phase shift.
Most true for relationship between color burst and color subcarrier. PPU makes 12 phases from masterclock: 6 phases direct and 6 phases inverse. So, we don't know for sure, wich delay are may be between this phases at divider. This delay can affect to color, becouse can be detected by decoder. And color change occur.
Kinopio wrote:I know and this is often stated, but surely there is a standard way to decode/parse the video signal?
Yes sir! They has long been used in digital TV processors, and PC TV tuners. ;)
Bisqwit wrote:In hardwareguy's oscilloscope dump, it appears that there is no spike overshooting effect, but the signal level settles to the desired level in a perfect RC curve, as in every 10th of the wavelength it changes by 70% of the difference of the current and intended signal level or something like that (rather than the 100% currently simulated by my algorithm).
Now, the question is, at which step(s) does the degradation happen? This is particularly important with the de-emphasis bits: If the signal controlling the effect of the de-emphasis bits is analog rather than digital, the problem of how to decide the de-emphasis attenuation level is back and stronger than ever.
You will be surprised: inside PPU. This shots are taken direct from 21 pin of PPU. Closer:
Image
And even more closer:
Image
So, some integrating circuit are present in it. I think, they are made on purpose to reduce spectrum of color subcarrier, and do not allow our decoder go mad (many, many color spikes in B-Y channel will be present, believe me, I had experience to build digital PAL coder. :3).
So, where is your God?

User avatar
HardWareMan
Posts: 206
Joined: Mon Jan 01, 2007 11:12 am

Post by HardWareMan » Thu Oct 20, 2011 2:19 am

Let's take the case. You write me a small demo, which fills the screen with one color. Color change cyclically on the button joystick. I will record you two adjacent lines (needed for PAL). Then you try to make the software implementation of the decoder. I can to record PAL and NTSC. Deal?
PS For the reference levels made black and white vertical bars. Like this: WBWCCCCCCCCCCWBW, where W - maximum white, B - true black and C - color. One tile width will be good. ROM must be AROM or 0 mapper.

ReaperSMS
Posts: 174
Joined: Sun Sep 19, 2004 11:07 pm
Contact:

Post by ReaperSMS » Thu Oct 20, 2011 2:42 am

@Bisqwit

The DAC in the PPU is one big resistor with a number of taps. Modellable as a shoddy R2R network probably, but the deemph attenuation is controlled digitally -- it's just another tap on the thing.

There's going to be two main sources of distortion in the output. Internal to the PPU, there's probably some slew rate limits on the output, probably combined with RC effects. External to the PPU, there's the video filter circuit, which probably smooths things out even more.

I would suggest that the canonical emulation would be for the post-filtered AV-out video, since that is what 99.99999999999999% of the audience would be comparing to.


@HardWareMan

The 12 phases should be evenly spaced, since the 21 MHz clock is nominally 50/50. The filter should be phase-agnostic as far as output, since they're all at the same frequency.

User avatar
HardWareMan
Posts: 206
Joined: Mon Jan 01, 2007 11:12 am

Post by HardWareMan » Thu Oct 20, 2011 3:37 am

ReaperSMS wrote:The 12 phases should be evenly spaced, since the 21 MHz clock is nominally 50/50. The filter should be phase-agnostic as far as output, since they're all at the same frequency.
In theory - yes. In practice - it depends on the implementation of the divider. Here are 12 phases (6 lines and 6 inverse):

Code: Select all

21M _-_-_-_-_-_-_-_-_-_-_-_-
PH0 ______------______------
PH1 -______------______-----
PH2 --______------______----
PH3 ---______------______---
PH4 ----______------______--
PH5 -----______------______-
PH6 ------______------______
PH7 _------______------_____
PH8 __------______------____
PH9 ___------______------___
PHA ____------______------__
PHB _____------______------_
We see that the need to build the first 6 phases, 6 secondly - it is the inversion of the first. 3 phases is generated at the rise of masterclock and 3 at descent. Depending on the implementation possible additional phase shift between them if masterclock are not 50% duty cycle (wich hard to get in simple generator, wich used in NES). Furthermore, if the inverted phase signal a formed by simple inverter, they will be delayed for a delay time of inverter. It's obvious. The only true way to learn how to form the 12 phases of the color subcarrier and calculate their delay with respect to each other is decapsulation and research of the PPU's crystal.

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Thu Oct 20, 2011 5:29 am

Kinopio wrote:but surely there is a standard way to decode/parse the video signal?
Everything is supposed to be specified in the NTSC standard, which is part of the United States Code of Federal Regulations. There are probably several relevant ITU standards as well.
The NES palette is really frustrating. Couldn't nintendo used an 8- or 9-bit RGB palette instead? ;)
That would have cost more. I guess it's cheaper in hardware to do hue/brightness than to convert to RGB to YUV or YIQ or even to have three sine wave generators, one for each of R, G, and B, and add them up.
Bisqwit wrote:RGB without color management is <insert negative attributes here>.
The intended color space is that of the phosphors in an early-1980s television.

Bisqwit
Posts: 248
Joined: Fri Oct 14, 2011 1:09 am

Post by Bisqwit » Thu Oct 20, 2011 5:37 am

tepples wrote:
Bisqwit wrote:RGB without color management is <insert negative attributes here>.
The intended color space is that of the phosphors in an early-1980s television.
Yes, but an RGB palette in an emulator (whether constants or generated) is just RGB values without any information about how they are to be interpreted. Information that would allow displaying them on different monitors / other devices in the same way.

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Thu Oct 20, 2011 5:44 am

Bisqwit wrote:an RGB palette in an emulator (whether constants or generated) is just RGB values without any information about how they are to be interpreted.
Both major PC operating systems tend to assume that RGB unadorned with color management information should be interpreted as sRGB. So the final step of a palette generator would involve translating from whatever color space to sRGB.

lidnariq
Posts: 8785
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Post by lidnariq » Thu Oct 20, 2011 10:19 am

Kinopio wrote:
lidnariq wrote:
Kinopio wrote:I was under the impression that not enough is known about exactly how the PPU generates colors to correctly emulate it?
We know exactly how the PPU generates color. The problem is that every television parses the output slightly differently, and so there isn't one correct palette.
I know and this is often stated, but surely there is a standard way to decode/parse the video signal?
There absolutely is: look at this post where I demodulated NTSC by hand. But like I said, every television does things slightly differently.

beannaich
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

Post by beannaich » Thu Oct 20, 2011 12:15 pm

Bisqwit wrote:I think mr. beannaich made one in Java, I presume it could be used as a standalone program. beannaich?
I still have it if anyone wants it, I could just make a crappy google site or something and just embed it there.

EDIT: google sites apparently don't allow you to embed java applets. So for now you can download it here
Last edited by beannaich on Thu Oct 20, 2011 1:28 pm, edited 1 time in total.

User avatar
James
Posts: 429
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James » Thu Oct 20, 2011 12:20 pm

tepples wrote:translating from whatever color space to sRGB.
What is the proper method of converting YIQ to sRGB? Some variation of the RGB conversion matrix in Bisqwit's code?
get nemulator
http://nemulator.com

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Thu Oct 20, 2011 12:45 pm

First convert YIQ to RGB using whatever primaries NTSC specifies, then convert RGB using those primaries to sRGB using well-known color space translation methods.

Bisqwit
Posts: 248
Joined: Fri Oct 14, 2011 1:09 am

Post by Bisqwit » Thu Oct 20, 2011 1:16 pm

Well, good news: It seems to be already sRGB. Heh.
According to http://www.ipol.im/pub/algo/gl_localcol ... cc9be8b6e1 anyway. (That code uses the "popular" matrix, though.)
At least if one uses 2.2 for the gamma. (Rather than the 1.8 that I made default rather arbitrarily.)

Post Reply