It is currently Tue Oct 17, 2017 2:50 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 150 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 10  Next
Author Message
 Post subject:
PostPosted: Thu Oct 20, 2011 12:30 am 
Offline
User avatar

Joined: Fri Oct 14, 2011 1:09 am
Posts: 248
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:
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.

Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 12:33 am 
Offline

Joined: Tue Mar 15, 2005 10:34 am
Posts: 34
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? ;)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 12:35 am 
Offline
User avatar

Joined: Fri Oct 14, 2011 1:09 am
Posts: 248
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 1:41 am 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
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?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 2:19 am 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 2:42 am 
Offline

Joined: Sun Sep 19, 2004 11:07 pm
Posts: 154
@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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 3:37 am 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
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:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 5:29 am 
Offline

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

Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 5:37 am 
Offline
User avatar

Joined: Fri Oct 14, 2011 1:09 am
Posts: 248
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 5:44 am 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 10:19 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6273
Location: Seattle
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 12:15 pm 
Offline

Joined: Wed Mar 31, 2010 12:40 pm
Posts: 207
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.

Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 12:20 pm 
Offline
User avatar

Joined: Sat Jan 22, 2005 8:51 am
Posts: 427
Location: Chicago, IL
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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 12:45 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 20, 2011 1:16 pm 
Offline
User avatar

Joined: Fri Oct 14, 2011 1:09 am
Posts: 248
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.)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 150 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 10  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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