Eicar

Hi @kevtris ! The Super NT is awesome! This is the ultimate SNES, and when the rest of the bugs are ironed out it will probably be the last SNES I will ever need to buy However, I have a few feature requests 1. Would it be possible to have a RGB color range setting like: Full (0-255) or Limited (16-235) like you have on the Nintendo Switch, Xbox etc? 2. Would it be possible to have an audio bitrate option like, 32 kHz (native), 44,1 kHz or 48kHz ? Maybe also the ability to select 16 or 24 bit? Are you simulating the SNES's DSP in native 32 kHz internally and resampling to 48kHz? My receiver shows 48 kHz from the Super NT. 3. Simulation of the "real" non-linear RGB gamma ramps for the different video DACs sounds awesome! 4. Have you looked at what kind of HDMI device the Nintendo Switch / XBox / PS4 etc. are identifying themselves as? Are you sure "PC" is the right one? I though there was a special device type for gaming devices. This will also tell the TV/Monitor to bypass most of the internal image processing to reduce input lag. Maybe this only applies to newer HDMI 2.0 standard? I'm not an expert on this... I guess a HDMI signal analyzer would be able to tell what other gaming consoles are doing.. Hope this will make it into the firmware someday Keep up the good work!!

So, does this mean that the "source device" (Super NT) needs to set the CN1 and CN0 bit on in order for the screen to detect in as a Game device? Is the Super NT doing this? I'm getting my Super NT today, and I have the same LG TV as @Beer Monkey, however I also have a Nintendo Switch connected to it and I havn't had any issues with overscan. So I guess that if the Nintendo Switch works on my TV without overscan over HDMI, then the Super NT should also behave the same way.. Both transfer audio over HDMI so they are both running in HDMI mode and not DVI. Can't wait to test this when I get home... As a side-note... Alot of people have issues with overscan using the Raspberry PI. The raspberry pie has a special disable_overscan=1 setting that you need to add to the boot config file. This setting magically fixed my issues with overscan on an older Samsung TV. I'm pretty sure that this setting has nothing to do if whenever the videomode is HDMI or DVI, so I guess there is some magic "overscan" bit somewhere in the HDMI data stream that a device can set to control this. The question is if the Super NT is doing this correctly...

I have the same TV as you, except it's the European model (55B7V). My super NT will be delivered today so I haven't been able to test it yet. However, make sure the "Just Scan" option is enabled in the settings. Also try the different aspect ratios to see if it changes anything. "Original" sounds like the most obvious setting but you should try them all just in case. If it still doesn't work, then rename the HDMI port that you use for your super NT to "PC" (without quotes and in uppercase). This magic renaming will also change the behavior of the TV slightly. I will test mine this evening and I'll let you know what happens. -Eicar

For what it's worth, I just had a quick look at the Higan source code, and it does some magic with the ouput: auto Interface::videoColor(uint32 color) -> uint64 { uint r = color.bits( 0, 4); uint g = color.bits( 5, 9); uint b = color.bits(10,14); uint l = color.bits(15,18); //luma=0 is not 100% black; but it's much darker than normal linear scaling //exact effect seems to be analog; requires > 24-bit color depth to represent accurately double L = (1.0 + l) / 16.0 * (l ? 1.0 : 0.25); uint64 R = L * image::normalize(r, 5, 16); uint64 G = L * image::normalize(g, 5, 16); uint64 B = L * image::normalize(b, 5, 16); if(settings.colorEmulation) { static const uint8 gammaRamp[32] = { 0x00, 0x01, 0x03, 0x06, 0x0a, 0x0f, 0x15, 0x1c, 0x24, 0x2d, 0x37, 0x42, 0x4e, 0x5b, 0x69, 0x78, 0x88, 0x90, 0x98, 0xa0, 0xa8, 0xb0, 0xb8, 0xc0, 0xc8, 0xd0, 0xd8, 0xe0, 0xe8, 0xf0, 0xf8, 0xff, }; R = L * gammaRamp[r] * 0x0101; G = L * gammaRamp[g] * 0x0101; B = L * gammaRamp[b] * 0x0101; } return R << 32 | G << 16 | B << 0; } If you have enabled "colorEmulation" in Higan it will use it's own gamme ramp to simulate the non-linear analoge signal. I havn't received my Super NT yet (It will arrive tomorrow!) so I can't comment on the colors compared to Higan yet. However, everyone needs to pay attention to a lot of factors before making incorrect statements: 1. Higan runs on windows. This means the several factors can affect the HDMI output. What colorspace have you selected in the Nvidia/AMD/Intel control panel? Nvidia supports both RGB/YUV color space in both limited/full color space. For doing a fair comparison you should make sure that you have selected Full RGB color space output. Also, make sure that you have not activated any calibrated ICC color profile. That will also change the output from the PC. Also make sure that you havn't enabled any fancy settings in Higan like shaders etc. (quite obvious I think....) 2. Higan is not the reference for comparison. The real SNES hardware is the real deal. I guess the real SNES also differs quite a bit between chip revisions (Early Revs up to the 1-Chip etc.). 3. NTSC-U vs NTSC-J vs. PAL.... These will probably look different as well on a high-end Sony BVM monitor... In order to fix this properly, someone should make a video test-rom for the SD2SNES and run it on several real SNESs. The analoge RGB signal levels would need to be sampled (or checked using an oscilloscope) for all red/green/blue values from black to 100% color. red/green/blue might have different gamma ramp curves. The results should be averaged using several hardware consoles to rule out variation in old capacitors etc.. And this also needs to be done for Both NTSC and PAL consoles... Then these gamma curves/lookup tables/math formulas can be applied to the pixel processing in the Super NT. You would then need built-in presents for NTSC-J/U and PAL or raw linear, that the user can select I guess @kevtris has already looked into this already. Maybe you can fill in something here @kevtris? -Eicar

If it makes you feel any better.... I payed 55.31 USD for the shipping, and I pre-ordered the super NT the same day it was announced. I've not received a shipping confirmation yet.

I'm wondering about this as well. I've just gotten the FDSStick and I'm going to buy the RAM adapter. Is it just plain old hit and miss, or should I look for something special? I know that the actual FDS drives comes with different controller chips (3206 and 7201), do the RAM adapters differs as well?

I understand that the mapping of input and output pixels might cause a shift. However, if I start out with 'none', then go to 'hq2x' and then go back to 'none' then I would expect to have the same image alignment which I started with. However, this is not the case. I need to go back and forth between 'none' and 'hq2x' several times in order to get back to the correct starting alignment. Just try Super Mario Bros 1 @ 4,5x (vert scale) (1080p) and look at the bottom of the screen. Then go back and forth between 'none' and 'hq2x'. You can see that the bottom of the two bricks are sometimes cut off, and sometimes it's not. If you are still unable to reproduce this I can make a video of it.

@kevtris Is there any reason why I get the "load core yes/No" prompt everytime I go from any NES game and try to load Castlevania III ? Does it require a "special" NES core? However, I don't get the "load core" when I go to another game afterwards...

I'm testing firmware 1.6 now. Yes, the 5x height scaling slider works as it should now. The problem I'm talking about now is about the fancy upscalers, hq2x, hq3x, x-ray etc. The image will shift slightly if you go back and forth between 'none' and hq2x. I'm not sure if this was a problem before. I havn't seen it before...

@kevtris The scaling seems to work better now, however there's another small snag. If I go into the nes core menu when I'm running SMB1 and toggle back and forth between 'none' and 'hq2x' then the screen will be misalligned on the buttom. This means that going back and forth several times will change the position. (not beween two postitions, but many..) It's a bit hard to explain what's going on. If you're not able to see what I mean then I can take some images. However, it's quite easy to see when running SMB1 in 4,5x vert scale mode (hdmi@1080p) and looking at the bottom of the screen when you change back and forth between 'none' and 'hq2x'. Sorry to throw all this at you as you probably have better things to do. I just wanted you to know..

@kevtris It looks like something is wrong with the vertical scaling on the NES core as well. If I select 4,5x then it looks like the last two nes scanlines are missing (goes below the screen) I also get two black NES scanlines on the top. The vertical position slider also seems to no longer work. Nothing happens when I change it. I'm running HDMI @ 1080p in NTSC mode. Tested with Super Mario Bros 1, you can easily see the brick on the buttom (title screen) is chopped off. BTW: Do you have any plans for supporting FDS titles without using the Everdrive (or the real FDS hardware) ?

Well, there's many different systems to choose from. My expreience is primarly with GitHub and Jira (part of the Atlassian stack). However, Jira is an overkill commercial solution that I don't think will fit here. (Trust me, I use it daily.....) There's also Trac and Bugzilla... The nice thing about GitHub is that it's quite easy to use, and it's a system that alot of people already know. The actual issue/bug-tracking part of GitHub might not be the most advanced, but it's quite easy to use. Kevtris could also put his binaries here for his releases and we could create issues tied to specific release versions of his firmware and cores. Maybe, sometime in the future we could also get some sourcecode in there as well Then more people could contribute to the project, and Kevtris could shred our noob-FPGA pull requests into pieces As far as I can see, "kevtris" is not a registered GitHub user so the username is still available. (Hint... hint... Kevtris, go and register, it's free!) -Eicar

I preordered the NT Mini on the same day it was announced only because I knew that Kevtris was involved with the product. I already have Kevtris's Hi-Def NES HDMI kit from Game-Tech.us and know what to expect from his work. I've just played with the NT mini for a few days, and so far it's the best thing since sliced bread! I'm professional developer myself however I'm more on the asm, c, c++, python, x86/x86, microcontrollers side of things. My knowledge of verilog and FPGAs are quite limited. However, I know a lot about what kind of work that goes into this. I did write my own simple NES emulator in early 2000... and it was mainly all the different mappers that stopped me from getting to a usable state. It was only able to run a few games partially with glitches... I never released it. Thank you Kevtris for all your fantastic work! I will continue to follow everything you do! And as someone else said, you need to setup some kind of channel so we can give you all our money -Eicar