240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD

[Artemio]

I see, that is unfortunate... and good at the same time.

It might mean I made a mistake, or that both aren't really good at 480p. I'll look deeper into it, thanks s lot. Pics would be nice if possible. A small segment of the screen is perfectly good.

[Artemio]

New update for the Dreamcast version 1.19

https://sourceforge.net/projects/testsuite240p/files/

- SMPTE color bars
- Improved the lag test with FFT and dreamcast microphone
- Help for every test and pattern.
- Added Wii/GC contextual menu for Video, Help and options (start button)
- Changed button scheme to match the WIi/GC versions
- Changed video mode names, they are now easier to understand
- Now uses true Framebuffer screenshots for backgrounds when help is displayed (probably nobody cares, but it is fancy)

I've been playing around with the Fast Fourier Transform test and it is indeed very accurate if the audio follows teh same chain as the video. Tested the xrgb framemeister+TV and direct HT hookup.

I'll update the Genesis version with the SMPTE bars to its capabilities, and when my SD Loader arrives I will test the GC version personally, and compare its 480p output to the Wii.

[Bax]

Sorry about the delay. I'm not sure how helpful this will be, the camera doesn't quite capture much, it looks more dark gray with a hint of vertical lines in reality.

Edit: 2 more of 1:1.

[Artemio]

Thanks a lot, I'll look into it and see if it is my mistake or if it really can't display such a pattern.

[Paradise]

Hi,

maybe a stupid question. How can i burn the suite for Gamecube to CD?
My cube has a chip and until now i had only iso files to burn.

I want to test some RGB crt TV's with it.

[Artemio]

Here is an ISO release for the GC, I will include both methods from now on:

http://sourceforge.net/projects/testsuite240p/

[Traveller]

I know I kinda got into this awhile ago, but I have just received my RGB N64.

Does everyone here just set the image size using the 240p test suite? Some games seem to use a larger res, and setting to 240 will cut off bits of the full image. Is my best option just to use this?

Thanks.

[Artemio]

I know I kinda got into this awhile ago, but I have just received my RGB N64.

Does everyone here just set the image size using the 240p test suite? Some games seem to use a larger res, and setting to 240 will cut off bits of the full image. Is my best option just to use this?

Thanks.

Depending on the version of teh suite you are using, most of them have a 480i mode. The Genesis version though can only output 224p in NTSC (and 240p in PAL), since that is what the console is capable off.

The Wii, DC and GC versions have 480i (and will have 576i/288p very soon). I've been working in refining them to comply with the standards set by PAL and NTSC when in interlaced mode, so they should be 100% correct this week. I've been checking the output signals with an oscilloscope for that.

The currently released versions do output compatible signals in those modes, and games that output a larger res must output one of these.

Also, the release candidates of the suite currently allow to change the resolution inside the grid pattern and change the patterns to adapt to the new resolution, helping out when comparing them.

So, which version of the suite are you using and which games are outside of the range for you?

[Traveller]

I was using the Wii, but have not downloaded the recent one. I actually don't have it plugged into the PVM at the moment, I was just wondering what the best way to approach the N64 was.

Banjo Kazooie appears to output a smaller image, so it is showing black borders on all sides. If I set the image so that Banjo goes all the way to the edges, other games won't be showing the full picture. I guess thats just the way it goes though, I think the best option would be to find the smallest resolution grid and just set it to that. I gather thats the way most CRT's would have shown it back in the day right?

Beetle Adventure Racing also has its menus in a higher res than the actual game, so thats another one that has black on all sides.

Thanks!

[Artemio]

Many N64 games are 480i, so calibrating with the suite in that mode and alternating with 240p will give you a good idea of how much your display changes bewteen resolutions.

[Traveller]

Ok. I'll hook the Wii back up to it soon and try just calibrating for 480i.

Edit: Tried it. I set the grid to 480i and extended it so that the red squares were just touching the screen border. Various games that I presume are full screen are still not working right. Mario 64 has black on the top and bottom etc. It is better than before though.

[Xan]

It's fairly common for badly optimized PAL games to run with black borders at the top and bottom. In fact, when looking at this video, this is exactly the case for Mario 64. So if it's just that, everything is running as intended.

[Traveller]

Nah it's not that, I am running an NTSC system.

Some games just seem to not use the full screen. But games like Banjo on a crt never showed the black sides I am pretty sure, so am wondering if that was the normal display size.

[HDgaming42]

Nah it's not that, I am running an NTSC system.

Some games just seem to not use the full screen. But games like Banjo on a crt never showed the black sides I am pretty sure, so am wondering if that was the normal display size.

Many games do not use the full screen. If I'm not mistaken, when you place the red boxes at the outermost edge of your screen, you have essentially "defeated" overscan, have you not? So that anything that would have normally been hidden by overscan (including lack of game content) is now visible to you?

Is that not what you're seeing?

[Traveller]

Right ok. I was wondering if I was making a mistake as well.

So, when using the grid I should make the red squares go off the screen and not visible? I was thinking that originally but was unsure.

Thanks.

[Traveller]

I know I kinda got into this awhile ago, but I have just received my RGB N64.

Does everyone here just set the image size using the 240p test suite? Some games seem to use a larger res, and setting to 240 will cut off bits of the full image. Is my best option just to use this?

Thanks.

Depending on the version of teh suite you are using, most of them have a 480i mode. The Genesis version though can only output 224p in NTSC (and 240p in PAL), since that is what the console is capable off.

The Wii, DC and GC versions have 480i (and will have 576i/288p very soon). I've been working in refining them to comply with the standards set by PAL and NTSC when in interlaced mode, so they should be 100% correct this week. I've been checking the output signals with an oscilloscope for that.

The currently released versions do output compatible signals in those modes, and games that output a larger res must output one of these.

Also, the release candidates of the suite currently allow to change the resolution inside the grid pattern and change the patterns to adapt to the new resolution, helping out when comparing them.

So, which version of the suite are you using and which games are outside of the range for you?

Look forward to the 576i/288p. I have a few different setting variables working at the moment, but maybe that will provide the best trade offs. Having the NTSC standard would be what regular CRT's would have displayed correct?

[TheShadowRunner]

After more testing I think something could be wrong with the built-in SMPTE pattern of the Wii port.
When I calibrate my BVM using this SMPTE pattern [Control Preset Adj > CH Set > Auto > SMPTE CB], the image ends up being way too dark (burnt blacks).
It seems the color space of the built-in SMPTE pattern is wrong..(?)

Did anyone use this pattern to calibrate a PVM/BVM and got satisfying results?

Edit: my Wii is connected to BVM via original Component cable. The results are the same when I calibrate with the suite set to 240p or 480i.

[Artemio]

After more testing I think something could be wrong with the built-in SMPTE pattern of the Wii port.
When I calibrate my BVM using this SMPTE pattern [Control Preset Adj > CH Set > Auto > SMPTE CB], the image ends up being way too dark (burnt blacks).
It seems the color space of the built-in SMPTE pattern is wrong..(?)

Did anyone use this pattern to calibrate a PVM/BVM and got satisfying results?

Edit: my Wii is connected to BVM via original Component cable. The results are the same when I calibrate with the suite set to 240p or 480i.

Thanks for the feedback. As far as I can tell there is nothing wrong with the pattern. The color space of course depends on whether the signal is PAL or NTSC, but since I haven't released the PAL version the encoding should be NTSC in the one you are using.

Here are the values of the pattern when viewed through a scope, using composh... composite so that luma and chroma are present:

SMPTE Color bars, line 22


SMPTE Color bars, line 205 (pluge) white level is at 714mV (my scope can't step at lower values in this zoom level)


SMPTE Color bars, line 205 (pluge) black level is at 53mV


As you cansee at least the white and black level part of the signal matches what should be expected, and your black and white levels should be matching that. I still need to check out color, but from teh first image you can tell it also seems to match what is expected of it.

I am in the middle of checking all values comply to the NTSC and PAL standards for next release, so any feedback atm is quite welcome in order to adjust everything.

If someone knows why this is happening, please let me know. Values match what my text book says.

Look forward to the 576i/288p. I have a few different setting variables working at the moment, but maybe that will provide the best trade offs. Having the NTSC standard would be what regular CRT's would have displayed correct?

"NTSC" is what an NTSC console would output to a CRT. However the signal of the console is not necessarily NTSC (that is a brouadcast standard). They are NTSC compatible. The next release I make will have notes on these technical parts. The PAL tests are almost there, a lot of non standard things happening with resolutions so far. Still verifying.

[TheShadowRunner]

After more testing I think something could be wrong with the built-in SMPTE pattern of the Wii port.
When I calibrate my BVM using this SMPTE pattern [Control Preset Adj > CH Set > Auto > SMPTE CB], the image ends up being way too dark (burnt blacks).
It seems the color space of the built-in SMPTE pattern is wrong..(?)

Did anyone use this pattern to calibrate a PVM/BVM and got satisfying results?

Edit: my Wii is connected to BVM via original Component cable. The results are the same when I calibrate with the suite set to 240p or 480i.

Thanks for the feedback. As far as I can tell there is nothing wrong with the pattern. The color space of course depends on whether the signal is PAL or NTSC, but since I haven't released the PAL version the encoding should be NTSC in the one you are using.

Here are the values of the pattern when viewed through a scope, using composh... composite so that luma and chroma are present:

SMPTE Color bars, line 22


SMPTE Color bars, line 205 (pluge) white level is at 714mV (my scope can't step at lower values in this zoom level)


SMPTE Color bars, line 205 (pluge) black level is at 53mV


As you cansee at least the white and black level part of the signal matches what should be expected, and your black and white levels should be matching that. I still need to check out color, but from teh first image you can tell it also seems to match what is expected of it.

I am in the middle of checking all values comply to the NTSC and PAL standards for next release, so any feedback atm is quite welcome in order to adjust everything.

If someone knows why this is happening, please let me know. Values match what my text book says.

Thanks for your super detailed answer!
I really have not much clue what's wrong, it could totally be on my end ^_^;
What happens exactly is that before calibration -factory settings- I can see (1), (2) and (3).
After calibration I can only _barely_ see (3).
The color accuracy seems better to me after calibration, it's only the crushed blacks that is the issue.

Again I'm using Component out, from a JPN Wii.
Hmm I wonder if the issue could be because of this..

Code: Select all

The black level and blanking level of the NTSC-J signal are identical (at 0 IRE), as they are in PAL, another video standard, while in American NTSC, black level is slightly higher (7.5 IRE) than blanking level.

[Artemio]

Well, although I don't have a NTSC-J Wii to verify that - and I don't know if the available util to change region will change the vidoe standard - will check later. It is indeed a different encoding, so knowing that migt be teh source of the issue is refreshing since I didn't know/remember you had a NTSC-J wii.

So, I can make an NTSC-J SMPTE color bar pattern that could be auto selected if the console region is Japan, though I'll need you to verify this in a beta I will send you today. However I'd liek you to check out this corrected version of the NTSC SMPTE 75% color bars, since I noticed I was some pixels off in the version you have. That might be the cause of the issue as well, so please test this version first, and we'll see if a NTSC-J pattern is needed, since I believe there is no way to control that from inside the software, it is a wii configuration setting.

https://dl.dropboxusercontent.com/u/140 ... RCTest.zip

If anyone has a PAL Wii with component, composite or SCART RGB cables, could you also please test the PAL video modes with those cables?

Here is the info regarding the color bars I'd make for NTSC-J if needed. I still need to verify the corrections I'd need for PAL.

[TheShadowRunner]

So, I can make an NTSC-J SMPTE color bar pattern that could be auto selected if the console region is Japan, though I'll need you to verify this in a beta I will send you today. However I'd liek you to check out this corrected version of the NTSC SMPTE 75% color bars, since I noticed I was some pixels off in the version you have. That might be the cause of the issue as well, so please test this version first, and we'll see if a NTSC-J pattern is needed, since I believe there is no way to control that from inside the software, it is a wii configuration setting.
https://dl.dropboxusercontent.com/u/140 ... RCTest.zip

I tried this version and it didn't change anything, sorry :/ (nice job compressing the DOL though!)
I think the region detection is problematic for this. The output signal is set by the system software, not the console region. For exemple, when switching a NTSC-U Wii to PAL, RGB setting becomes available (and SVideo is disabled).
The region checking mechanism from CheckRegion only checks inside the Wii for it's serial number in the nand, and crossmatches it with a DB of serial numbers to determine the region.
In other words, not only it will report wrong information when the Wii region has been changed, it will also be problematic if indeed there is a different black level between NTSC-J and NTSC-U; this method cannot be trusted for region changed Wiis.
Is there any way to derive the region from the system software instead (4.x J / E / U)? I think it would be the most fool proof method for the suite to use.

For the beta you will build with the NTSC-J SMPTE pattern for testing, could you hardcode it and bypass the (serial based) region detection?

[Artemio]

I tried this version and it didn't change anything, sorry :/ (nice job compressing the DOL though!)

I am compressing al textures with zlib, the dol is uncompressed, thanks. I did compress the GC dol further though. All this helps a lot the Gamecube RAM.

I think the region detection is problematic for this. The output signal is set by the system software, not the console region. For exemple, when switching a NTSC-U Wii to PAL, RGB setting becomes available (and SVideo is disabled).
The region checking mechanism from CheckRegion only checks inside the Wii for it's serial number in the nand, and crossmatches it with a DB of serial numbers to determine the region.
In other words, not only it will report wrong information when the Wii region has been changed, it will also be problematic if indeed there is a different black level between NTSC-J and NTSC-U; this method cannot be trusted for region changed Wiis.
Is there any way to derive the region from the system software instead (4.x J / E / U)? I think it would be the most fool proof method for the suite to use.

I understand, I will look into this possibility. Thanks for the info, I haven't played with changing the wii region. If it does indeed change the video levels to NTSC-J, I'll probably have to dig into this to verify the values myself.

For the beta you will build with the NTSC-J SMPTE pattern for testing, could you hardcode it and bypass the (serial based) region detection?

Of course, however there is another issue regarding that... your PVM would probably expect NTSC SPTE, not NTSC-J bars... and those are just like the PAL bars as fas as I have investigated, they have no PLUGE at the bottom.

However, we can experiments bit further if you are willing to test it. The SMPTE color bars have been 75% all the time, maybe the monitor expects SMPTE bars at 100%, and I've just included them. I also included the PAL bars, and they do have 75 and 100% versions. Press the A button to switch between them, a small message will flash letting you know which ones you have selected.

This is the new build with the 100% bars and PAL EBU bars:
https://dl.dropboxusercontent.com/u/140 ... RCTest.zip

(yes, it is the same link, I replaced the dol)

[TheShadowRunner]

I am compressing al textures with zlib, the dol is uncompressed, thanks. I did compress the GC dol further though. All this helps a lot the Gamecube RAM.

I see, good job in all cases ;)

I understand, I will look into this possibility. Thanks for the info, I haven't played with changing the wii region. If it does indeed change the video levels to NTSC-J, I'll probably have to dig into this to verify the values myself.

While the signal change from NTSC-U (Svideo) to PAL (RGB) is certain and tested, between NTSC-U and NTSC-J, it is more subtle and conjecture on my part, I am not certain.

Of course, however there is another issue regarding that... your PVM would probably expect NTSC SPTE, not NTSC-J bars... and those are just like the PAL bars as fas as I have investigated, they have no PLUGE at the bottom.

Ah, I upgraded to a BVM last weekend. In the Auto calibration screen, I can select:
- FULL FIELD CB 100: 100% full-field color bar
- FF CB 75 (WHITE 100): 75% full-field color bar (with 100% white signal)
- SMPTE CB: SMPTE standard color bar
- EIA CB: EIA standard color bar

As you can see the SMPTE signal intensity (75% - 100%) isn't specified :S

However, we can experiments bit further if you are willing to test it. The SMPTE color bars have been 75% all the time, maybe the monitor expects SMPTE bars at 100%, and I've just included them. I also included the PAL bars, and they do have 75 and 100% versions. Press the A button to switch between them, a small message will flash letting you know which ones you have selected.

Sure, I'll test everything ;)
I recalibrated using the 100% version, it didn't change anything either.

But actually, I'm thinking about something! I think the SMPTE bar just cannot be used to calibrate a console signal.
From the wiki:
----------
When a monitor is properly adjusted, the rightmost pluge bar should be just barely visible, while the left two should appear completely black.
----------
And this is precisely what I'm getting. But this calibration is done for studio levels / movies (16-235), it will crop everything outside this range.
In the case of the Wii, which must output 0-255, the extra information 0-15 / 235-250 is in fact needed!
Does that make any sense to you?
Haha I'm so confused right now XD

[Artemio]

But actually, I'm thinking about something! I think the SMPTE bar just cannot be used to calibrate a console signal.
From the wiki:
----------
When a monitor is properly adjusted, the rightmost pluge bar should be just barely visible, while the left two should appear completely black.
----------
And this is precisely what I'm getting. But this calibration is done for studio levels / movies (16-235), it will crop everything outside this range.
In the case of the Wii, which must output 0-255, the extra information 0-15 / 235-250 is in fact needed!
Does that make any sense to you?
Haha I'm so confused right now XD

I was away for a while, and was thinking about this. And yes, we are completely silly, but not in the way you believe us to be.

SMPTE Color bars, line 205 (pluge) black level is at 53mV

This pattern was the clue, and it was obvious.

Indeed, having the console calibrated for NTSC levels with the SMPTE color bars will give you the NTSC setup at 7.5 IRE, which is the value 19 in RGB (255*0.075, or 7.5%). You are indeed assuming that the console game considers this, and not the full range RGB from 0 to 255.

But, you are indeed using an NTSC-J console, whose games are coded to use 0-255 and not 19-255. Now back to the image above, the line at the bottom is the reference or 0V in the SMPTE color bars as seen with teh scope in the PLUGE part of the SMPTE color bars. The console doesn't clip the signal, even in my NTSC-U console, it oputputs the level I tell it to output, zero in this case. The upper line is 7.5 IRE, and the difference is 53mV as it is supposed to be, the pulse below is 3.5IRE and the pulse above is 11.5 IRE.

Thing is, if your games are using the full range, you should calibrate to the 3.5 IRE black. You can use the PLUGE in the latest version I uploaded, where the background is 0 IRE, the first bars are 3.5 IRE, the second bars are 7.5 IRE and teh last ones are 11.5 IRE. This was the recommended method for adjusting this.

Just as a note, the suite never crops values from 235 upwards, since it isn't broadcasting. Also, the 100% SMPTE color bars use the 16-255 range, even in studio equipment. Even the broadcast 75% SMPTE color bars have "super white" in the lower part, which is 255,255,255.

So, You can use the auto adjustment as a startup level, and then just use the pluge to stretch your black level up to 3.5 IRE, as expected. I am in teh middle of finishing teh PAL PLUGE, which uses 2 IRE for black adjustment. I could add that to the NTSC PLUGE as well, or have an extra one for NTSC-J/full RGB levels.

EDIT: Just added a test version for you, it has teh PAL pluge, but you can use it in NTSC for Full range NTSC-J setup since it starts at 2 IRE, then 3.5 IRE and then 7.5 IRE. Just press teh A button while in teh pluge and it will toggle. A brioef message will let you know which one you are using.

[TheShadowRunner]

I was away for a while, and was thinking about this. And yes, we are completely silly, but not in the way you believe us to be.

Haha

SMPTE Color bars, line 205 (pluge) black level is at 53mV

This pattern was the clue, and it was obvious.

Indeed, having the console calibrated for NTSC levels with the SMPTE color bars will give you the NTSC setup at 7.5 IRE, which is the value 19 in RGB (255*0.075, or 7.5%). You are indeed assuming that the console game considers this, and not the full range RGB from 0 to 255.

But, you are indeed using an NTSC-J console, whose games are coded to use 0-255 and not 19-255. Now back to the image above, the line at the bottom is the reference or 0V in the SMPTE color bars as seen with teh scope in the PLUGE part of the SMPTE color bars. The console doesn't clip the signal, even in my NTSC-U console, it oputputs the level I tell it to output, zero in this case. The upper line is 7.5 IRE, and the difference is 53mV as it is supposed to be, the pulse below is 3.5IRE and the pulse above is 11.5 IRE.

Thing is, if your games are using the full range, you should calibrate to the 3.5 IRE black. You can use the PLUGE in the latest version I uploaded, where the background is 0 IRE, the first bars are 3.5 IRE, the second bars are 7.5 IRE and teh last ones are 11.5 IRE. This was the recommended method for adjusting this.

Just as a note, the suite never crops values from 235 upwards, since it isn't broadcasting. Also, the 100% SMPTE color bars use the 16-255 range, even in studio equipment. Even the broadcast 75% SMPTE color bars have "super white" in the lower part, which is 255,255,255.

So, You can use the auto adjustment as a startup level, and then just use the pluge to stretch your black level up to 3.5 IRE, as expected. I am in teh middle of finishing teh PAL PLUGE, which uses 2 IRE for black adjustment. I could add that to the NTSC PLUGE as well, or have an extra one for NTSC-J/full RGB levels.

It's a bit too technical for me but I *think* I understand
After calibration, the monitor was simply clipping 0-19, thus the blacks were crushed.
Is you Wii connected via Component as well ? Because it's another thing, while RGB always carries 0-255 I believe, Component can carry either 0-255 or 16-235(255?) and I have no idea what the Wii is set to output. Or is that completely irrelevant in view of your findings?
As for the definitive method in order to calibrate, an extra NTSC-J/full RGB levels pludge would be ideal, this way the monitor could calibrate on its own for perfection ^_^;

[Artemio]

It's a bit too technical for me but I *think* I understand
After calibration, the monitor was simply clipping 0-19, thus the blacks were crushed.
Is you Wii connected via Component as well ? Because it's another thing, while RGB always carries 0-255 I believe, Component can carry either 0-255 or 16-235(255?) and I have no idea what the Wii is set to output. Or is that completely irrelevant in view of your findings?

I've tested it throughly with the scope via component and composite. And it always displays 0-255, unless I give it a pattern starting at other value. So yes, it is completely irrelevant as far a NTSC-U Wii or GC goes.

As for the definitive method in order to calibrate, an extra NTSC-J/full RGB levels pludge would be ideal, this way the monitor could calibrate on its own for perfection ^_^;

It won't calibrate on its own, due to the reasons explained above. The NTSC-J pattern is teh same one as PAL. It will auto calibrate to NTSC-U with 7.5 IRE setup using the SMPTE color bars, as you've already done. For 0-255 range, use the PLUGE pattern set to Full RGB or PAL and adjust it to the 2 IRE bars. The link above has the updated dol with these patterns in the PLUGE.

[TheShadowRunner]

I've tested it throughly with the scope via component and composite. And it always displays 0-255, unless I give it a pattern starting at other value. So yes, it is completely irrelevant as far a NTSC-U Wii or GC goes.

Very good to know, thanks for testing.

It won't calibrate on its own, due to the reasons explained above. The NTSC-J pattern is teh same one as PAL. It will auto calibrate to NTSC-U with 7.5 IRE setup using the SMPTE color bars, as you've already done. For 0-255 range, use the PLUGE pattern set to Full RGB or PAL and adjust it to the 2 IRE bars. The link above has the updated dol with these patterns in the PLUGE.

Yes, I misundersood what you were saying, I thought you were proposing to add another version of the SMPTE bar (like you added a 100% version) altering the pluge section only. The monitor would have then been able to auto-calibrate everything on its own.

Here's what I did with your latest build (I hadn't seen the edit sooner, sorry).
I fed the monitor the 75% SMPTE bar and used the Auto Calibration feature.
As usual the result was black crush. I then opened the Pluge pattern and set it to "RGB Full Range". From there I raised the Brightness until the 2nd bar became barely visible (from Brightness 1000 to 1050 on the BVM). Incidentally, the 2nd bar in "RGB Full Range" indeed corresponds to the 1st bar in "NTSC 7.5 IRE" (so I'm not certain the "RGB Full Range" Pluge is really needed after all?)
Indeed, it corrects the black crush beautifully and I must say the pq is now quite stunning ;D

Thank you very much for figuring this out, I would have lived without auto-calibration otherwise (no way I could handle the black crush) and the factory setting had a nasty green tint on this component input.

Oh on another note, this latest beta build seem to break a couple things on the SFC controller side.
Increasing the IRE for exemple is done with the START button which is also mapped to Menu with the SFC controller setting enabled. I'm pretty sure you didn't forget and it's due the beta nature of the build, but we never know ^^

Edit: Btw, is there a way to force/keep the Wiimote alive? It goes in sleepmode way too often and way too quickly XD

[Artemio]

Yes, I misundersood what you were saying, I thought you were proposing to add another version of the SMPTE bar (like you added a 100% version) altering the pluge section only. The monitor would have then been able to auto-calibrate everything on its own.

I did intend to naively create such a pattern, but it can't be done so...

Here's what I did with your latest build (I hadn't seen the edit sooner, sorry).
I fed the monitor the 75% SMPTE bar and used the Auto Calibration feature.
As usual the result was black crush. I then opened the Pluge pattern and set it to "RGB Full Range". From there I raised the Brightness until the 2nd bar became barely visible (from Brightness 1000 to 1050 on the BVM). Incidentally, the 2nd bar in "RGB Full Range" indeed corresponds to the 1st bar in "NTSC 7.5 IRE" (so I'm not certain the "RGB Full Range" Pluge is really needed after all?)
Indeed, it corrects the black crush beautifully and I must say the pq is now quite stunning ;D

Excellent, that was exactly what I hoped would work out.

The second PLUGE with Full range RGB gives you a 2 IRE bar at the left, you can press X and it will show the IRE values and highlight the IRE bars as needed. This is the PAL pattern as well, since 2 IRE is what is used then. And yes, the 2nd bar in the Full one corresponds to the 1st bar in the NTSC 7.5 IRE one, but that is only 3.5 IRE.

Thank you very much for figuring this out, I would have lived without auto-calibration otherwise (no way I could handle the black crush) and the factory setting had a nasty green tint on this component input.

Thank you for your help and input as well. This is a community driven project.

Oh on another note, this latest beta build seem to break a couple things on the SFC controller side.
Increasing the IRE for exemple is done with the START button which is also mapped to Menu with the SFC controller setting enabled. I'm pretty sure you didn't forget and it's due the beta nature of the build, but we never know ^^

Yes, there are a lot of things to test yet, and a lot of changes that might not be evident until I document all of them and post the next release up. This particular case was because a the button mapping wasn't checked when the user holds teh button down, thanks for finding that out. I updated the beta for you just now. Will keep that in mind, thanks.

Btw, is there a way to force/keep the Wiimote alive? It goes in sleepmode way too often and way too quickly XD

Made that to last 3 times longer, hope that is enough. Since I have it on a lot of time while I test, I had it set too low.

[TheShadowRunner]

I did intend to naively create such a pattern, but it can't be done so...

Ah, I see.

The second PLUGE with Full range RGB gives you a 2 IRE bar at the left, you can press X and it will show the IRE values and highlight the IRE bars as needed. This is the PAL pattern as well, since 2 IRE is what is used then. And yes, the 2nd bar in the Full one corresponds to the 1st bar in the NTSC 7.5 IRE one, but that is only 3.5 IRE.

Ah nice the X button feature, I hadn't seen it.
What I mean about the Full Range RGB Pluge is that it only adds the 2 IRE bar, which is under any circumstance of no use under NTSC, so why keep it? The key value here is 3.5 IRE which is already present in the NTSC 7.5 Pluge so..
Edit Aahh I figured it out. I thought when the output was set to PAL, there was a single correct Pluge for PAL, and similarly for NTSC. In fact both Pluge are always present regardless of output, the user needs to select the correct one manually.

Yes, there are a lot of things to test yet, and a lot of changes that might not be evident until I document all of them and post the next release up. This particular case was because a the button mapping wasn't checked when the user holds teh button down, thanks for finding that out. I updated the beta for you just now. Will keep that in mind, thanks.

Got you. Yeah I did notice many changes and new features, I thought it couldn't be perfected from 1.4 but you actually did it ;)

Made that to last 3 times longer, hope that is enough. Since I have it on a lot of time while I test, I had it set too low.

Great, thanks for that.

[Konsolkongen]

Hey Artemio. The new version for the WIi fixes the RGB problem. Thanks a lot

The Wii has super clean RGB in 240p mode. This actually goes for component as well, but most of the time we use that for 480p which is a blurry mess on the Wii.

I don't have a RGB cable anymore because I used that to make a breakout box to easily switch between RGB and component. Still, the RGB signal looks really, really good. This is using the XRGB-mini at 1080p, Smart_X2, H/V scaler at 5/6:



- Ignore the red tint in this one, it's caused by my camera or the fact that my TV flickers in impulse mode, or a combination of both

Is there a reason for the huge amount of IRE patterns? It would be very tedious having to go through all of those if you were calibrating with by 10% increments

Great job!