question about DMA registers

[psycopathicteen]

Do the DMA registers get destroyed after a DMA block has been transfered? If they do not get destroyed, does the source address register continue where it left off after a DMA block update, or does it still hold the starting point of the last DMA block? Same thing with the DMA legnth register. Does it count down to zero during a DMA block update, or does it still hold the legnth of the previous DMA block?

I want to know if there is a faster way to upload an individual 16x16, without updating them in groups of 8, or spending additional vblank time reseting the DMA control registers, just to get the bottom half of a sprite in.

[MottZilla]

I think the parameters for the transfer remain the same until you choose to change them. So it's always going to be the exact same transfer until you alter the registers. I could be wrong, write a test ROM and find out. But I see no reason why the DMA registers would become altered by having the DMA transfer activate. But it's possible, afterall the NES's VRAM Pointer for $2006 is also used in rendering. So DMA registers could be modified during DMA.

BSNES *probably* should have the behavior correct if you don't have a flash cart or copier to test on real hardware.

[nocash]

Addresses are incremented (or decremented) during transfer, and contain new address after transfer.
Same for the length counter, contains 0000h after transfer.
Special case would be HDMA, the start address is used as reload value (and doesn't change).

[Near]

BSNES *probably* should have the behavior correct if you don't have a flash cart or copier to test on real hardware.

To give you an idea of how thoroughly I've tested things ...

I found a glitch where if the last HDMA indirect channel completes (eg no other HDMA channel is scheduled to run after it), the indirect address is updated to the low byte of the loaded address << 8, and the final read does not occur, so it finishes eight clock cycles sooner.

So yeah, it's well tested =)

[MottZilla]

Well then I was right to believe you would have tested such behavior. Curious, are you aware of any games that rely on either of these DMA behaviors?

[Near]

I have myself relied on SNES DMA regs being updated as it runs. That's pretty common.

No game intentionally relies on the HDMA reload issue to my knowledge, but that tiny difference once per frame ended up throwing off the main menu in Circuit USA somehow.

What I'd really like to know more about is the 1/1/1 SNES' DMA glitch. When DMA starts near an HDMA end and vice versa, the entire system crashes. I want to emulate it, but it's hard to test what's happening when the entire system crashes on you

[qwertymodo]

Emulating a system crashing hardware glitch... that sounds like all sorts of fun >.<

[tepples]

Not too much different from stopping emulation on the STP opcode on the 65816 or any of the twelve STP opcodes (whose low nibble is $2) on the 6502.

[Near]

Far, far, far easier to emulate STP. And STP is useful for test ROMs. Less code than sei; stz $4210; stz $4211; bra $fe =)

This doesn't just freeze the CPU, I suspect what's happening is the program counter is being corrupted. Sometimes really weird stuff happens, like the screen fills with gibberish and random sound effects start playing. It's ... something to behold.

[MottZilla]

If the PC is being corrupted and you can make it crash where you want maybe the PC corruption is just causing it to be misaligned with the opcodes? Maybe stick some NOPs after where it would crash and see if you can make it recover? Just a random thought though. I've never heard much about the DMA glitch other than it existed on the original version of the hardware.

[mic_]

How about this:

• Fill as much of the memory space as you can with WAI opcdes.
• At the first scanline of the active display period, setup the GP DMA / HDMA combo that will trigger the crash, and hope that whatever weird value PC is changed to will hit one of the WAIs.
• Once the next vblank occurs and your NMI handler is called, fetch the return address from the stack and log it somehow (send it through a debug interface, print it to the screen, ...).

?

[koitsu]

Re: WAI method: why not just fill memory with $00 and install a BRK/IRQ handler, in which you pull the originating address off the stack, save it somewhere in DP or RAM, then in NMI do your drawing/rendering of the 16-bit address in DP/RAM?

[mic_]

Same but different. As long as the amount of non-WAI/BRK code is kept to a minimum to reduce the chance of hitting anything else than one of those instructions when PC gets corrupted (if that's what's happening). This obviously won't work if PC ends up somewhere in I/O space

[tepples]

It's not a bus conflict between the DMA unit's address output and the CPU's address output, is it?

[Near]

Lots of great ideas, anyone here want to test them out on hardware and see?

I'm honestly pretty swamped from my end. Dumping more than 720 carts, databasing all the board layouts, hacking Far East of Eden Zero, trying to figure out a hires blending edge case in Marvelous, build an SNES expansion port connector, on and on.