Sharp analog RGB for the 3-Chip SNES using digital signals

[Opatus]

I've presoldered both the footprint and the board, then I've reflowed the pins. Tried it on 2 mainboards, did not have any issues. It's easier than it sounds. And as there's a really small gap between the mobo and the adapter you can see if there's a connection.
Lining up is also no big deal if you take your time and check the pins. The new version has the pads on the top side as well, maybe it helps.

If you have a better solution, I'm open to it.

[Harrumph]

Nice work!

[Opatus]

Here are some examples of the Mode 7 patch in action. And a bonus image of Air Strike Patrol's infamous shadow. I couldn't do a direct capture because I couldn't get decent quality out of my cheap capture device.

Spoiler

[yveltalgriffin]

I like your mounting solution a lot. For a hypothetical future HDMI mod, maybe a FPC interposer between the PPU2 and mainboard could streamline things. That would enable a low profile install and a built-in FFC for connecting to the retiming board.

[Opatus]

To be fair I took the idea from the UltraPIF and then improvised a bit. I thought about using an FPC but I had no experience with it, costs more to prototype and I was not sure if the whole project would succeed. So I've dropped it.

[Konsolkongen]

I think what you have achieved here is really great. The older model SNES consoles are useless IMO because of the worst RGB image of any system. The easy solution has always been to get a 1chip but they are getting harder and more expensive to track down.

Would something like this be possible on the Mega Drive too? Not that its RGB image is anywhere near as bad as the SNES, but there are faint jailbars and unfortunately none of the bypass solutions make any difference, at least not on the revisions I own.

[Maka8295]

I think what you have achieved here is really great. The older model SNES consoles are useless IMO because of the worst RGB image of any system. The easy solution has always been to get a 1chip but they are getting harder and more expensive to track down.

Would something like this be possible on the Mega Drive too? Not that its RGB image is anywhere near as bad as the SNES, but there are faint jailbars and unfortunately none of the bypass solutions make any difference, at least not on the revisions I own.

I feel like the 1chips get too much praise, sure they have a sharp picture, but you have to put up with ghosting, glitches, overblown whites, and the annoying black line that appears in a lot of games (as well as some other issues). The colours also look washed out without an RGB bypass or the resistor mod.

[Opatus]

I don't think it is possible on the Mega Drive. I have a VA4 PAL Mega Drive, where I also couldn't completely get rid of the noise. I thought about running the RGB through an ADC and snapping the digitized signal to the next valid color. If I remember correctly the Mega Drive has a 0-5V video signal coming out of the VDP and it's only 3bit per line. So it would give us about +-0.35V margin for each color step. Which is plenty. If we wanted to go overboard we could compare the results again the CRAM to get a more precise result. But it would probably not be necessarily.

And if we are already using an FPGA for that we could correct the horribly timed Csync as well.

[Konsolkongen]

I feel like the 1chips get too much praise, sure they have a sharp picture, but you have to put up with ghosting, glitches, overblown whites, and the annoying black line that appears in a lot of games (as well as some other issues). The colours also look washed out without an RGB bypass or the resistor mod.

Could you point me towards an example of that black line you mention. Not sure I’m aware of that issue. As for the ghosting and blown out colors these issues are easily fixed with a few cheap components. As is the jailbar right down the middle that’s visible on dark screens.
I don’t understand the need to bypass RGB on this system either as you can get pretty perfect results with the stock hardware. Unless I’ve missed something when playing, like that black line you mention

[Kez]

Could you point me towards an example of that black line you mention.

Street Fighter 2 Turbo is the example that springs to mind, there is a black line right at the top of the screen that runs partway across. The C11 ghosting fix changes the length of the line.

EDIT: Here's a post about it

[Maka8295]

I feel like the 1chips get too much praise, sure they have a sharp picture, but you have to put up with ghosting, glitches, overblown whites, and the annoying black line that appears in a lot of games (as well as some other issues). The colours also look washed out without an RGB bypass or the resistor mod.

Could you point me towards an example of that black line you mention. Not sure I’m aware of that issue. As for the ghosting and blown out colors these issues are easily fixed with a few cheap components. As is the jailbar right down the middle that’s visible on dark screens.
I don’t understand the need to bypass RGB on this system either as you can get pretty perfect results with the stock hardware. Unless I’ve missed something when playing, like that black line you mention

Heres a good article talking about the black line (https://retromods.game.blog/snes-sfc/sn ... sting-fix/)

Some games I've noticed that have the black line:

Link to the past (when opening the item menu or transitioning worlds)
Chrono Trigger (when opening the menu, this one is pretty minor)
Mario Collection Mario 3 (Just above the HUD info thing and on the top of the screen during water levels when pausing the game)
Yoshi's Island (2 lines of pixels are missing from the top of the screen, with a third line very dim with the C11 fix, its just a single faded line of pixels without)
Front Mission Gun Hazard (same as yoshi's island except it actually partially covers some important HUD info)
Tactics Ogre (Top line of pixels on the HUD flickers even without C11, I imagine this one could be very problematic with the C11 fix as its right above some important info and appears right in the middle of the screen.)
Super Gameboy (top line of pixels flickers pretty badly, but you can just set the border to black to get rid of it)
Street fighter (as someone else has mentioned)

But the most annoying problem I've had, is a weird sort of interference that 1chips seem to have that I've never seen anyone else talk about, bright colours leave a trail on dark backgrounds (different ghosting) and theres a strange flickery noise outside the game window which sometimes encroaches into the game screen itself. Luckily the OSSC can fix all of it except for the trails. All 3 of my 1chips have this problem and none of my 3/2 chips have it.

[Konsolkongen]

I don't think it is possible on the Mega Drive. I have a VA4 PAL Mega Drive, where I also couldn't completely get rid of the noise. I thought about running the RGB through an ADC and snapping the digitized signal to the next valid color. If I remember correctly the Mega Drive has a 0-5V video signal coming out of the VDP and it's only 3bit per line. So it would give us about +-0.35V margin for each color step. Which is plenty. If we wanted to go overboard we could compare the results again the CRAM to get a more precise result. But it would probably not be necessarily.

And if we are already using an FPGA for that we could correct the horribly timed Csync as well.

Doesn't sound that complicated. Not sure about the 0-5V but it seems logical. I can check on mine if you'd like. Would be really great if it could be solved eventually

Kez & Maka8295>

Thank you. I remember that black line now. It's annoying but I'd take that over the ghosting any day :/

[yoshiyukiblade]

Amazing results! So it looks like the known issues, discussed in this thread so far, were resolved. Let's hope that there aren't any more nasty surprises lurking around.

[paulb_nl]

But the most annoying problem I've had, is a weird sort of interference that 1chips seem to have that I've never seen anyone else talk about, bright colours leave a trail on dark backgrounds (different ghosting) and theres a strange flickery noise outside the game window which sometimes encroaches into the game screen itself. Luckily the OSSC can fix all of it except for the trails. All 3 of my 1chips have this problem and none of my 3/2 chips have it.

It sounds like a problem with your OSSC instead of the 1-CHIPs. I have not seen those issues with my three 1-CHIPs and SNES jr.

An increased brightness outside of the game window usually indicates a defective OSSC unless there is something wrong with your RGB cable.

[Unseen]

Would something like this be possible on the Mega Drive too?

IIRC: The graphics chip in the Mega Drive 1 has an unused port that can output the palette index of the current pixel that could be used to create a high-quality reconstruction of the output image. However, that port must be enabled in software first and tracking the current palette to convert that index to a color is a bit complicated because the palette can be manipulated using DMA.

[Opatus]

Amazing results! So it looks like the known issues, discussed in this thread so far, were resolved. Let's hope that there aren't any more nasty surprises lurking around.

I'm sure there will be surprises, there always are. Did you make your board with the simple DAC that you were planning?

[yoshiyukiblade]

Yeah, I designed the board and had it made a couple months ago, but decided not to install it for now. The thought of hand soldering 15 tiny wires was rather intimidating! This was before I thought about designing an adapter board like your prototypes. I think I'll "finish" the analog RLPF project first before playing around with digital stuff more.

I want to see if it's possible to eliminate the high frequency ripple seen in the analog signal by feeding all the PPU2 VCC pins with a low noise source. If not, I think it's safe to assume that all that ripple is generated inside the PPU itself or the data inputs are contributing significant amounts of interference seen at the output.

[mikejmoffitt]

This mod looks great, I look forward to the final results.

As for the DAC: I recommend the ADV7123, as it is a 10-bit parallel DAC - double what you need. So, it's trivial to see how you'd double up bits without introducing a tiny disturbance in the ramp. Same pinout, just some N/C pins become additional LSBs.

Regarding Megadrive: A similar thing is possible, but the VDP only outputs digitally the pixel data, palette index, and bg/spr select. Those are intended to form the lookup address within external Color RAM. In that mode, the internal CRAM is disabled. This is how the System C/C2 works. In a sense, this is similar to how NESRGB works.

Unfortunately, making a Megadrive solution would necessitate snooping all writes to the internal color RAM, which is done through the VDP. The easiest ones would be simple port read/writes, but most games use DMA to transfer palette lines much faster. To snoop those would require a much tighter understanding and implementation of the MD VDP's DMA timings, which are influenced by its internal state heavily. That is the part that makes that mod seem too challenging.

[paulb_nl]

As for the DAC: I recommend the ADV7123, as it is a 10-bit parallel DAC - double what you need. So, it's trivial to see how you'd double up bits without introducing a tiny disturbance in the ramp. Same pinout, just some N/C pins become additional LSBs.

The SNES has a 4 bit brightness level and 5 bits per color so 9 bits are needed to show all possible colors.

[Opatus]

@yoshiyukiblade
Too bad, I wanted to see someone's results as well.
I don't think the high frequencies are coming from the PPU, you're introducing a lot of really high frequencies with that slew rate boost on the video signal. Maybe you could try an even faster opamp, but I don't know.

@mikejmoffitt
I already use the ADV7123, because as paulb_nl said I have almost 9 full bits of video per channel. If I've calculated everything correctly, I have a 0.7V linear output. But I didn't check it, first I was more interested in the bigger picture, namely the Mode 7 patch.

I will experiment with the Mega Drive, when I find the time for it. But first I have still plans for this SNES mod.

[6t8k]

That's great progress.

With an FPC connection between the original PPU2 footprint and the mod board, it may be possible to fit the mod board somewhere else in case this becomes a concern with different main board versions, or a new connector needs to be incorporated into the side of the casing. But I also really like your current solution.

[maxtherabbit]

As apprehensive as I am about lining up the QFP adapter board, I imagine it makes for an excellent mounting platform, mechanically.

[qjkxbmwvz]

As for the DAC: I recommend the ADV7123, as it is a 10-bit parallel DAC - double what you need. So, it's trivial to see how you'd double up bits without introducing a tiny disturbance in the ramp. Same pinout, just some N/C pins become additional LSBs.

The SNES has a 4 bit brightness level and 5 bits per color so 9 bits are needed to show all possible colors.

Does the real SNES actually have 512 brightness levels per channel? If you were to set the minimal 15-bit color (1,1,1) and then vary the brightness bits, would there actually be fourteen different shades between min RGB @ max brightness and black?

[yoshiyukiblade]

If I understood it correctly, stock DAC outputs the 5-bit steps (though technically it's continuous because it's analog), and the brightness register alters the voltage reference independently, attenuating the brightness like a digital volume knob. So for each step in the 5-bit output, there are 16 steps of brightness they can take.

There are some overlapping/redundant values though. Like if the brightness level is zero, any 5-bit output is zero. And if the 5-bit output is zero, any brightness value also yields zero.

[paulb_nl]

Does the real SNES actually have 512 brightness levels per channel? If you were to set the minimal 15-bit color (1,1,1) and then vary the brightness bits, would there actually be fourteen different shades between min RGB @ max brightness and black?

Well in theory yes but color(1,1,1) should be around 22mV and once you go into noise floor levels then it is difficult to measure.

This post with measurements on nesdev mentions there is about 7-12mV of noise on his SNES. Also brightness level 0 seems to be just above 0mV with color 31,31,31.

[Opatus]

This post with measurements on nesdev mentions there is about 7-12mV of noise on his SNES. Also brightness level 0 seems to be just above 0mV with color 31,31,31.

This is interesting. As of right now, I just use the brightness register linearly, but I may think about making it non-linear. Even if the non-linearity is probably not noticeable at all.

[ikari_01]

FWIW I took some measurements of my PPU2 analog outputs back when tinkering around with the TST pins:
https://drive.google.com/drive/folders/ ... sp=sharing

Congratulations on the OVER pullup discovery, that had been pretty much the show stopper for Unseen and me back then.

I'm curious what the output of this ROM looks like with your mod, especially with the "OVER2" test ROM:
https://sd2snes.de/files/misc/sppu-digi ... essdemo.7z
It is a Mode 7 test written by krom that shows a checkerboard on a plane with some color math and sprite priority variations.
You can move around the checkerboard using the D-pad.

I have prepared "OVER0", "OVER2", and "OVER3" ROMs which correspond to the values of the OVER bits in register $211a (bits 7+6).
OVER0 repeats the checkerboard over and over, OVER2 shows a single board over the backdrop, and OVER3 repeats tile 0 around the checkerboard (so there is a single board on an infinite plane).
I don't expect any trouble with OVER0 and OVER3. Here's a reference shot for OVER2:

[Opatus]

Unfortunately I don't have a flash cart, so I cannot run it. But some people were interested in the mod and they wanted to try it. They should have their boards ready in about 2 weeks. I think at least one of them will have a cart and hopefully they can test it.
I assume that it will work fine, but confirmation is needed. The way I do the Mode 7 now is making the PPU2 think it has still not left the active area by pulling the OVER signal high and injecting Color #0 from the VRAM. So the priority and color math should not be effected.

It's good to see that the signal from the PPU2 directly is fairly linear and the non-lineraity comes from the transistors on the motherboard.
And I also like to see the peak voltage of the video signal being 2.43V. My board has 2 options (technically 4) to route the RGB. One is a direct RGB output that has to be connected to the Multiout. The other is using the amplifier from the motherboard to clean up compostie and S-Video. For that I've calculated my amplifiers to generate 2.5V, I didn't have a pure white image to measure it and after a quick measurement 2.5V seemed reasonable.

[Opatus]

I bought an SD2SNES during Black Friday, which has finally arrived (thank you ikari_01 for creating it).
So I had the chance to try the chess table and as I have expected seems to be fine.

Here is a video and an image:

https://youtu.be/n3JoIReIQJw



Please note that there is some color inaccuracy and blurriness. I rewired my SNES to use the original video encoder but this way the green line picks up some noise from the blue digital lines, causing some problems.
I ran out of space on my mod board and the green line had to be routed directly under the video DAC.

[gordon-creAtive]

Are you guys aware of the RGBtoHDMI project? Could this help with an HDMI output?