nesdev.org

Does anyone know how to reliably trigger the DMA/HDMA crash? I was hoping that we might be able to figure out what was going on using poot36's slightly-broken SNES, but byuu tells me it's not simply as easy as just starting one of each transfer type at the same time.

I struggled with this very bug in an early alpha build of my PowerPak firmware. I could try and write up a test ROM that reproduces it (the original code unfortunately wasn't preserved, but I do remember the details). This might take a few days though as I have little spare time right now ...

If you have any down time, I'd appreciate it.

Only caveat is that poot36's SNES breaks the stack pointer when you issue a PLB or PLD instruction, but you probably don't need those.

Here you go.
Source code is included so you can tinker around with it if you feel like it. BTW, I ensured there were no plb/pld instructions used.

Screenshots of some of the less dramatic effects:







I especially like the solid green background color it brings up at some point. Note how the text cursor position gets messed up as well.

This is beautiful and weird; is the cause of this crash written up somewhere? A little searching didn't return much.

I was hoping to trigger the crash on poot36's SNES (since he has a logic analyzer there) but it hasn't been cooperative yet.

> This is beautiful and weird; is the cause of this crash written up somewhere? A little searching didn't return much.

Nobody knows.

Given that it crashes the program execution, I have no way to write a software test to verify what's going on.

My best guess is that it ends up fetching (H)DMA data for instructions to execute and/or fetching instructions [and subsequently displacing the program counter] for (H)DMA to process.

But from over a decade of past experience, it'll most likely end up being far more convoluted than that. When it comes to the SNES, it's never the most logical behavior.

I'm guessing an address bus conflict of some sort between the CPU and the HDMA controller.