I assume you're referencing register $420b in the SNES? You might want to be more descriptive when asking for help.

I'm also assuming you mean your DMA routine is inside the NMI routine?

How can you just set a flag and wait for DMA? DMA pauses CPU execution and executes practically immediately after being enabled on $420b.

If you are 'waiting' for DMA, you are probably using it incorrectly as that's not really possible.

As for potential problems:

1. Depending on how long the original game's NMI routine is and where your code was added, your added code may not always execute within the vblank period in which case, your transfer may not occur.

2. Make sure that channel is not in use by the game. It's easy to think a channel is not in use and later find it is under certain circumstances.

There's obviously something different occurring on the fourth transfer that doesn't happen on the other three. You'll need to find out what that is. You can use the debugging version of BSNES which will show the results of DMA realtime when viewing VRAM. You can step through and see if it indeed worked immediate after that instruction. If it didn't, something is wrong with your DMA code or the game messed with some of the DMA register settings.

What is VAR_VSYNCFLAG? That's what I don't get.

Is that code separated? Your NMI code shouldn't be waiting for anything. Perhaps I misunderstand what you're doing.

If you're setting a flag in the normal game code and then NMI will DMA if it's set that's another thing. If that's what you're doing, then that's ok.

There's really not a lot that can go wrong here. I will wait and see what you come up with after looking at the debugger. If your DMA code is write and the registers are set correctly, DMA WILL fire on $420b enable. It has to.

Nothing appears to be wrong with your DMA code.

Considering this works 3 out of 4 places -- I'm inclined to think you might be mistaking that last area for something other than it really is -- and perhaps your DMA routine isn't being called because the original routine isn't being run when you are thinking it is.

I would try to verify that your DMA routine is even being called.

The only other thing I can think of, is maybe the DMA is working, but then the game is overwriting VRAM again a little bit further in the code.  Perhaps you might want to check that out as well.

Ok.. so we know:

1. Your DMA code is correct.
2. It actually is being executed when expected.
3. The game doesn't interfere with the register settings.
4. DMA must execute as per hardware design.

Therefore.. I can think of a few more things...

1. Does the code still fail on an older version of ZSNES? I only ask because this will eliminate all possibilities of trying to send data to VRAM while not under vblank. Being that the other three circumstances work, this probably is not the case, but I like to be sure. If it worked with ZSNES for some odd reason, that would be the avenue to peruse. The DMA may fire, but the data does not actually get to VRAM.

2.   Not to insult your intelligence, but are you sure you're looking in VRAM and at the right VRAM address for the results? In BSNES you also have to refresh the contents with the update button to see the current values as I don't think it's updated on the fly by default like Geiger's.
If you write to location $5600 as set via $2216, you're actually writing to effective location $AC00 which is where you'll need to look if you want to view VRAM contents. VRAM is only addressable to $7fff via $2116. It's because there are two VRAM chips that you can get an effective VRAM range of 0-ffff.

3. A savestate is not too useful if the condition Disch mentioned exists. If the game overwrote VRAM again soon after your DMA, the savestate would show that data and visually it would appear as if your transfer never happened.

Aside from those three things, I can't think of much else that could possibly be happening. DMA is executing. It's just either not going where you think it's going, or it is trying to go there, but can't get there. And check and double check your source data is where it should be. It's quite easy to bang your head over an issue and then find out, you had moved some data around, or were dyslexic when putting down the source address.

aha!

That hadn't even crossed my mind.

Glad to hear you got it working  :thumbsup:

+1 for Disnesquick! Smart cookie. I didn't even think about that. Hopefully that'll stick in my head if I ever make the same mistake in the future. That's definitely one of those annoying problems that could cause some head banging.

Yes, that was indeed the problem. I thought that was obvious. The information was available, nobody thought about it. Sometimes it doesn't matter like for instance writing to the lower 128K of RAM. You can do that in a LoROM setup from most banks. It's not hard to overlook the data bank register even if you full well know the rules and how it works. I know for fact that every person who responded in this topic knows how DMA works and understands why it didn't work in this case. It just wasn't caught. No need to give us all an undecided face.  \

You can be decided. :laugh: