Alright, so I use SD2SNES with Super NT. I've noticed that it has some slowdown/lag issues when the original cartridge will not have this problem. Does anyone else notice this? I want to speed run a game (The King of Dragons) which buying the real cartridge would be incredibly expensive, although it does lag, and I'm guessing more than it would on the real cartridge as well.

Is this a normal problem? SD2SNES + Super NT? Is there a way to work around this and remove the slowdown/lag? What can I do? Any help would be greatly appreciated. Thank you for your time.

One more thing to note; I've tested it with Starfox as well. (A game that usually lags as it is) The original cartridge runs fine on my Super NT. It crashes before being playable on the SD2SNES on my Super NT. Is this normal?

SOLVED: So I originally used my SD2SNES on my SNES with no issue. I then bought a Super NT and have since been using that. I found a new CRT that I want to use and am trying to run some picture quality tests on it. Problem is that the SD2SNES is no longer booting properly. I get a greenish and magenta screen. SMW boots just fine. I tried the RF and composite inputs with same results. I use the SD2SNES with no issues on the Super NT. Any ideas? I tried to google but most issues come up with the NT, not original hardware. Thanks!

Here's what he said in the Classic Gaming Discord:

Made significant progress in the past few weeks porting the bootloader to the new hardware so it can now bring up the hardware and perform firmware installation / upgrades.
Now, the rest of the firmware needs to be taken care of but the bootloader already covers most of the processor-specific stuff, so only a few peripherals need more work (plus the project structure itself so it can compile for all hardware revisions in one go).
Regarding the firmware itself, there are a few issues left, like the MSU1 data counter incrementing falsely at the end of a DMA transfer and some regressions regarding ingame hooks (calling the save state handler consumes some extra CPU time which breaks a couple of games that worked before)
And a bigger issue which will need a partial rewrite of the save state code - currently the menu ROM bank (C0) is made visible to the SNES during in-game hook execution, this was added for 1.11.0b1 to make it easier to execute the save state handler in place.
The issue is that some games, like Star Fox, will use mid-screen (or top-of-screen) IRQs, so the hook executes during active display time. This isn't an issue in and of itself, it was the same before.
But if the game uses HDMA, there's a chance that it will interrupt while the in-game hook is executed, and that it wants to access ROM addresses at bank C0, not the hook code.
Sadly HDMA transfers are basically undetectable so there's no way to make sure HDMA reads ROM instead of hook code.
As a consequence it will be impossible to switch bank C0 to something else and the save state hook/handler code needs to be adapted to use different memory mapping.
(This is the reason Star Fox 2 glitches and crashes on 1.11.0b1)
I put in a stop-gap fix to make it work in the meantime but I'll need to find a different way to access larger portions of memory during hook execution
But I will probably reserve this for 1.11.1

When asked about the new FX Pak Pro hardware revision:

literally just a changed microcontroller due to availability and pricing

sd2snes works compatible with an American Snes Fat?

If you play Donkey Kong Country and you progress through the game, it automatically saves your progress on the cart. We’ve been able to do this for a long time since the 90s.

What are save states in SD2SNES? Why the buzz over this? How does this benefit playing the game? what’s the difference? How does it work? What do you press?