Crash on SNES with Everdrive X5

[jwalk9557]

Summary:
When I load a room from a category preset and then do some ammo loadout adjustments, eventually I will run into a crash after trying to create a savestate just after a door transition.

It also sometimes happens arbitrarily without making ammo adjustments.

Steps:

1. Load "High Jump Boots" preset in RBO.
2. Go up to ice gates door.
3. Change some ammo loadouts, e.g. increase Missiles to 20, supers to 15, PB's to 15 and ETanks to 4.
4. Progress through to ice beam and then back to Business center, creating savestates after various room transitions and re-loading a few times.
5. When creating the savestate into Business center, I observe a crash.

Isolation:
I was able to recreate this multiple times with my SNES + Everdrive x5. It's not an issue on my SNES Junior.

Extra:
I have a video of the crash. Feel free to message me.

[NobodyNada]

I was able to recreate this multiple times with my SNES + Everdrive x5. It's not an issue on my SNES Junior.

To clarify, the issue occurs on one console and flashcart, but not on a second console with the same flashcart?

I'm inclined to blame hardware for that (perhaps bad RAM?), but I'll take a closer look at the stack trace sometime later this week.

[jwalk9557]

Yes that's correct, it was never an issue on my SNES Jr. I just bought a replacement SNES (not Jr) and it happens consistently. I'll drop by game store tomorrow and try to bargain with them for a replacement. Not sure it will fly since I'm talking about an unofficial cartridge, they might not like that. Do some SNES have different HW / FW revisions on them?

…

On Sun, Jan 11, 2026 at 10:01 PM Jonathan Keller ***@***.***> wrote: *NobodyNada* left a comment (tewtal/sm_practice_hack#243) <#243 (comment)> I was able to recreate this multiple times with my SNES + Everdrive x5. It's not an issue on my SNES Junior. To clarify, the issue occurs on one console and flashcart, but not on a second console with the same flashcart? I'm inclined to blame hardware for that, but I'll take a closer look at the stack trace sometime later this week. — Reply to this email directly, view it on GitHub <#243 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4UZLFOCXE7SQ5AISZA4AZT4GM2BTAVCNFSM6AAAAACRMDCHOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZXGAYDEMBTGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[NobodyNada]

Different SNESes do have different hardware revisions, yes; there is no firmware on the console. But the hardware behaves identically in all but a few edge-case scenarios, and I haven't heard of a crash like this before. So faulty hardware strikes me as most likely. I can answer that in more confidence once I've had time to look at the stack trace, which I can probably do tomorrow morning.

If it's a hardware issue, you may be able to identify it with a test ROM (like the SNES Burn-in Test) or reproduce it in other games.

[jwalk9557]

Thanks! I’ll find a ROM for that and check.

…

On Monday, January 12, 2026, Jonathan Keller ***@***.***> wrote: *NobodyNada* left a comment (tewtal/sm_practice_hack#243) <#243 (comment)> Different SNESes do have different hardware revisions, yes; there is no firmware on the console. But the hardware behaves identically in all but a few edge-case scenarios, and I haven't heard of a crash like this before. So faulty hardware strikes me as most likely. I can answer that in more confidence once I've had time to look at the stack trace, which I can probably do tomorrow morning. If it's a hardware issue, you may be able to identify it with a test ROM (like the SNES Burn-in Test) or reproduce it in other games. — Reply to this email directly, view it on GitHub <#243 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4UZLFLZHLE5HVWIHTKPQZ34GM7FXAVCNFSM6AAAAACRMDCHOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZXGEYDIOBYGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jwalk9557]

FYI The ROM was reporting all PASSES, but I went by the shop and got a replacement SNES. I’ll keep you updated if I continue to see the issue. On Monday, January 12, 2026, Jonathan Walker < ***@***.***> wrote:

…

Thanks! I’ll find a ROM for that and check. On Monday, January 12, 2026, Jonathan Keller ***@***.***> wrote: > *NobodyNada* left a comment (tewtal/sm_practice_hack#243) > <#243 (comment)> > > Different SNESes do have different hardware revisions, yes; there is no > firmware on the console. But the hardware behaves identically in all but a > few edge-case scenarios, and I haven't heard of a crash like this before. > So faulty hardware strikes me as most likely. I can answer that in more > confidence once I've had time to look at the stack trace, which I can > probably do tomorrow morning. > > If it's a hardware issue, you may be able to identify it with a test ROM > (like the SNES Burn-in Test) or reproduce it in other games. > > — > Reply to this email directly, view it on GitHub > <#243 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/B4UZLFLZHLE5HVWIHTKPQZ34GM7FXAVCNFSM6AAAAACRMDCHOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZXGEYDIOBYGE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[NobodyNada]

Looking at the stack traces more closely, each one shows the game has crashed somewhere within the savestates VM:

sm_practice_hack/src/tinystates.asm

Line 460 in 9daf0c4

vm:

In addition, the values in the registers indicate that, in every case, the VM has just executed a write to $420B to trigger a DMA transfer. And then the CPU somehow went completely off the rails immediately after, before resuming normal operation well enough to trigger the crash handler. Perhaps ROM reads had a chance of returning corrupted values for a short time after a DMA transfer?

---

I looked at the hardware errata page on the SNESdev wiki and found an interesting entry:

On version 1 of the 5A22 chip ("S-CPU"), the chip can crash if DMA finishes right before HDMA happens.

Looking at the savestate timing in Mesen, it seems like the offending DMA transfer did end suspiciously close in time to an HDMA So, I suspect that the SNES you acquired was a very early model which had this hardware bug, but was not (otherwise) defective. We should fix the practice hack to disable HDMA during savestates so that others are unnafected by this issue.

Too bad you returned the SNES, because now we can't test a fix ;)

[jwalk9557]

Super interesting + impressive. Thanks for the extensive report! Maybe my replacement will be another early model. 😉 I’ll have a look tonight and report back.

…

On Monday, January 12, 2026, Jonathan Keller ***@***.***> wrote: *NobodyNada* left a comment (tewtal/sm_practice_hack#243) <#243 (comment)> Looking at the stack traces more closely, each one shows the game has crashed somewhere within the savestates VM: https://github.com/tewtal/sm_ practice_hack/blob/9daf0c4024c274b8d91f5ba6cbfc8f 00ae230795/src/tinystates.asm#L460 In addition, the values in the registers indicate that, in every case, the VM has just executed a write to $420B to trigger a DMA transfer. And then the CPU somehow went completely off the rails *immediately* after, before resuming normal operation well enough to trigger the crash handler. Perhaps ROM reads had a chance of returning corrupted values for a short time after a DMA transfer? ------------------------------ I looked at the hardware errata page on the SNESdev wiki and found an interesting entry: On version 1 of the 5A22 chip ("S-CPU"), the chip can crash if DMA <https://snes.nesdev.org/wiki/DMA> finishes right before HDMA <https://snes.nesdev.org/wiki/HDMA> happens. Looking at the savestate timing in Mesen, it seems like the offending DMA transfer did end suspiciously close in time to an HDMA So, I suspect that the *SNES you acquired was a very early model which had this hardware bug, but was not (otherwise) defective*. We should fix the practice hack to disable HDMA during savestates so that others are unnafected by this issue. Too bad you returned the SNES, because now we can't test a fix ;) — Reply to this email directly, view it on GitHub <#243 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4UZLFJBWSVBVZKUOTAWMC34GQWQNAVCNFSM6AAAAACRMDCHOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONBRGAYTAOBXG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[InsaneFirebat]

Excellent bug report and debugging

[jwalk9557]

FYI my replacement SNES doesn't have the issue. Really sorry for the impatience! Wish I had waited for your reply before jumping on the new console.

…

On Mon, Jan 12, 2026 at 7:21 PM InsaneFirebat ***@***.***> wrote: *InsaneFirebat* left a comment (tewtal/sm_practice_hack#243) <#243 (comment)> Excellent bug report and debugging — Reply to this email directly, view it on GitHub <#243 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4UZLFJQJOJA4EJJE2VVSML4GRQEFAVCNFSM6AAAAACRMDCHOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONBRGY2TKMRWGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>