Kismet
-
Content Count
494 -
Joined
-
Last visited
Posts posted by Kismet
-
-
Yeah, it's really unfortunate. I would love to be able to have just one controller that works with everything on the Nt Mini and Super Nt, but there is just too much stuff that rejects input from the NTT Data Pad. As far as I can tell you can't navigate the SD2SNES menu with it either.
There's a product opportunity for 8bitdo right there.
-
I don't own a Super NT yet so I'm going by HD youtube videos, but my NT Mini doesn't show shimmering at 5x.
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.
-
I've also toyed with the splash screen delay settings a bit. I'm currently using an hdmi to dvi cable to run my asus monitor (the monitor only goes to standby mode with dvi input) and analog stereo audio split off using a monoprice hdmi switch. It takes a full 8-9 seconds for the display to wake from this setup, with audio starting about a second earlier than video. On my 720p living room Sanyo, I need a delay of only 4 seconds for the display to respond, and audio / video are simultaneous. The HDMI switch likely increases the sync time on thd ASUS but does not produce lag. The ASUS response time is 9ms. I have no idea what the Sanyo is but it's fast enough that I don't notice it.
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 says this? So we've had it confirmed that a lot of excess capacity remains on the Super NT's FPGA, that we can expect improved scaling options, and that he's looking into enhancement chip support for SD rom loading in an upcoming patch?
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.
-
2
-
-
I would imagine it renders they very pointless with that firmware. Considering the NT had to be capable of running any legitimate game cart Nintendo published that would make all the special chips viable from the era. That means that the SDSNES failing on SDD1, SA1, FX, FX2, and the other odd one offs/near one offs have to work in the Super NT too. Just download the smokemonster dump, organize the parts you value best, throw that in there with the hacked file they provide in the root, and you have a true 'everdrive' that doesn't crap out on special chips. With that little SD card and the small system size itself you have a pretty small total system all games possible package going on there outside of the few SS6 games that won't play nice with HD.
Nope. The JB firmware is broken. It plays no expansion chip games either.
It depends on what custom chips it can support. I'd expect it doesn't have MSU1 for example. My guess is that it could obsolete the Everdrive (if it has DSP1/2/3/4 support) but not the SD2SNES. Remains to be confirmed until somebody tests and reports back.
Also note that this is for ROM images only. On real original carts the special chips are there so it should work fine without JB.
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.
-
I haven't had any bugs or glitches with real cartridges other than DKC3 telling me it can't run with devices used to copy games, and that was resolved by cleaning the cartridge extra well.
When they say "99% of problems are caused by dirty cartridges" it's probably quite true. If I understand correctly, the Super NT provides a slightly lower amount of power to the cartridge, and I imagine that makes clean contacts even more important. Especially if you're having lots of graphical glitches in different games, it probably represents a collection that hasn't been cleaned in a while. Especially if they're like... obvious ones that would've been spotted in basic testing.
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.
-
Will people ever stop stating things as a fact, when they don't know if it is a fact or not? Just stop. Say "I think".
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.
-
My crappy unboxing video of the Super NT from last night:
Bug Report: Super NT Mini may not display properly on some 720p flat panel TVs...
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?
-
Im curious what you mean be consider the source
Im not jumping to conclusions but if Kevtris hadnt been behind it wouldnt he have said that? There wouldnt really be much point in keeping things mysterious.
Edit: uggg for some reason posts from my phone always drop punctuation
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.
-
1
-
-
Of course he wrote the jailbreak, but he will disavow any knowledge of it which is why he used smokemonster / github as a release portal.
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.
-
Did you try 1. Saving within the game and then 2. Exiting to the Super Nt menu?
If so, its a bug that others found too. Im sure it will be fixed soon..
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.
-
What happens when I turn on the Super Nt with the Super Wild Plugged in, is exactly what is shown in the firsr picture I posted. Its simply a blank screen with "HDMI No Signal".
The same thing it does when the Super Nt is powered off, or when the HDMI plug is disconnected.
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.
-
I did find something that works perfectly on a real SNES system, as well as an SNS-101, but not on the Analogue Super Nt.
The Super Wild Card DX (3201) SNES copier from 1994.
I asked on another post if the Super Wild Card DX would work, and received a "Yes, most definitely." answer. Not so.
I do have an SD2SNES cart as well, but I have owned and used the SWC DX, and other copiers since 1992, and even dumped many of the roms still floating today.
So I was looking forward to seeing how it looked on the Super Nt.
Maybe there will be a fix for this? I hope so.
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?
-
That's still assuming Kevtris did not write this. He could write a jailbreak without other cores. He had 8-bit cores already but maybe not 16-bit. Also considering that there may be a chance of a Analogue Genesis, which a core would mean many wouldn't buy it.
EDIT: I would still buy the Super NT for roms even if I only got the SNES core.
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.
-
So I guess the big question is that since Kevtris is still squashing bugs, does the jailbreak firmware need to be updated every time there is an official firmware change?
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.
-
Sorry but I'm calling shenaningans here. My response time (from responding to visual stimulus by hitting a button on my controller) is reliably 130ms playing Wild Gunman on NES with a CRT. Sometimes I can get it down to 110ms. You need to hit the trigger within 160ms (10 frames) to beat the fastest opponent. Pro level speedrunners may very well be gifted with faster than average reflexes. That said, when playing actual rythm games, I can get tighter response because my brain anticipates making the inputs before they are executed. There is no way your brain can respond by pushing a button within 005ms in response to visual or auditory stimulus unless you have the reflexes of superman.
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.
-
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?
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
-
So which 4K tv is this? None of them in that link have lag below 10ms but your test here shows 5ms.
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.
-
It sounds more like an issue with your TV, especially since it's happening with another device as well. I don't know why DVI would cause it (since HDMI and DVI are basically the same thing, at least as far as the digital video portion goes). It sounds like a problem with how your TV recognizes and/or handles the signal.
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.
-
Feature request, if it's possible:
Can re-selecting the run cartridge option while a cartridge is already running do the equivalent of a power cycle instead of a "soft reset"? Currently I can't think of a way to get back to the SD2SNES menu to switch games other than loading Super Turrican to flush out the cartridge, and then booting the cartridge again.
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.
-
For what it's worth, I just had a quick look at the Higan source code
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
-
Honestly I think the best we can hope for out of first generation Mega NT/Analogue MD is just an expansion port for an actual Sega CD and maybe somebody will create a some kind of adapter so we can plug the analog out from the DAC into the AV In on the 32X, and just only have analog output on the 32X, and upscale it. Come to think of it, I think this is inevitable for the 32X. As long as the Mega NT's case isn't some weird shape that disallows the 32X from being plugged into it, and the Genesis core is sufficiently accurate, it should just work right? This means that it'll be MORE expensive for Analogue to have some kind of support for the more successful of the 2 add-ons, with whatever the expansion port costs.
This actually makes me think of my hope for the Analogue DAC add-on having an HDMI pass-through, with the ability to switch between "DAC mode" and HDMI pass-through with a controller hotkey. Then you could have the HDMI pass-through plugged into your TV, then the DAC output could be plugged into the 32X AV In, with the 32X AV Out upscaled however.
It probably can't be done.
https://www.polygon.com/features/2015/2/3/7952705/sega-genesis-masami-ishikawa
Despite not working on the Mega-CD were you aware of the design process? Was the hardware complex to implement?
MI: I was told by someone who worked in the Mega-CD production department that because there were no plans to release a CD-ROM add-on when we were designing the body of the Mega Drive, it was really difficult to design the connection between the two units. It seemed, however, that Sato-san was obsessed with the idea of a CD peripheral. The solution involved attaching a metal plate adaptor to the base of the Mega Drive and then sliding it onto the CD unit. Four holes and connectors held them together — it was not screwed on to hold it in position. Another obstacle was that the Mega Drive's side extension connector slot had a carbon resistant coating to prevent rust on the copper connectors of the board, but this actually made electric resistance very high and lowered connection signal levels, which resulted in weaker noise-resistance.
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.
-
1
-
-
higan was super dark compared to *my* 2 chip, and 1 chip though. I am not sure what else I can do since it's not like the snes has a palette like on the NES. Since it's 999 RGB (approximately) it isn't possible to make a palette either. It's 555 RGB but there is also the 4 bit brightness register to worry about, too.
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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Super Nt Console review
in Classic Console Discussion
Posted
Issues with save games mostly. It seems to be random that save games actually persist past a reboot of the NT.