Let's talk SNES HDMI (analog based)

[Woozle]

The SNES is one of my favorite consoles and it would be great if an HDMI mod existed for it. From my understanding a pure-digital solution would be very difficult due to the lack of easy to capture digital RGB signals on the board.

A while back I made a board with three flash ADCs (ADC08100) and a sync stripper on it. I had hoped to make a low-level RGB video scaler which never really panned out. The lack of a PLL made for jittery-video. I think it would work a lot better with a specific console like the SNES due to being able to grab clock timing info from the SNES board.



While not as good as a pure digital solution, I think it would be a fun learning experience and would lead to sharp video from the SNES for those willing to experiment.

Here's a picture of the SNES running through the ADC board to an FPGA (full frame-buffer) and output over HDMI. It has some serious issues, for starters I was using a sample clock generated by FPGA which is clearly out of phase with the pixel data and causes the pixel shifting. The other issue is the layer of noise (seems to be on red channel) over the image.

http://imgur.com/KCz4M5h

The first issue should be fixable by either a) using the SNES oscillator as input to FPGA and obtain a pixel clock using the FPGA's PLL, or b) finding a pixel clock line on the SNES motherboard itself.

As for the second issue, I'm thinking a video filter at the ADC input would help a lot...alternatively I could have messed up the ADC input circuit.

I was hoping to get some input on choice of video filter and the best place to grab analog RGB internally from a SNES mini plus the pixel clock. I plan to shrink down the ADC board and output digital video using an FFC/FPC connector so it can be easily hooked up to an FPGA scaler board. After that I'll try line doubling with my spartan 6 lx9 board, it has enough room for a line buffer at least. Otherwise the Artix7 XC7A35T has enough BRAM for a frame buffer based design.

Here's a link to the ADC PCB on oshpark.
https://oshpark.com/shared_projects/YvYZRQlt


Combined FPGA + ADC board, still needs to be tested/verified. I don't recommend ordering a board until I've built one and gotten it tested, but it's up for those who are curious https://oshpark.com/projects/0Jm7hIjr

[mikejmoffitt]

I've been playing with an idea like this. Absolutely - clocking the sampling by the pixel clock on the system (or the master clock, or any division thereof) would completely get rid of jitter. I've wanted to make system-specific line doublers this way. If you're sampling at the right position, I think it can be done without any serious filtration.

[Woozle]

Maybe it would be best to remove the SNES oscillator and clock it with the fpga? That way the fpga and SNES start with a known timing relationship.

Another question, for the ADCs, should video be AC or DC coupled? Right now I'm doing AC coupled (I think), it's a series capacitor at the board input with a 75ohm resistor to ground at the ADC input.

Any opinions on ADC choice? Flash ADCs seem pricey, but necessary for this application.

[paulb_nl]

If done correctly I doubt you would see a difference with a pure digital solution. Just do not use a framebuffer, only buffer the lines you need to adjust to the HDMI timings.

For a higher compatibility with TVs you need to generate a slightly slower SNES clock so it outputs at 60.00hz instead of 60.09hz like Kevtris has done with the Hi-def NES.

Here is more information about SNES timings. http://problemkaputt.de/fullsnes.htm#sn ... scillators

[Woozle]

As long as the fpga has enough bram, both frame and line buffer modes could be supported.

Wouldn't a frame buffer be necessary for 4x scale/1080p?

Thanks for the SNES timing link!

[paulb_nl]

Kevtris has done 4x and 4.5x scaling without a framebuffer. You need to buffer about 19 lines and 12 lines respectively if my calculations are correct.

[mikejmoffitt]

A line multiplier (like Kevtris's), and a slightly modified master clock can allow for low-latency output without a framebuffer, so that would be the best way to go. The FPGA won't have enough BRAM for a whole framebuffer probably (and the nearly requisite secondary buffer), though external RAM can make it happen at the expense of... well, cost.

If you're going the ADC route, this will work a lot better on the 1CHIP consoles with the stock RGB output path.

[Woozle]

Thanks for the input.

All I have is a SNES mini, can I just use the rgb signals which the ths7314 mods tap into? or should I buffer them with a ths7374?

[RGB32E]

For a higher compatibility with TVs you need to generate a slightly slower SNES clock so it outputs at 60.00hz instead of 60.09hz like Kevtris has done with the Hi-def NES.

Speaking of which, I wonder if the OSSC can be easily modified to provide a master clock for a given console? That would make the OSSC compatible with nearly all displays!

[Woozle]

I would think the main issue would be the wire length for the clock line from OSSC. Otherwise it's just using a spare fpga I/O to pass a clock signal to the SNES clock input.

[RGB32E]

Would there not be the option to create a clock driving circuit, and carry the signal over mini coax, or a STP? I also came across a clock generator on Adafruit for ($8):

https://www.adafruit.com/products/2045



User micro made something similar, but the Adafruit item is preassembled, but requires a device (Arduino) to program it, and it's unknown to me whether or not it can generate a close enough clock for the SNES and other consoles/arcade boards.

[atheistgod1999]

For a higher compatibility with TVs you need to generate a slightly slower SNES clock so it outputs at 60.00hz instead of 60.09hz like Kevtris has done with the Hi-def NES.

Wait: NES HDMI slows down the NES? That makes everything inaccurate!

[Woozle]

Why not just send the clock from the fpga? What benefit does that clock generator provide?

[RGB32E]

Just stating an alternative to using an FPGA, as you suggested that there can be cabling issues with high frequency clock signals.

[RGB32E]

For a higher compatibility with TVs you need to generate a slightly slower SNES clock so it outputs at 60.00hz instead of 60.09hz like Kevtris has done with the Hi-def NES.

Wait: NES HDMI slows down the NES? That makes everything inaccurate!

So does the AVS.... ZOMG!!!! Or anything that is frame bufferless/no scan conversion!

[atheistgod1999]

So does the AVS.... ZOMG!!!! Or anything that is frame bufferless/no scan conversion!

Except for a legit, non-HDMI modded NTSC NES or Famicom. Even a slightly lower refresh rate means easier gameplay, so the Yellow Devil, for instance, will be a teensy bit easier on the AVS or an HDMI-modded NES than an unmodded (or just RGB modded) NTSC NES. I don't want people in the future saying they beat the Yellow Devil, when if they were playing on the real deal they wouldn't have been able to do it.
Yes, I'm probably overreacting, but still.

[Woozle]

Changing the console speed to match HDMI or changing the HDMI timing to match the console both have drawbacks. If I'm making something for myself I would probably modify the HDMI timing if it'll work with my displays, but if it's for others then display compatibility takes priority over authentic game speed imo.

A good idea imo is to have it be different modes. One with standard HDMI timing and one with HDMI timing matched with the console, let the user choose if they want to go off standard.

[RGB32E]

A good idea imo is to have it be different modes. One with standard HDMI timing and one with HDMI timing matched with the console, let the user choose if they want to go off standard.

This is what the Nintendo 64 UltraHDMI kit allows for, and also includes a frame buffer (<16ms lag max). Original timing is 480p only ("Direct+Sync").

[Woozle]

I updated the ADC board. It has three ADC08100 flash ADCs and an LMH1980 sync separator, size is 2.3"x1.2" and uses 0402 resistors/capacitors. I still need to physically verify that it works, just waiting on oshpark to make it.

It converts analog RGB + sync into 24-bit digital RGB + hsync/vsync. It passes the SNES clock to the FPGA (or from FPGA to SNES) and the FPGA will generate a sample clock for the ADCs.

I need to update a spartan6 HDMI pcb I made to accept the FFC pinout, but I'll wait to do that until after midterms/finals.

https://oshpark.com/shared_projects/YvYZRQlt

[atheistgod1999]

Considering how the Analogue NT Mini uses an FPGA, I wonder if we could convince Analogue to add a switch that sets the clock speed so both sides can be happy. I mean, unlike the AVS, it hasn't been released yet, and I doubt they really started mass producing them yet.

[Woozle]

https://imgur.com/a/Gb7AR

https://imgur.com/a/ppdY6

I soldered a wire to pin 1 of the SNES cartridge connector which is a 21mhz clock signal. Dividing it by 4 in the fpga gave me a proper pixel clock to sample with. It removed the jitter from before, but the image is still noisy. The squashed image is due to my monitor not liking 720x480.

I just realized that I'm sampling DC coupled video...would the noise I'm seeing be due to a DC offset? The new ADC board will have input capacitors, similar to most video input circuits I've seen.

It stutters like crazy but that can be fixed with timing tweaks, right now I want to focus on getting low-noise video to the screen.

[Guspaz]

Wouldn't that approach have problems when the SNES switches output resolutions to 480i?

[Woozle]

What popular games use it? I don't have many SNES games but if I have a 480i one I can see what happens.

[Guspaz]

Actually the problem is worse than that: highres and interlaced modes are separate, so a game could output 512x224, or 256x448, or 512x448. Some games would switch on and off highres mode within the same frame: example, one of the Secret of Mana games used highres mode for character dialog boxes, but not the rest of the screen.

For example, see this screenshot from Secret of Mana 2 (well, a translation of it anyhow, the original does the same thing):

http://lparchive.org/Seiken-Densetsu-3- ... torage.jpg

The text is at a different resolution than the rest of the image.

Secret of Mana 1 still used it for a few screens, but I don't think the text boxes? I'm not sure.

RPM Racing was a 480i game, I think.

[Woozle]

Hmm...I would think since I'm sampling at a fixed rate that any higher detail horizontal information would just be missed during the sampling process. I'll definitely look into it.

My local game store sells repros/translations. I'll go by tomorrow and see if I can get a copy of secret of mana 2 for testing.

[Woozle]

Made an FPGA pcb that should be able to hook up to the ADC board and handle the line doubling plus HDMI output.

For my testing, the ADC board will go under the SNES mini motherboard and feed digital video data over a flex connector to this hdmi pcb which will be outside the SNES shell.

https://oshpark.com/shared_projects/wkyHd6VN

[paulb_nl]

https://imgur.com/a/Gb7AR

https://imgur.com/a/ppdY6

I soldered a wire to pin 1 of the SNES cartridge connector which is a 21mhz clock signal. Dividing it by 4 in the fpga gave me a proper pixel clock to sample with. It removed the jitter from before, but the image is still noisy. The squashed image is due to my monitor not liking 720x480.

I just realized that I'm sampling DC coupled video...would the noise I'm seeing be due to a DC offset? The new ADC board will have input capacitors, similar to most video input circuits I've seen.

It stutters like crazy but that can be fixed with timing tweaks, right now I want to focus on getting low-noise video to the screen.

Looking good. What kind of noise are you seeing? I assume the lines in the photos are caused by the camera.

From what I've read the DC offset from the NTSC SNES is normally removed by the 220uf caps on the RGB wires.

That 512 high res mode is just for bonus points I haven't been able to find how it can output 512 pixels when the PPU is only outputting 341 dots.

[Woozle]

The noise is consistent across the whole image, almost like a very dense Gaussian noise.

I think the noise is related to me powering the ADCs from the FPGA's pmod 3.3v. I switched over to my linear bench supply and the noise is gone at first but then builds up gradually over time.

Any lines in the active image data is from my camera.

I'm surprised it works considering the clock line is going across almost 8" of wire.

I'm thinking this could possibly work in a Hanzo/toro kind of way. The ADC/fpga pcb could be put in a small enclosure with a fixed short SNES RGB cable attached to it. It would require the SNES clock line to be connected to a pin on the multi-out, the cable would ideally be one of those individually shielded conductor cables from retro console accessories.

That way installation is just wiring RGB, csync, and a clock to the multi-out and then this device can be plug n play.

[RGB32E]

I'm thinking this could possibly work in a Hanzo/toro kind of way. The ADC/fpga pcb could be put in a small enclosure with a fixed short SNES RGB cable attached to it. It would require the SNES clock line to be connected to a pin on the multi-out, the cable would ideally be one of those individually shielded conductor cables from retro console accessories.

That way installation is just wiring RGB, csync, and a clock to the multi-out and then this device can be plug n play.

This would be welcome as well:
1. Consolidating the two PCBs into one
2. Internal installation with mini HDMI output so that only a notch in the bottom part of the case could be made (e.g. UltraHDMI)
3. Ability to reclock the SNES for standard timing
4. >480p/line doubled output. 1080p 5x5 scale is a desired feature for any of the HDMI mods
5. Frame buffer
6. Integration of I2S digital audio (resampling DSP option)
7. OSD / controller polling

The list goes on!

[Woozle]

All of those sound great. I would like to ideally consolidate the ADCs and FPGA on board with an HDMI Tx IC. Controller polling is easy since I already have it working on Spartan 6 for my GBA project....OSD will be challenge.

I would also like to integrate the filter circuit from the snes RGB mods, so that it isn't required to first mod it for rgb and then for the FPGA board.

Reclocking the SNES can be supported right now, I just need to desolder the SNES crystal and change my FPGA to output a clock instead of receive one. But it's my childhood SNES and I've already done enough crap to it Once I get this other SNES mini (bought "broken" from ebay, just needs power jack) ready for RGB I'll remove the clock on it.

The FPGA which can do a frame buffer is a BGA part..I have an ok reflow convection oven based on the controleo2, maybe that could work for testing out a BGA board design.

Integrating audio over HDMI is something I'll look into, I just don't really know how that works at the moment (audio sampling chip, I2S, putting it in HDMI data). Is there a way to get pure digital audio from snes?

Once I get a single board solution working in basic form on the SNES, I'll see how it works in the ps1, genesis, saturn and other consoles which I don't really recall hearing about pure-digital HDMI solutions.