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.paulb_nl wrote: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?
Video probs w/ SNES RGB (Vertical Bands, etc)
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
Are you absolutely sure a setting isn't mucked up on your devices?GigaBoots wrote: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-FixPost-FixSpoiler
Pre-Fix (jumping)Spoiler
Post-Fix (jumping)Spoiler
Spoiler
The following pictures are softened by Vegas zooming in; Sharper in reality.
Post-fix (Hyper Contrasted)No Adjustments at allSpoiler
Final Comparison:Spoiler
Before/After SplitSpoiler
The Pure White Test:
Pure White (pre)Pure White (Post)Spoiler
Pure White (emulated)Spoiler
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. :\
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.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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:
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.
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.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.
It's probably just an accidental change with the capture card or Vegas software.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.
The reference (white) sample I raised slightly to around 25mV just so could clearly see the difference in wave form.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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:
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:
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.
S-video Direct capture, Resolve's Scopes:
Spoiler
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.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.GigaBoots wrote: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: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
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.
Just put the bastard back in a box and let me cover the shipping.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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
Post-OSSC Corrections Pure White
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)
OSSC Post-"calibration":
ZSNES:
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:
ZSNES' Pixels:
RetroRGB's (02) Pixels:
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.
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.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.GigaBoots wrote: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 gameplaySpoiler
Post-OSSC Corrections Pure WhiteSpoiler
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.
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.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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!GigaBoots wrote:
OSSC Post-"calibration":Spoiler
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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:
Speaking of replacing ceramic caps, can I jump in with a quick question? Quoting RetroRGB's page on the SNES white line fix:
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?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
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.copy wrote: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:
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?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
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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).Voultar wrote: 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.
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
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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
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
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.GigaBoots wrote: 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.
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
-FBX
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
SNES -> fully shielded cable -> OSSC 5x -> Datapath E1sGigaBoots wrote: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.
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.
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 wrote: 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!
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.retrorgb wrote: OSSC settings are "stock", with nothing tweaked.
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.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
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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:
Zoom in:
MMX:
Major revelation. The sampling phase adjustment fixed the vertical bar that seemingly remained until now. Here's a contrasted up sample shot:
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...
SuMari World sample Phase 0:
Spoiler
Spoiler
Spoiler
Major revelation. The sampling phase adjustment fixed the vertical bar that seemingly remained until now. Here's a contrasted up sample shot:
Spoiler
Sure, it's by no means applicable to most people system's cause mine is borked (obviously) but my settings are:FBX wrote: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!
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
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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:
Pretty damn close anyway, and the Genesis was quite the challenge to get perfect pixels in 320 mode.
-FBX
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
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.FBX wrote: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 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 wrote:
Pretty damn close anyway, and the Genesis was quite the challenge to get perfect pixels in 320 mode.
-FBX
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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:GigaBoots wrote: 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.)
320 mode games.
256 mode games.
Universal profile for games the jump repeatedly between 320 and 256.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
Wait, is there a database online for these resolutions or did you figure that out yourself? This is definitely something I'm interested in..
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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:GigaBoots wrote:Wait, is there a database online for these resolutions or did you figure that out yourself? This is definitely something I'm interested in..
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
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
Voultar has stated that there is a wide output variance between consoles. Your mini might have been attenuated too much.FBX wrote: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.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
I ran into this issue myself and tried to look for an automatic solution.FBX wrote: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.retrorgb wrote: OSSC settings are "stock", with nothing tweaked.
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.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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 wrote:Voultar has stated that there is a wide output variance between consoles. Your mini might have been attenuated too much.FBX wrote: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.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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.FBX wrote:My mini has voultar's board installed.
The brightness variations might be related to the tolerance of the R3 resistor borti4938 was talking about which controls the output current.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
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:
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)
Also interesting is the rise time. I measured around 20ns for both C11 values.
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)
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
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.
Sooooooo... and finally the attenuation fix with R3. In my system I found the following values for R3 suiteable:
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.
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)
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
Spoiler
a) on the rise time and
b) on the amplitude
(Fig. takes the data points of the following oscilloscope measurements)
Spoiler
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)
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
- 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.
Last edited by borti4938 on Mon Nov 20, 2017 8:18 pm, edited 1 time in total.
Re: Video probs w/ SNES RGB (Vertical Bands, etc)
Excellent analysis Borti!borti4938 wrote: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)
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).