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

[GigaBoots]

Oh shit Ruprit, that is the exact same problem. Do you also have a THS 7374 mod?

[Ruprit]

Oh shit Ruprit, that is the exact same problem. Do you also have a THS 7374 mod?

I do, I'm using Voultar's THS7374 mod.

[Harrumph]

I only have ntsc consoles.

Ah, I assumed too much, my bad.

[Syntax]

Not sure if it makes a difference as I haven't looked at Voultar's amps but I'm using Bortis 7374 design.

[FBX]

Not sure if it makes a difference as I haven't looked at Voultar's amps but I'm using Bortis 7374 design.

In my case, the aliasing lines the Framemeister shows were happening with a prototype of Borti's board as well as when I swapped it over to Voultar's newest board.

[borti4938]

I wonder, have you ever tried adjusting the sample rate and phase when using no filter?

That's nearly impossible without using the same clock source.

Technical explonation:
The video signal comming out of the SNES has discrete nature (convoluted with a rectangular signal of width equal the pixel width). This means you have a periodic spectrum with periodicy of f_pixel (spectrum is multiplied with a sin(x)/x function due to the convolution.)

Now, you have to know that a sampling process creates a spectrum, which build of the original spectrum and mirrors at multiples of the sampling frequency. Original and mirrors are summed up.
This means, that if the sampling frequency does not EXACTLY match the pixel frequency, frequency content of the periodics of the initial spectrum folds back into positions where they don't have to be.
Further and unrelated to f_pixel, if the initial spectrum has a higher bandwidth than half of the sampling frequency, original and mirros are overlapping to each other.

This distortion is called aliasing and cannot be reversed after the sampling process. To remove the periodic spectrum content as well as to bandlimited the spectrum a low pass filter has to be used; so no aliasing can be appear. That's why also the filter is called anti-aliasing filter.
(If you are working just in the analoge world, such a filter is called reconstruction filter and is just meant to remove the periodics of the initial spectrum.)

PAL machines have 160 Ohm pull down resistors and a different output stage, compared to NTSC designs.
Also I never had a machine newer than 1Chip-02 PAL (late 1996) and especially no SNES Jr design.

Also NTSC consoles have 160ohms pull-down at the output. Nintendo has changed that to 150ohm for the the small factor designs.

In my case, the aliasing lines the Framemeister shows were happening with a prototype of Borti's board as well as when I swapped it over to Voultar's newest board.

I'm still curious why this is the case. I had a Framemeister at home a few weeks ago (I borrowed it) and could experience this behaviour. I used a modded PAL-1Chip at 50Hz and 60Hz.
I just want to mentioned that I changed the principle approach from the prototype to the current version from DC input to AC input. Voultars board uses DC input coupling.

The S-video output is driven by the SRGB encoder that's on board. Seeing that S-video is equally affected, It's safe to say that you just have something wonky going on with your Mini that's unrelated to your mod.

[...]

I would probably do a shotgun approach and replace caps and the linear regulator.

I'm happy to take a look.

+1
But I would not exclude the extremely unlikely case of a defective THS7374 which also effects its inputs in the same way (and so the S-RGB)

Please let us know your findings

Because I was surprised our NA community OCD nerds like retrorgb and FBX seemed largely unaware of this issue. Would be great if Voultar could get a PAL 1-chip to look at also!

I would be happy to send around my SNES to the USA to the visual and technical experts FBX RetroRGB and Voultar.

[FBX]

I would be happy to send around my SNES to the USA to the visual and technical experts FBX RetroRGB and Voultar.

Might want to nix my name in that list. I'm neither an expert, nor have the equipment to test with (which I sure includes a scope).

[borti4938]

You are the "visual" expert in this group
You have defenitely the best eyes in seeing minor differences between very similar mods aiming for good picture quality.

[RGB0b]

In my case, the aliasing lines the Framemeister shows were happening with a prototype of Borti's board as well as when I swapped it over to Voultar's newest board.

Both Leonk and I found that cables with the wrong resistor on the sync line can cause aliasing lines. I didn't believe it until I saw it with my own eyes...but it happened consistently on my OSSC with all mods (not just the 7374).

You are the "visual" expert in this group
You have defenitely the best eyes in seeing minor differences between very similar mods aiming for good picture quality.

Agreed!

Also Borti, thanks for the detailed responses, they were a big help!

[rama]

The resistor probably delays the sync signal slightly.
That delay might push the sampling into a region that's less prone to aliasing.

@borti4938
Working on my scaler, I found that you can get away with a different sampling clock.
As long as it's close enough, and I mean really close, it will work
Edit:
The reason is probably that all the sampling scalers are PLL locked to the hsync of the source.

[borti4938]

Working on my scaler, I found that you can get away with a different sampling clock.
As long as it's close enough, and I mean really close, it will work
Edit:
The reason is probably that all the sampling scalers are PLL locked to the hsync of the source.

"It will work" means that you don't see the aliasing in your testing image content. But this does not mean that it works with every image content due to the 'classic' aliasing (not only the non-matching folding of the periodics)!
And you totally forget about jitter, which performance varies from setup to setup.

Both Leonk and I found that cables with the wrong resistor on the sync line can cause aliasing lines. I didn't believe it until I saw it with my own eyes...but it happened consistently on my OSSC with all mods (not just the 7374).

Interesting; I missed that out. Maybe because all my consoles output sync for pure 75ohm termination with -300mV pulses. So I don't care about any resistors in my sync lines - I do have just a straight wire

[FBX]

Both Leonk and I found that cables with the wrong resistor on the sync line can cause aliasing lines. I didn't believe it until I saw it with my own eyes...but it happened consistently on my OSSC with all mods (not just the 7374).

Wow really? Maybe I can fix this issue then, as I have all the tools needed to mod my cable. What resistor rating would you say works the best with a modded mini and Voultar's board going into the Framemeister?

[Syntax]

It was my understanding that the Nintendo RGB mods pretty much delete all scart components.
Between my ntsc NES, SNES and N64 I use the same cable with 0 components.

Ossc on its way, give me a week or 2 and ill have a play.

[FBX]

It was my understanding that the Nintendo RGB mods pretty much delete all scart components.

With Voultar's board, I recall there being a jumper pad for TTL or attenuated sync, but I will crack the junior open tonight and double-check.

[RGB0b]

Both Leonk and I found that cables with the wrong resistor on the sync line can cause aliasing lines. I didn't believe it until I saw it with my own eyes...but it happened consistently on my OSSC with all mods (not just the 7374).

Wow really? Maybe I can fix this issue then, as I have all the tools needed to mod my cable. What resistor rating would you say works the best with a modded mini and Voultar's board going into the Framemeister?

I have Voultar's board set to TTL and a 33Ohm resistor in the cable...although between 300 and 450 should be fine. I think the issue was when sync went directly from the console to the OSSC, with no resistance at all. Maybe Leon can confirm on his end.

[rama]

I've taken pictures of oscilloscope readings from my 1Chip showing a 100% white screen.

One more measurement round.
Console is PAL 1Chip-01 with no modifications other than more Vcc bypassing, showing 100% white, probing just the red channel at several points:
- before 160 Ohm to ground
- after 160 Ohm, into the coupling capacitor
- after coupling capacitor (this is the S-RGB input now)
- at S-RGB red output

The result is that in all measurements, the waveform shows that distinct distortion on the left side.
I also tried increasing the capacitance of the coupling cap, and I tried lowering pulldown resistor Ohms.
The capacitor didn't make any difference, the pulldown resistor reduced the amplitude to half but still showing the distortion.

It's much harder to test series elements though, so no tests with series resistors yet.
I assume they would help with this particular problem though? Not sure.

It would be nice if we could find some kind of modification that eliminates this, that doesn't require lifting the AVcc pin.
This distortion is very much visible as dark bars on bright screens and it's the same thing that shows ghosting on some sprites / against some backgrounds.
I'd also like to keep using the onboard S-RGB, as it's normally a pretty okay chip. It does the job fine, it comes with the console and it produces a nice Composite Video image.

[Syntax]

I don't think there is much point doing these tests on an SNES with a stock 7805.

Every single Snes I've worked on displayed the white bar on composite untill I replaced the 7805 with a 2amp version.
Caps do fek all, and are a bandaid fix for this situation.

[rama]

Yeah, I ordered a couple 78S05 the other day. It could just be too little oomph when it counts!
Will test that out, once they arrive.

[Syntax]

Very interested to see the changes in waveform between the old regulator and a new one.

Ill send you one of these if you scope it for me too.

OKI-78SR-5/
http://au.rs-online.com/web/p/products/7962132/

[rama]

Thanks for the offer but I already know I don't want a switcher in a retro console.
I don't have a spectrum analyzer (nor the skills to use it correctly), so I couldn't even tell if I've filtered all the switching noise.
Most likely not ;p

[Syntax]

I felt the same but grabbed a couple when I had a chance out of curiosity.
They are supposed to be pretty clean units but its all hearsay.

[Voultar]

This disortion that you see is more likely caused by a component failing/oscillating +supply on the SNES mainboard, or even aged capacitors.

I'll be looking at a SNES that's having this trouble in the next day or so.

But as I was poking around at much earlier, this is more than likely a +supply issue. Of course that's just speculation and I won't know until it arrives, but the fact that it's occurring with the vast minority of systems suggests that it's more than likely a component which is in some state of failure. The linear supply should be investigated among other things on the output rail and everything in between. I seriously, seriously doubt that there's a "batch" of 1CHIP ASIC's that exclusively have this issue as this phenomenon is the very uncommon exception.

[syboxez]

Anyone that wants better quality then that should expect to pay an extremely high price for an EXPERT modder to do Borti's other mod, for a minimal quality difference. It is by no means a "standard procedure".

I don't consider myself an expert modder (only do it as a hobby for personal use), but I successfully did that mod with no problem. Lifting the pin does require precision, but I just used a craft knife and a thin tip on my iron. Routed a short wire to a pre-prepared SMD 20 Ohm resistor on one of the near 5v points (SNES Mini in my case).

I wouldn't recommend it to beginners or people who are worried about breaking their systems, but it is not exclusive to expert modders (unless I am an expert modder and I just don't know it ).

[FBX]

Lifting the pin does require precision, but I just used a craft knife and a thin tip on my iron.

Speaking of lifting pins, Voultar discovered the root of the awful checkerboarding issue on the SNES APU revisions. Turns out it is the trace from pin 3 on PPU2 coupling over into the RGB lines (reminiscent of the sub-carrier trace issue with early revision Sega Genesis consoles). I dug my APU SNES out of the closet to confirm on my end. In my case, I used a set of professional electronics tweezers and a conical tip on my soldering iron to lift the pin. Here's the before and after:

Spoiler

While much cleaner, it still doesn't hold a candle to the clarity of 1CHIP revisions.

[rama]

I see the same behaviour on my CPU-RGB-02 console.
It appears Nintendo engineers totally dropped the ball on the subcarrier line for 3 Chip consoles that use the S-RGB.
With the S-ENC encoder they used before, it was never so bad.
The affected console revisions are:
CPU-RGB-01 / 02, CPU-APU-01

So the question is this:
How can we fix the coupling while keeping the subcarrier intact?

[FBX]

So the question is this:
How can we fix the coupling while keeping the subcarrier intact?

Voultar suggested just rerouting the signal using a wire and drive it directly to its resistor.

[rama]

I've tried that. Took the signal directly off the lifted pin and routed it away from any distortions to its destination.
I removed that resistor and added my own, so the original trace was unused.
This helps with the problem, but it's not good enough. The pattern was still in the image, maybe 70% reduced.
With upscalers being what they are, this is still too annoying

We might want to get this solved now. There's a new OSSC firmware coming that offers a deblur filter.
It would be a pity if people couldn't use these consoles, due to some subcarrier leakage ;p
On that note, here's an idea.

If we assume that the problem is early coupling, still within the PPU2, then we don't want to use it for the subcarrier at all.
We would need a relatively noise-free termination for the subcarrier pin.
(Is leaving it floating good? Is there something better?)
On the S-RGB side, we could use the system oscillator and some kind of div by six solution.
21.473Mhz / 6 = ~3.597Mhz
I just hope something simple like that exists.

Oh, and one more:
There's a system clock output pin on every PPU2 that goes to the expansion port. It too couples into the analog video.
Lifting it is a good solution, unless someone wants to use a Satellaview.

[rama]

Yeah, I ordered a couple 78S05 the other day. It could just be too little oomph when it counts!
Will test that out, once they arrive.

Update:
The new regulator does nothing for the ghosting.
It does help with the Vcc noise floor but only a little. It is comparable to adding a good bypass capacitor to a stock machine.

[borti4938]

Speaking of lifting pins, Voultar discovered the root of the awful checkerboarding issue on the SNES APU revisions. Turns out it is the trace from pin 3 on PPU2 coupling over into the RGB lines (reminiscent of the sub-carrier trace issue with early revision Sega Genesis consoles). I dug my APU SNES out of the closet to confirm on my end. In my case, I used a set of professional electronics tweezers and a conical tip on my soldering iron to lift the pin. Here's the before and after:

Spoiler

While much cleaner, it still doesn't hold a candle to the clarity of 1CHIP revisions.

I did this approximately a year ago and it hasn't changed anything in my system. I removed R59 instead of lifting pin 3, which is much easier. (R59 is 4.7k resistor and close to Q1, Q2 and Q3 under PPU2).
My experience was the same as ramas these days: it was better but still there. So I put the SFC back into its place inside the cabinet.

After reading this, I give it another shot. This time I lifted pin 3 but it's still the same...
Has Voultar documented it somewhere? Have I missed something out?

So the question is this:
How can we fix the coupling while keeping the subcarrier intact?

Voultar suggested just rerouting the signal using a wire and drive it directly to its resistor.

Remove R4 (just a 0 ohm jumper; located under the S-RGB), remove R59 and reconnect the right pad of R59 over a 4.7kOhm resistor (one can use R59) to the right pad of the place where R4 was.

In that way you left out the whole trace in-between.

Just want to note: also the Composite Video output of the S-RGB runs all across of the mainboard and crosses the RGB lines two times: pin 15 to C18 (a big cap), then to R18 and finally to the MultiOut. But also rerouting this completely (or simply lift pin 15 of S-RGB) haven't vanished the checkered board pattern.

So my SNS-APU-01 stays inside the cabinet.

[paulb_nl]

Lifting pin 3 on my Super Famicom APU-01 removed the diagonal bars completely. However there is still other strange noise visible. It's easiest to see when using 256x240 optimized mode on the OSSC.

I also removed R54 under PPU2 which is the 5MHz pixel clock but that did nothing.

Here is a video of the noise: https://youtu.be/DluzvPtm3UQ

EDIT: After some more testing it seems the noise is caused by CPU or PPU activity. The 240p test suite displays a clear picture when idle but when pressing up or down on the menu the noise shows up for a moment.