Video probs w/ SNES RGB (Vertical Bands, etc)

[GigaBoots]

Thats odd because the captures by shartqueefa have no difference in colors. Have you checked the RGB gain and offsets are still at default on the OSSC?

I was noticing that too. I checked everything on my capture card just in case but didn’t check the OSSC. I can’t remember ever messing with those options but I’ll check it in about 10 hours. Gotta work and sleep first.

[Voultar]

Got my SNES back from Voultar. The MMX Pre/Post-fix images all have the same correction applied to them. All captured lossless 4:2:0, upscaled 4X by the OSSC. I later confirmed all of my findings with lossless 4:4:4 captures, I'm just not redoing all these screen caps when they look identical (bc 420 = 1/4 chroma res, OSSC 4x negates.)

Google Drive Lossless PNG's: https://drive.google.com/open?id=1fjxC_ ... c5DsLEc5Jp



Pre-Fix

Spoiler

Post-Fix

Spoiler

Pre-Fix (jumping)

Spoiler

Post-Fix (jumping)

Spoiler

The following pictures are softened by Vegas zooming in; Sharper in reality.

Post-fix (Hyper Contrasted)

Spoiler

No Adjustments at all

Spoiler

Final Comparison:

Before/After Split

Spoiler

The Pure White Test:

Pure White (pre)

Spoiler

Pure White (Post)

Spoiler

Pure White (emulated)

Spoiler

Conclusions: All of the previous problems are effectively solved with ghosting almost completely unnoticeable (can see on super-high contrast content that's been adjusted) but the colors are different now. A blue tint has been introduced to the image. You can see this easily in the pictures of pure white, though it's evident normal gameplay.



Here's a Yoshi's Island clip to confirm ghosting is nearly completely invisible: https://www.youtube.com/watch?v=D1MQTFHRETQ


I'm troubled that a blue tint has been introduced and I'm not sure how to progress from here. :\

Are you absolutely sure a setting isn't mucked up on your devices?

I manually measured the v-PP of each output (see my scope pots in the iniitial post) and there was none of this "stepping" between R, G and B. when verifying that the distortion resolved itself. I know others here have, too. I don't believe this has anything to do with the fix.

[GigaBoots]

I’ll check the OSSC later today. It’s certainly possible that it was messed with I just don’t know why. It seems the most logical possibility given that you took measurements of each channel.

[Voultar]

Just to clarify.

The left shot is C11 untouched. The right side is C11 w/ 470nF.



The Y cursor has been fixed to 712mV, rather than doing a reference, I'm just old-school like that. On the left picture, there's maybe a measly 10mV swing before it stabilizes.


As you can see, the differences in amplitude are negligible and I'm unable to reproduce your Vegas capture. But looking at your Vegas shot, it looks like there's perfectly even stepping between the color inputs in terms of their amplitude. It looks like there's a 50mV increase between red, green and blue.


Comparison courtesy of RetroRGBob:

Spoiler

Gigaboots, if you can't find a problem with your configuration. You can send it back to me, completely free of charge. You've spent enough money. I'll take care of the return shipping. Just make sure it isn't an equipment issue. Because I honestly don't have an explanation for you as what I saw & tested on the scope differs greatly from your current problem.

[rama]

I don't get any color level changes either, 2 consoles modded so far.
It's probably just an accidental change with the capture card or Vegas software.

[Voultar]

I did a few reference shots, but they're so inline with each other it's hard to make anything out.


The reference (white) sample I raised slightly to around 25mV just so could clearly see the difference in wave form.

[GigaBoots]

I tested both capture cards, multiple codecs, raw .BMP screencaps, and also S-video. The blue is present in every test. I even proved that Vegas isnt' wrong by testing the S-video Screengrab in DaVinci Resolve, the industry standard for color correction and grading.

S-video Direct capture, Resolve's Scopes:

Spoiler

Also, the vertical bars still exist despite being vastly mitigated, which is fine it's hardly noticeable but I thought I'd post for reference here:

Spoiler

I've done every conceivable test now. It's not the capture cards (tested both and they're identical & calibrated,) it wasn't the OSSC (it showed up in S-Video,) it's not Vegas (showed up in Resolve,) and it's definitely not any of the many codecs and raw BMP format I captured this in. I think I've irrefutably proven that this is real now.

This sucks. Not sure what deity is pissed off to luck out with this SNES like this. I guess once the SD2SNES shows up I could make an OSSC profile that corrects for the blue (if Offset and Gain are able to do that effectively) and only use that profile on the SNES but that doesn't help me for Analog video.

I'll ponder your offer Voultar. Thanks.

[Voultar]

I tested both capture cards, multiple codecs, raw .BMP screencaps, and also S-video. The blue is present in every test. I even proved that Vegas isnt' wrong by testing the S-video Screengrab in DaVinci Resolve, the industry standard for color correction and grading.

S-video Direct capture, Resolve's Scopes:

Spoiler

Also, the vertical bars still exist despite being vastly mitigated, which is fine it's hardly noticeable but I thought I'd post for reference here:

Spoiler

I've done every conceivable test now. It's not the capture cards (tested both and they're identical & calibrated,) it wasn't the OSSC (it showed up in S-Video,) it's not Vegas (showed up in Resolve,) and it's definitely not any of the many codecs and raw BMP format I captured this in. I think I've irrefutably proven that this is real now.

This sucks. Not sure what deity is pissed off to luck out with this SNES like this. I guess once the SD2SNES shows up I could make an OSSC profile that corrects for the blue (if Offset and Gain are able to do that effectively) and only use that profile on the SNES but that doesn't help me for Analog video.

I'll ponder your offer Voultar. Thanks.

Something simply isn't adding up here. If you do choose to send it back (completely free), please include the PSU you're using. I'm 100% convinced that there's another element at play here that's beyond the C11 replacement. I'm really trying to think of what could be plaguing your setup. All of my scope plotting & signal analysis shows something completely different from what you're getting currently, and I can't reproduce it on any system. I've done several of these, Rama's done a few, FBX has done his and so has RetroRGB with none of these ill-effects.

Just put the bastard back in a box and let me cover the shipping.

[GigaBoots]

So as an experiment, I used video scopes and the OSSC's gain controls to correct the image. It honestly looks fine, but of course this won't help me for non-scart analog output. I'm still definitely sending it back at some point, at very least for science. I've yet to find another PSU to power it but I have a friend locally who might be able to help me out soon.


Post-OSSC Corrections gameplay

Spoiler

Post-OSSC Corrections Pure White

Spoiler

ADDITION TO POST: so I downloaded RetroRGB's screen cap. Is he using a Framemeister or OSSC? The colors a smidge off and his screencap is 1080p so I'm assuming he is. Anyway, here's his SNES (02), mine w/ OSSC (post-gain adjustment), and ZSNES of the same area. All images are scaled in Photoshop to fill the same approximate screen space (but the PAR of each image was kept untouched.) My PAR is 4:3, ZSNES is 8:7.



RetroRGB (SNES 02)

Spoiler

OSSC Post-"calibration":

Spoiler

ZSNES:

Spoiler

I'm almost there with the colors being balanced, getting in the SD2SNES would help me nail it with the 240p test suite. I do notice that there's a weird after-halo to the right of every high-contrast region in my image. Here's some zoom-ins to exemplify. The halo is EXACTLY 1 pixel in size.



My Pixels:

Spoiler

ZSNES' Pixels:

Spoiler

RetroRGB's (02) Pixels:

Spoiler

As you can see from the ZSNES sample, that's not fine pixel work shading, it's definitely a post-high contrast halo. RetroRGB's halo seems far more muddled (both left and right) in comparison but still present.

[Voultar]

So as an experiment, I used video scopes and the OSSC's gain controls to correct the image. It honestly looks fine, but of course this won't help me for non-scart analog output. I'm still definitely sending it back at some point, at very least for science. I've yet to find another PSU to power it but I have a friend locally who might be able to help me out soon.


Post-OSSC Corrections gameplay

Spoiler

Post-OSSC Corrections Pure White

Spoiler

ADDITION TO POST: so I downloaded RetroRGB's screen cap. Is he using a Framemeister or OSSC? The colors a smidge off and his screencap is 1080p so I'm assuming he is. Anyway, here's his SNES (02), mine w/ OSSC (post-gain adjustment), and ZSNES of the same area. All images are scaled in Photoshop to fill the same approximate screen space (but the PAR of each image was kept untouched.) My PAR is 4:3, ZSNES is 8:7.



RetroRGB (SNES 02)

Spoiler

OSSC Post-"calibration":

Spoiler

ZSNES:

Spoiler

I'm almost there with the colors being balanced, getting in the SD2SNES would help me nail it with the 240p test suite. I do notice that there's a weird after-halo to the right of every high-contrast region in my image. Here's some zoom-ins to exemplify. The halo is EXACTLY 1 pixel in size.



My Pixels:

Spoiler

ZSNES' Pixels:

Spoiler

RetroRGB's (02) Pixels:

Spoiler

As you can see from the ZSNES sample, that's not fine pixel work shading, it's definitely a post-high contrast halo. RetroRGB's halo seems far more muddled (both left and right) in comparison but still present.

You have to keep in mind that the SNES 1CHIP has a variably wide output swing. No two consoles are going to necessarily look completely identical in terms of their amplitude.

Also, remember that you're comparing a pure digital source to an analog source that's went through A/D conversion. I don't know of any (A)nalog to (D)igital (C)onverter that's going to give you that digital (emulation) pixel precision. Not to mention, the color space conversion that's happening in your video chain.

Welcome to analog video.

[FBX]

OSSC Post-"calibration":

Spoiler

If you don't mind listing it here, can you tell me what settings you use for scaling your SNES on the OSSC? I'd like to have a look at them myself. Thanks!

[copy]

Kudos to Voultar et al. for another interesting discovery and fix.

Speaking of replacing ceramic caps, can I jump in with a quick question? Quoting RetroRGB's page on the SNES white line fix:

Also, replacing the 1uF surface mount capacitor on the 78S05CV-DG's output circuit with a 22uF should also help a bit:

Murata GRM21BR61C226ME44L
https://www.digikey.com/product-detail/ ... ND/5251353
http://www.mouser.com/search/ProductDet ... 61C226ME4L

Bob links to an 0805 size for this cap. I assume that's right for a 1CHIP, but is it also okay for a Mini? Or does the Mini need an 0603 here?

[Voultar]

Kudos to Voultar et al. for another interesting discovery and fix.

Speaking of replacing ceramic caps, can I jump in with a quick question? Quoting RetroRGB's page on the SNES white line fix:

Also, replacing the 1uF surface mount capacitor on the 78S05CV-DG's output circuit with a 22uF should also help a bit:

Murata GRM21BR61C226ME44L
https://www.digikey.com/product-detail/ ... ND/5251353
http://www.mouser.com/search/ProductDet ... 61C226ME4L

Bob links to an 0805 size for this cap. I assume that's right for a 1CHIP, but is it also okay for a Mini? Or does the Mini need an 0603 here?

Really, I just use 0603 for everything. But 0805 would fit on both, too. Might be a little big, but you'll be able to grab both pads.

[FBX]

Really, I just use 0603 for everything. But 0805 would fit on both, too. Might be a little big, but you'll be able to grab both pads.

I'm looking at C11 for the mini right now and I doubt 0805 would fit. It uses a much smaller cap (probably the 0603 you use).

Edit: Yeah the mini needs an 0603. Here is the best I could find on Digi-key:

https://www.digikey.com/product-detail/ ... ND/3316954


-FBX

[FBX]

So here's a pic I took of the 0805 replacement cap sitting below the original 0603 in the mini:



You might be able to fit it, but I decided instead to just order a batch of those 0603 caps I linked to. No headaches, just gonna get it done right the first time.

At any rate, while I'm waiting for those caps, I used the OSSC and Datapath Vision card to document the ghosting in the mini. This mini has Voultar's RGB board already installed:



And below is a negative image with enhanced edge sharpness of the health meter and ghosting:



I'll post after-mod pics when the new 0603 caps arrive from Digi-key.

I will say for now that the mini was rather dark on the OSSC at default settings, I had to raise the gain values from the default 26 all the way up to 68 in order to get properly bright whites. This might be because of the SCART cable I was using, but I don't know for sure.

-FBX

[FBX]

I do notice that there's a weird after-halo to the right of every high-contrast region in my image. Here's some zoom-ins to exemplify. The halo is EXACTLY 1 pixel in size.

Have you tried the sampling phase setting in the OSSC? I noticed when I compared my 1CHIP-03 to the mini, each required a different sampling phase setting. The mini worked fine for the default of 180, but this was way off for the 1CHIP-03 (with stock encoder). So then I tried a setting of zero degrees, and it looked pretty good except for that same 1-pixel halo you have in your pics. Then I changed the setting to 90 degrees and the halo vanished entirely.

Edit: Further OCD testing shows the sampling phase can also cause dark halos, and also halos on the left side of pixels. Using the Mega Man X snow stage, I was able to fine-tune the sampling phase to get rid of all halo artifacts. For my 1CHIP-03 with stock encoder, this ended up being 123 degrees. Here's how it looks now:

Spoiler

Edit: Figured out the noise issue I was having: My Datapath capture color space somehow reverted to 5-6-5. Changing it back to 8-8-8 got rid of the noise. We're emulator perfect now!


-FBX

[RGB0b]

so I downloaded RetroRGB's screen cap. Is he using a Framemeister or OSSC? The colors a smidge off and his screencap is 1080p so I'm assuming he is.

SNES -> fully shielded cable -> OSSC 5x -> Datapath E1s
Capture software is the "Vision" software, set to full RGB color (8:8:8) saved as a BMP. OSSC settings are "stock", with nothing tweaked.

Figured out the noise issue I was having: My Datapath capture color space somehow reverted to 5-6-5. Changing it back to 8-8-8 got rid of the noise. We're emulator perfect now!

If you're using the Vision software, you have to set it to 8:8:8 every time you launch the software. It's a pain, but you get used to it.

[FBX]

OSSC settings are "stock", with nothing tweaked.

That's the problem. The sample phase, H-Sample clock rate, and scaling are not aligned at stock settings, and is very dependent on each specific console in order to dial it in. I'm finding this out testing each of my consoles.

If you're using the Vision software, you have to set it to 8:8:8 every time you launch the software. It's a pain, but you get used to it.

No actually it was may fault, and you don't have to keep setting it each time you run the software. The trick is to get everything set the way you want, and then use "Save Settings As" to save the settings as a profile. Then next time you want to run the Vision window, double-click on the profile you saved. It will load up the Vision window with your preferred settings intact.


-FBX

[GigaBoots]

Just got off work. Your suggestion of tweaking the sampling phase worked like a charm. Here's a new screencap with the sampling phase set to 0.

SuMari World sample Phase 0:

Spoiler

Zoom in:

Spoiler

MMX:

Spoiler

Major revelation. The sampling phase adjustment fixed the vertical bar that seemingly remained until now. Here's a contrasted up sample shot:

Spoiler

If you don't mind listing it here, can you tell me what settings you use for scaling your SNES on the OSSC? I'd like to have a look at them myself. Thanks!

Sure, it's by no means applicable to most people system's cause mine is borked (obviously) but my settings are:

Gain: R-40 G-35 B-31
Offset: R-128 G-128 B-128

These settings were sorta set up using SMW assets as reference points but without a gray ramp it's by no means perfect. Even while bringing the blue down by that much it's still showing up in my greens. It looks really great but calibrating it to what I consider a final setting would definitely require the output to be more balanced and I'd need the 240p test suite so I can fine tune the offset too.

As for screencaps, I use AmaRecTV. The screenshot function should work without a paid codec license, and it's great for screencaps, imo. It does have an "interesting" problem with the Datapath though..

It records correctly, but the preview window...

Spoiler

[FBX]

Cool, glad the sampling phase turned out to the the culprit on the halo. And yeah, the OSSC requires a level of obsession far beyond the framemeister, but this is right up my alley, and I'm having a blast with it.

I started working on the Genesis, including tweaking the colors to as closely match Kega Fusion as I could get. It's not exactly the same, but that's because we're dealing with 25-year-old analog hardware versus digital software. In the pic below, the left image is my VA3 Genesis through the OSSC, and the right image is Kega Fusion:

Spoiler

Pretty damn close anyway, and the Genesis was quite the challenge to get perfect pixels in 320 mode.

-FBX

[GigaBoots]

Cool, glad the sampling phase turned out to the the culprit on the halo. And yeah, the OSSC requires a level of obsession far beyond the framemeister, but this is right up my alley, and I'm having a blast with it.

Yea, I generally tend to use more difficult equipment that forces me to learn but ultimately provides the best image possible for the buck. Got a BMD camera years ago and taught myself color correction and color grading with it.

Pretty damn close anyway, and the Genesis was quite the challenge to get perfect pixels in 320 mode.

-FBX

I heard the Genesis has 2 different resolutions thus wouldn't you need to make 2 profiles for different resolutions? Also, some games switch resolutions (like CV Bloodlines, supposedly.)

[FBX]

I heard the Genesis has 2 different resolutions thus wouldn't you need to make 2 profiles for different resolutions? Also, some games switch resolutions (like CV Bloodlines, supposedly.)

Already anticipated this last year with the Framemeister: I went through and sorted every game that uses 320 mode as main gameplay into a separate folder on my X7 Mega Everdrive. So I'll actually be making 3 profiles for the Genesis like I did on the Framemeister:

320 mode games.
256 mode games.
Universal profile for games the jump repeatedly between 320 and 256.

[GigaBoots]

Wait, is there a database online for these resolutions or did you figure that out yourself? This is definitely something I'm interested in..

[FBX]

Wait, is there a database online for these resolutions or did you figure that out yourself? This is definitely something I'm interested in..

I tested each USA game myself in an emulator. This text file below lists every 256 mode main gameplay game, and I added notes when sub menus or title screens switched to 320:

http://www.firebrandx.com/downloads/Gen ... 20List.txt

Games NOT appearing in that list use 320 mode for main gameplay. So what you'd do for the USA titles is sort out the games that appear in my text file list and put them in a "256 Gameplay" folder, while the rest would go in a "320 Gameplay" folder.

And I apologize in that I should have specified I only did the USA library.

-FBX

[paulb_nl]

I will say for now that the mini was rather dark on the OSSC at default settings, I had to raise the gain values from the default 26 all the way up to 68 in order to get properly bright whites. This might be because of the SCART cable I was using, but I don't know for sure.

Voultar has stated that there is a wide output variance between consoles. Your mini might have been attenuated too much.

[rama]

OSSC settings are "stock", with nothing tweaked.

That's the problem. The sample phase, H-Sample clock rate, and scaling are not aligned at stock settings, and is very dependent on each specific console in order to dial it in. I'm finding this out testing each of my consoles.

I ran into this issue myself and tried to look for an automatic solution.
Apparently, TFT makers had to solve this problem for their VGA displays back then.

If you remember your early PC flat screens, they always had an option to optimize the dot clock / phase. Most ran it automatically when the resolution changed.
From reading a patent on it, it looks like they go through the entire sampling phase range and actually "look" at the result, then pick the best one.
Just instead of a pair of eyes, they use a chip to do it.

We would need to do something similar on our upscalers, if we wanted it to be automatic.

[FBX]

I will say for now that the mini was rather dark on the OSSC at default settings, I had to raise the gain values from the default 26 all the way up to 68 in order to get properly bright whites. This might be because of the SCART cable I was using, but I don't know for sure.

Voultar has stated that there is a wide output variance between consoles. Your mini might have been attenuated too much.

My mini has voultar's board installed. I'm thinking it's more likely that these consoles were not meant to drive 255-0 RGB ranges, and so the whites in both my Genesis and this console were instead in the 220s to 230s range. It's easily fixed using the gain functions for R, G, and B, and you can even correct for non-perfect balance of the channels.

[paulb_nl]

My mini has voultar's board installed.

That does not mean that the output of your mini can't be too dark. For example, my unmodded 1-CHIP-01 already outputs a good brightness. If I were to install Voultar's board then the attenuating resistors alone would make it too dark. However the 7374 has a lower gain than the stock encoder so combined it would be even darker.

The brightness variations might be related to the tolerance of the R3 resistor borti4938 was talking about which controls the output current.

[borti4938]

That's a good point to jump in with my measurements on R3.
Surprisingly, I wasn't able to confirm that the S-RGB (not S-RGB A version) has a higher gain than 6dB. Actually it was a bit below and the THS7374 was a bit above of 6dB. But step by step.

My system:

• SNSP-CPU-1CHIP-01 (i.e. PAL 1Chipper)
• S-CPUN has 160ohm load resistors on R, G and B outputs (like NTSC big model; NTSC Mini/Jr. has 150ohm)
• S-RGB (not the S-RGB A version)
• RGB Bypass with THS7314 and THS7374 (filter on and off)

All measurements show the corresponding red output. Green and blue outputs were all over equivalent in my system!

First measurement was about replacing C11 to additionally confirm Voultar findings. I just used the S-CPUN output for that measurement.
Well, nothing to add to Voultar findings.



(Fig. takes the data points of the following oscilloscope measurements)

Spoiler

Also interesting is the rise time. I measured around 20ns for both C11 values.

Spoiler

The next figure shows the impact on of R3
a) on the rise time and
b) on the amplitude



(Fig. takes the data points of the following oscilloscope measurements)

Spoiler

One can clearly see that
a) the rise time in not effected (in the measured range)
b) the attenuation drops with rising value of R3

So far everything is as expected. So let's take a look into several video amplifier approaches. I investigated

• S-RGB output with 150ohm load (equivalent to NTSC systems afak)
• S-RGB with post transistor output with 150ohm load (not 100% equivalent to PAL system; stock PAL system has 76.5ohm load)
• THS7314 with 150ohm load
• THS7374 (LPF on and off) with 150ohm load (THS7374 with LPF off is state of the art for RGB bypass)

Measurement point was always after 75ohm; i.e. virtually at the MultiAV output assuming a 0ohm cable resistance(1-3 ohm would be more realistic) and 75ohm input load at reciever side.

First I was interested in how the different approaches effect the rise time. Here is the THS7374 in bypass mode clearly superior than all others.



This approach does not effect the rise time at all. The S-RGB follows with a rise time increase by a factor of two. Next is S-RGB with post transistor, THS7314 and THS7374 with LPF. I put all of them into the spoiler.

Spoiler

Sooooooo... and finally the attenuation fix with R3. In my system I found the following values for R3 suiteable:

• R3 = 1.69kohm for S-RGB output with 150ohm load (as like as in a NTSC big model 1Chip),
• R3= 1.74kohm for S-RGB with post transistor and 150ohm load at the transistor output (mostly as like as in a stock PAL 1Chip-SNES), and
• R3 = 1.79kohm for THS7314, und THS7374 with 150ohm load (THS7374 with filter off is state of the art RGB bypass method)

Keeping the measurement point in mind (exactly at the half of the load) the S-RGB has a gain of below 6dB, the S-RGB with post transistor a gain of 6dB, and finally the THS7374 a gain of something above 6dB.

I do have another system I want to update C11 and R3. I will do similar measurements on it if found the time.
This system is a SNSP-CPU-1CHIP-02 and has a S-RGB A, IIRC.

Edit: I corrected my resistor values for R3. I'm sorry for that.

[RGBSource]

That's a good point to jump in with my measurements on R3.
Surprisingly, I wasn't able to confirm that the S-RGB (not S-RGB A version) has a higher gain than 6dB. Actually it was a bit below and the THS7374 was a bit above of 6dB. But step by step.

....

Sooooooo... and finally the attenuation fix with R3. In my system I found the following values for R3 suiteable:

• R3 = 1.74kohm for S-RGB output with 150ohm load (as like as in a NTSC big model 1Chip),
• R3= 1.79kohm for S-RGB with post transistor and 150ohm load at the transistor output (mostly as like as in a stock PAL 1Chip-SNES), and
• R3 = 1.82kohm for THS7314, und THS7374 with 150ohm load (THS7374 with filter off is state of the art RGB bypass method)

Excellent analysis Borti!

So, if people are using Voultar's board, they should probably be removing the 1k2 resistors on that PCB and replacing R3 with the appropriate value on the console PCB (and adding a series cap before the THS7374).