Kismet

Issues with save games mostly. It seems to be random that save games actually persist past a reboot of the NT.

There's a product opportunity for 8bitdo right there.

Youtube, or any video capture really will not give an accurate representation of what is actually seen on the screen. Most people don't know how to capture video properly (basically you capture HD at the input resolution, not the target resolution, and then change the output scale to the target resolution when you are doing anything to the input stream), so a lot of the mush seen on youtube videos is actually a result of the capture hardware being fed a 1080p60 or 720p60 input but the editing software doing it's own interpolation and scaling to it. Anytime you upload something to youtube you have to render it at 2x or 4x the target resolution so that youtube's scalers don't go to town on it. This is a bit easier to explain from the capture side, but essentially by the time your web browser watches a youtube video, it's been rescaled 4 times. This is why you never upload 480p footage. Always upload 720p60 or 1080p60 otherwise youtube will lower the quality of it, believing you are uploading SD footage.

Switches/Splitters are passive devices. They don't cause a re-handshake. I bought one really cheap auto-switch and unfortunately when I used it in conjunction with the splitter, most devices didn't work through it, and the WiiU would randomly trigger it even though it was off. That said, HDCP handshake has to be reestablished with switches, but not splitters. So there's no additional latency being added, but it's very likely likely the lenght of the HDMI cable is compromised in the same manner that long USB and long Ethernet cables have maximum electrical properties that limit their lenght. I had one really long firewire cable that killed my camcorder's firewire port, so buyer-beware, even though it may be passive, it may also put additional load on the devices at either end. "Extender/Clone" devices do exist for HDMI, these actually do something akin to a framebuffer, thus they do add latency by design so you can double your distance. This is the kind of thing they use in airports and train terminals to show the same thing on dozens of screens at the same time. Since the signal comes off a computer and not a HDCP device, they don't need to deal with the HDCP handshake. So for the most part, any switching latency you see is due to the switching causing a re-handshake and some devices simply blank the screen instead of showing distorted garbage.

Kevtris said something alluding to the fact that there was plenty of space in the FPGA in the SuperNT, but obviously not enough to do native 4K. Which is fine, as 2160p60 4K screens appear to be a lot less miserable. But he has said nothing about sd card loading or enhancement chips. The logical thing is for people to just hold their horses and quit bugging him about it. On one of the live streams people were asking about this stuff every minute or so. So I imagine he's getting bombarded with questions that he's already refused to answer, even places other than here.

Nope. The JB firmware is broken. It plays no expansion chip games either. None. It would only obsolete the Everdrive's without DSP chips, that's about it. Considering that the Everdrive is like $85 w/o DSP, or $105 with DSP vs the SD2SNES $196. Consider that the Everdrive uses older Cyclone II (DSP models) and Max II fgpa's, and people generally consider it slow. The speed of the SD card on SuperNT is entirely dependant on buying a good SD 8GB+ SDHC/SDXC card. You can get 32GB UHS-I cards for like $30, or get the slower Ultra 10 32GB for like $12 off Amazon. My class 4 card that I use on the SD2SNES because it was just what I happened to have nearby when I got the SD2SNES last year works fine on the SD2SNES. Just make sure to fat32 format them.

The only cart I had that had an issue was the SFC Sailor Moon cart, and it fixed it self after the third time I put it in the Super NT (this game starts with a black screen for a few seconds because it's playing audio.) So the theory here is that the electrical resistance might be different with the Super NT cart connector, so you would obviously need to clean the contacts of carts better than you would on the original SNES. Also I kinda wish it had a mechanical eject mechanism so that even pressure would be placed on the cart as it's removed due to how grippy it is, but if the SD2SNES is just going to sit in it most of the time, I'm not too concerned.

I think people here don't have the first clue how to program, otherwise they would realize how asinine the suggestion that kevtris released a broken sdcard jb firmware anonymously. There is no reason to do that. There is no conspiracy here guys. The most obvious answer is "it doesn't matter, they just rushed it out untested", and whatever hacking or disassembly/assembly they did to do it didn't do enough. If it was simply unhiding a menu option to load from the SD card, it may very well have been incomplete, and the next firmware might optimize it out to prevent further leaks of it. If it was actually added by a skilled person, it still doesn't need to be kevtris because anyone who knows PIC32 can do it, and if you note, PIC32 chips are not unique to just the Super NT. The FPGA core however would require having the source code to the core, and that just won't be a thing unless someone else who was working on a FPGA SNES were to replace kevtris's core. People clearly can't wrap their head around this, otherwise they would realize that asking about expansion chips or other cores is not going to get an answer because only kevtris knows how the FPGA is wired up. To port a MiSTer core or something like that to it would not be a trivial undertaking despite also being on a Cyclone V FPGA, because the SoC in it is not the same.

Hmm, perhaps defaulting to 1080p60 might not be the right solution since there might be broken EDID or broken capture cards. Would it be possible to set the SuperNT in a failsafe mode (eg 1080p60, 720p60, 480p60) when powered on if both shoulder buttons are held down or something? Bringing it directly to the resolution menu every time in a different mode until something shows up?

The source (smokemonster) is the same source for the gamepacks people are fond of. He did not dump the games himself, he just found whatever was the least damaged version to put in the pack. The same is likely for firmware blobs. It's likely you'll see the unofficial SuperNT firmware blobs showing up in those packs just to ensure that people who download the pack can make it work on the SuperNT. But someone had to either know the menu item was in there, or found it through reverse engineering. It's also very likely that the SD card loading was designed to straight-up use the data from a Everdrive or SD2SNES otherwise there would be no provision for importing the saves the way they are setup. It's pretty much impossible to add such features if they were not already in there. So what I'm saying is that the firmware is very likely just "unhiding" features that actually already exist, not something someone added to it.

You don't know that. And quite frankly I find the suggestion that kevtris would leak such a thing without officially announcing it to be troubling. So I'm going to go with "someone who knows PIC32 disassembled/decompiled it, found a hidden menu item, and unhid it" There are at least three people that have existing skills that could be used to program the SuperNT other than kevtris. jwdonal, bunnyboy (RetroUSB AVS) , ikari (SD2SNES). Consider the source.

Because of the potential for some games to "use sram as work ram" it's likely it works the way it does because constantly writing to the SD-card would not be fast, and would wear sdcards out that don't have half their space free quickly (eg you's need to use a 16GB or larger card.) So you likely have to bring the menu up and tell it to switch games to write the SRAM or something. Right now, I'm not willing to test it because the source is unknown.

Hmm, might need kevtris to comment on it, but I suspect it might still be power. A regular 3.5" floppy drive uses 5V at 1.25A . The supplied USB cable and USB "power" brick likely can't do that. OEM US SNES PSU is 10V @ 950ma, SFC JP models were 850ma. USB is only designed for 500ma, but specific charger types like those for the iPhone/iPad, and some power strips that include USB ports allow for up to 2.1A. I don't know what the tiny brick that comes with the SuperNT does, but it's smaller than my iPhone's stuff.

If it doesn't work, you're going to need to volunteer more information that that. eg, When you go to "run cartridge" what happens? Screen black (try cleaning it?) or does it not get through a boot process?

What I'm saying is that it was clearly done using whatever code is already in the firmware. Nobody can push out a SNES FPGA firmware in 2 days. So whatever is in this JB firmware probably just unlocked the existing feature that was probably not #ifdef'd out of the compile process but probably "if readfromcard = yes , lots of extra code" and changed the initialization state. Who knows really. You can pretty much take any binary firmware blob, run it through IDA Pro, and figure out where any debug stuff was left in.

Obviously yes. Chances are whoever put this out there simply found the code for the existing games and copied it around. Note there are no other cores.

You know how that test works right? It doesn't allow "early hits", which is what happens when you anticipate it. I reliably get 10ms on my 4K or 15 on my TN every time except when it went through the splitter and capture card. When it goes through the capture card, I can typically get about 32ms if the software I'm using isn't buffering it. What you don't see, is how many times I "hit early" when I do it with my 4K , it took me about 80 seconds to do it.

Only if the monitor/HDTV/Capture device actually respects those bits. To go back a few pages, I use a SA7160 based capture device, it has a very useful panel This is what the TV box normally does at 1080i This is what the SuperNT (4.1) does at 1080p

Part if that is reaction time. This is the result of the manual lag test on my 4K monitor, the SuperNT runs at 1080p here. 240p lag test @4k 480i lag test @4k On my 1080p TN monitor with the splitter in place 240p lag @1080p 480i lag @1080p Note how only the 480i mode seems to suffer.

HDMI is basically DVI-D with the audio channels and HDCP handshaking. My earlier message with the capture card kinda spazzing at 1080p reflects this kind of thing too. Nearly any time you see "green everywhere" there's some kind of handshake problem. When you use HDMI as a "PC Monitor" most video cards actually default to an overscanned mode. This typically requires going into the video card's control panel and turning overscan adjustments off. When you use a "PC Monitor" as a TV over HDMI, usually the monitor goes edge-to-edge right away, because that's what it's expecting. This would be easier to explain with a brand new screen. Past experience has basically indicated that a "computer" output will wind up not filling a 1920x1080 HDTV screen, even though it's at 1920x1080 unless a setting is told not to. I had this problem with AMD cards. Since Windows moved to a resolution-agnostic mode, this problem has kinda only persisted with multi-monitor setups that are of unlike resolutions/aspect ratios.

Just hold the reset button for like 3 seconds, that returns to the SD2SNES menu

I received the Analogue SuperNT today: Right out of the box I encountered one problem that is likely unique to my setup, but if kevtris has any idea about it: This goes through a signal splitter first, so it's not the only thing that behaves strangely through it (eg the tv box doesn't support 1080p60 (tv box actually puts out 1080p24), but supports 1080i through it) On the capture software it actually looks like it's reporting 1080p, but running at 1080i, or failing hdcp handshake. The color looks fine though (720p) In both cases the colorimetry and color range is not being reported, which is to be expected over HDMI with this card apparently.

I'm pretty sure the output from Higan is the incorrect one in this testing methodology then. But I wouldn't say the output is actually wrong. If you check "colors" in v106 the colors are pretty much the same as the SuperNT

It probably can't be done. https://www.polygon.com/features/2015/2/3/7952705/sega-genesis-masami-ishikawa Any MegaNT that can take a real SegaCD peripheral would have to overcome the same engineering problems because the Genesis wasn't designed to have one in the first place. It may be possible to leave an "expansion slot" open, but it would only be able to take a MegaNT "pony" device, to use the term kevtris used near the beginning of the thread for the Z3K. As I mentioned a page or so back, there is no point in repeating the same engineering short-sightedness that the Sega engineers did.

This appears to be a case of the calibration being different. Between the second and third image, is only the difference of 16-235 vs 0-255. Between the first and third image, the first image is simply brighter. Like picking the same pixel in both frames: Higan(left) 0,107,140 ( #006b8c ) SuperNT(mid) 12,93,142 ( #0c5d8e ) SuperNT(right) 0,89,146 ( #005992 ) If I pick (or attempt to pick) the same pixel from my SNES, I get 0,99,134 (#006386) which is from the SA7160 set to RGB32 If I go back and tell it to do YUV2 I get 0,102,134 (#006686) If I select RGB32 again, I get 4,96,133 (#046085) Keep in mind that since the pixels are not square, it's not possible to grab the exact square pixel, and it's analog. If I pick a white pixel (from the O in nintendo) Higan (left ) 255,255,255 (#FFFFFF) SuperNT(mid) 245,245,245 (#F5F5F5) SuperNT(right) 255,255,255 (#FFFFFF) My GPM-02 SNES, YUV2, 252,255,252 (#fcfffc) My GPM-02 SNES, RGB32 218,228,230 (#dae4e6) Basically when the capture output is set to RGB32, it's displaying YUV2 within the parameters of RGB32, thus it's darker. At any rate, you're going to have to chalk this difference up to the capture capabilities presently. Edit: now that I think about it, that middle image is wrong. If it's set to full input, but the image clamps to 12-245, that is still wider than it should be, which should be 16-235. RGB reference black is 16,16,16, and white is 235,235,235. so the correct input would Limited so it would expand it to 0-255. editedit, I want and looked at the dark pixels in the image, there are places in the image where Higan has 0,8,8 but the middle image is 0,5,6 but the image on the right is instead 0,0,0