HDMI SNES?

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
getafixx
Posts: 372
Joined: Tue Dec 04, 2012 3:28 pm
Location: Canada

HDMI SNES?

Post by getafixx » Mon Oct 05, 2015 5:57 pm

Seeing as the mighty Kevtris and bunnyboy have made amazing NES HDMI adapters (well, bunny's is a complete system), is there any hope for a SNES equivalent? There is even an N64 adapter in the works.

Being that the SNES uses the APU, is that the main reason we haven't seen any work on an HDMI mod for SNES?

lidnariq
Posts: 10273
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: HDMI SNES?

Post by lidnariq » Mon Oct 05, 2015 6:11 pm

The SNES's video is generated in analog on-die, so unfortunately getting HDMI out requires ADCs or emulating parts of the PPU. Actually, hooking up the SNES's APU is the easiest part because it actually emits something that looks like I²S, the only problem is that it's at a nonstandard clock rate (≈32040 Hz).

The N64 natively emits 21-bit digital YCrCb, and the NES HDMI adapter takes advantage of that the the PPU can be tricked into emitting the 5-bit pre-CLUT color value.

Great Hierophant
Posts: 769
Joined: Tue Nov 23, 2004 9:35 pm

Re: HDMI SNES?

Post by Great Hierophant » Mon Oct 05, 2015 7:00 pm

lidnariq wrote:The SNES's video is generated in analog on-die, so unfortunately getting HDMI out requires ADCs or emulating parts of the PPU. Actually, hooking up the SNES's APU is the easiest part because it actually emits something that looks like I²S, the only problem is that it's at a nonstandard clock rate (≈32040 Hz).

The N64 natively emits 21-bit digital YCrCb, and the NES HDMI adapter takes advantage of that the the PPU can be tricked into emitting the 5-bit pre-CLUT color value.
I believe that 32,000 Hz is a standard sample rate, wouldn't one solution be to slow down the clock rate slightly to a more compatible rate?

Also, how much lag would be introduced with a ADC designed for SNES analog on-die video? Is it possible to digitize the color and upscale the graphics to HDMI resolutions with only introducing Hi Def NES latency? Of course, things may be complicated because the SNES has six standard resolutions instead of one for the NES.

lidnariq
Posts: 10273
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: HDMI SNES?

Post by lidnariq » Mon Oct 05, 2015 7:10 pm

Yup. Replacing the 24.576MHz ceramic resonator used by the SNES's APU with the same frequency of crystal (plus ballast capacitors) is all that's necessary. (The ceramic resonators are both lower precision and, for some reason, tend to drift fast in the SNES).

And similarly, a VGA-input equipped LCD computer monitor already has a set of ADCs that are fast enough for this. (My monitor can even directly parse the SNES's output, if only the SNES didn't change the width of some scanlines.)

The only tricky thing would be dealing with the SNES's interlaced modes. I'd personally choose to ignore them; nocash says it's only five games that use it.

User avatar
mikejmoffitt
Posts: 1352
Joined: Sun May 27, 2012 8:43 pm

Re: HDMI SNES?

Post by mikejmoffitt » Mon Oct 05, 2015 7:14 pm

Are we sure that no signals going between PPU1 and PPU2 are suitable for snooping with the intent of capture? How about snooping VRAM reads as it pulls tile data for the next line?

lidnariq
Posts: 10273
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: HDMI SNES?

Post by lidnariq » Mon Oct 05, 2015 7:15 pm

Oh, sure, but that'd have more in common with snooping the NES's PPU's bus activity. It certainly gets us, I dunno, maybe 80% of the way there, but there's all the other bits in the way.
Great Hierophant wrote:Also, how much lag would be introduced with a ADC designed for SNES analog on-die video? Is it possible to digitize the color and upscale the graphics to HDMI resolutions with only introducing Hi Def NES latency?
Oh, I failed to directly answer this. The amount of latency that would be involved here is trivial; typical high speed ADCs have 3 samples of latency, so the simplest naïve implementation could easily produce a letterboxed output with just 1-2 scanlines of latency on the emitter side.

Adding something like kevtris's HDNES circular buffer to scale it vertically to be full frame adds a little latency, but it's still less than 1 vsync's worth (16ms) .

User avatar
mikejmoffitt
Posts: 1352
Joined: Sun May 27, 2012 8:43 pm

Re: HDMI SNES?

Post by mikejmoffitt » Mon Oct 05, 2015 7:30 pm

lidnariq wrote:Oh, sure, but that'd have more in common with snooping the NES's PPU's bus activity. It certainly gets us, I dunno, maybe 80% of the way there, but there's all the other bits in the way.
I was focusing more on the inter-PPU communication; a good chunk of them in the center have something to do with palette line selection (probing around shorting them out demonstrates this a little, for a lack of better tools).

Digitizing with an ADC can turn out very well IF the ADC is clocked to some multiple of the PPU's pixel clock. Once you have digital RGB from that process, line doubling is line doubling, so it can be done as laglessly as the NES HDMI project.

User avatar
marvelus10
Posts: 243
Joined: Fri Feb 09, 2007 5:01 pm
Location: Nanaimo, BC Canada

Re: HDMI SNES?

Post by marvelus10 » Mon Oct 05, 2015 10:01 pm

Would it be easier or harder if you were to use a 1-chip SNES?

tepples
Posts: 22288
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: HDMI SNES?

Post by tepples » Tue Oct 06, 2015 6:58 am

lidnariq wrote:The only tricky thing would be dealing with the SNES's interlaced modes. I'd personally choose to ignore them; nocash says it's only five games that use it.
I've vowed to use interlace if I ever make a mode 7 game because it's essentially free extra vertical sample resolution, plus it should in theory improve compatibility with newer TVs.

User avatar
getafixx
Posts: 372
Joined: Tue Dec 04, 2012 3:28 pm
Location: Canada

Re: HDMI SNES?

Post by getafixx » Tue Oct 06, 2015 1:44 pm

marvelus10 wrote:Would it be easier or harder if you were to use a 1-chip SNES?
I've wondered that as well. If spying on the PPU is all that is needed, would it make it harder to do so in the 1Chip version? I kind of assume it wouldn't be easier.

tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

Re: HDMI SNES?

Post by tomaitheous » Wed Oct 07, 2015 8:46 pm

tepples wrote:
lidnariq wrote:The only tricky thing would be dealing with the SNES's interlaced modes. I'd personally choose to ignore them; nocash says it's only five games that use it.
I've vowed to use interlace if I ever make a mode 7 game because it's essentially free extra vertical sample resolution, plus it should in theory improve compatibility with newer TVs.
I had an HDTV that refused to show any color information over svideo from my snes. Yet the sdtv crt showed it fine (as well as the capture card). I also heard that the snes interlace mode isn't exactly to spec either.
__________________________
http://pcedev.wordpress.com

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: HDMI SNES?

Post by jwdonal » Sun Oct 25, 2015 1:28 am

lidnariq wrote:...the only problem is that it's at a nonstandard clock rate (≈32040 Hz).
How are you coming to that conclusion? Because some random person(s) measured the clocks on their particular SNES and it wasn't exactly 32kHz? So what? I bet if I measured the output sample rate on my SNES it wouldn't be _precisely_ 32kHz either. One person's SNES APU output might be a little slower than 32kHz and another's might be a little faster. Again so what? None of that means it wasn't intended to be 32kHz by the original designers.

If I measure this 50Mhz oscillator I've got on my FPGA board here I can guarantee you it's not going to measure as exactly 50MHz on my scope. A huge number of factors come into play when measuring clock frequency:

Scope calibration
Scope probe impedance
Accuracy (ppm) of the oscillator
Quality of the oscillator
How many times is the input oscillator frequency being divided down before the point at which the measurement is taken?
How much is the input oscillator being divided down before the point at which the measurement is taken?
What method is being used to divide the input oscillator down before the point at which the measurement is taken?
blah blah blah
...the list goes on and on. In my 20+ years of computer engineering and fpga design I've never seen a single oscillator output a precisely perfect frequency. But no one cares. That's life.

And it would make sense for Nintendo to use cheaper oscillators since they were mass producing these consoles; even if they could save just a couple cents per oscillator at the sacrifice of a little accuracy you're talking close to a $1M in savings over the life of the console. I'm willing to bet the range of the 24.576MHz master input oscillator frequency is pretty large.

Update: Actually, in Anomie's apudsp.txt we have: "Note that this clock has been indirectly observed to vary, with rates of anywhere from 24592800 Hz to 24645600 Hz."
Whoa, hang on, looks like we've got an output sample rate of 32021.875Hz (24592800/768)! Sweet, now we know the _real_ frequency that Nintendo meant to use! Or wait...is it 32090.625Hz (24645600/768)? Or is it... Hey, what kind of super secret weird stuff is Nintendo up to now?!

These consoles don't need atomic clock levels of accuracy. Lol. No user is going to hear/see/feel the difference of a few Hz. The better question is: What was the most obvious _intended_ output sample frequency for the design? Does it make more sense that they intended some weird silly frequency of 32021.875Hz? Or does it make more sense that they intended it to be the standard 32kHz audio sample rate that the entire audio industry and the programmer's using it would be familiar with (within some reasonable tolerance to save money)? The answer is obvious.

tepples
Posts: 22288
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: HDMI SNES?

Post by tepples » Sun Oct 25, 2015 9:11 am

jwdonal wrote:These consoles don't need atomic clock levels of accuracy. Lol. No user is going to hear/see/feel the difference of a few Hz.
Unless you're trying to resample the audio to a rate that has a fixed ratio with the video rate in order to multiplex the S-DSP's I²S output with the video output. Then you'll end up having to generate the audio clock and the video clock from the same oscillator. Or will an HDMI sink correctly play audio at a varying rate of 32020-32090 or 48030-48135 Hz?

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: HDMI SNES?

Post by jwdonal » Sun Oct 25, 2015 1:46 pm

tepples wrote:Or will an HDMI sink correctly play audio at a varying rate of 32020-32090 or 48030-48135 Hz?
I'm not sure specifically what you meant by that question but just to clarify for everyone, the variation in frequency would be from console to console (i.e. from oscillator to oscillator), not within a single console (i.e. single oscillator). It is highly unlikely that the frequency would modulate that much (i.e. 70Hz) within a single oscillator unless there was some power supply issue.

In any case, the best way to resample the S-DSP's serial audio output stream would be to have a source-synchronous design in which the HDMI SNES adapter board tapped into each console's own 24.576Mhz audio source oscillator and hooked it up to the adapter board's own FPGA. Then generate the div-by-24 (1.024MHz) clock off of that within the FPGA and resample the S-DSP's serial audio stream using that. In this way, you will resample the audio output samples at precisely the rate at which they were originally generated on every individual console regardless of its exact sample rate.

There is however one small caveat to the source synchronous approach for this particular application. You may likely run into the issue that the oscillator in the console cannot handle a multi-drop (i.e. multi-load) application. Most oscillators are meant to be connected to 1 and only 1 load unless they are specifically rated to support multi-drop. And note that multi-drop oscillators are more expensive than standard oscillators, so you're guaranteed that the oscillator in the SNES is not a multi-drop rated oscillator. Much more likely is the case that it was the absolute cheapest oscillator that Nintendo could buy in mass quantity - which is probably exactly why the oscillator frequency varies so much from console to console.

In cases where you want to use a single non-multi-drop rated oscillator in a multi-drop application you would want to connect the output of the source oscillator directly to the input of a multi-output clock buffer and then connect the outputs of that clock buffer to the loads (i.e. the S-DSP and the adapter board's FPGA). This is the only "safe" way to have multiple loads on a standard oscillator. Of course, you could always try it the cheap way and hook up the SNES' osc to both chips in parallel with no clock buffer and see if you get lucky too... Lol :)

With all that said I still don't think that's the best option for resampling the SNES' output because you're going to miss all of the audio mixed in from the cartridge (if any) and the audio mixed in from the expansion port (if any). (Remember, there are 3 possible sources for the final mixed audio output from the SNES.) So you'd probably be better off re-sampling the final amplified analog output at 64kHz (i.e. the Nyquist) and call it good. You still have the option in this scenario of tapping into each console's audio source oscillator (keeping in mind the multi-drop caveat mentioned above) if you wanted to get a perfect re-sampling across all consoles. But worrying about losing a couple samples across the span of 32,000 samples is splitting hairs if you ask me. So what if you re-sample at 64kHz but the source content is 32020. Big deal. Of course, if the actual sample rate was 31980 then you'd be over-sampling for that console rather than under-sampling. (Note that the frequency can vary faster OR slower from osc to osc.) In either case, would anyone notice? Probably not. And note that if you're using your own oscillator input to the FPGA that your own oscillator is not going to be an exactly perfect frequency either. All of these reasons and more are why you almost never worry about this stuff in common practice unless you have some super-ultra-high-speed, super-precise application where you have to be spot-on. But in 99% of cases it's just not worth thinking about. Just re-sample the incoming data at twice the _expected_/_intended_ frequency (which in this case is 32kHz) and call it good. After all, what's a few Hz between friends? :)

lidnariq
Posts: 10273
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: HDMI SNES?

Post by lidnariq » Sun Oct 25, 2015 2:10 pm

SPDIF and HDMI audio sinks are known to reject (or at least seriously screw up) digital sources that aren't much closer than the 1permille error that the SNES APU's clock often has.

Injecting the correct 768×32000 Hz clock is the only correct answer.


Anyway, what peripherals actually use the SNES's expansion audio? The only one I already know of is the SGB (and its 3rd-party descendant that plays GBA games). You'd have to digitize the analog output there anyway, which largely defeats the purpose of keeping the APU's almost-I²S output all-digital until the final stage.

Post Reply