nesdev.com
http://forums.nesdev.com/

HDMA behavior at frame end?
http://forums.nesdev.com/viewtopic.php?f=12&t=16262
Page 1 of 1

Author:  HihiDanni [ Wed Jul 26, 2017 2:58 pm ]
Post subject:  HDMA behavior at frame end?

There are a couple things related to the HDMA timeframe that I'd like to see cleared up from a developer's perspective, regarding how HDMA terminates at the end of the frame. Two questions, but they may or may not actually be the same question:

First, is it valid to have an HDMA table that extends outside the active area? More specifically, does the zero terminator in the table have to occur before VBlank? I imagine this would likely simplify HDMA offsetting logic if it is something you can indeed get away with, since you could just change the step size at the top of the table without having to replace any entries in the table with zeroes further down.

Secondly, as far as the DMA crash goes, would it be a good idea to disable HDMA when entering the VBlank routine? Or would this be a waste of VBlank time?

Author:  lidnariq [ Wed Jul 26, 2017 3:15 pm ]
Post subject:  Re: HDMA behavior at frame end?

HihiDanni wrote:
First, is it valid to have an HDMA table that extends outside the active area? More specifically, does the zero terminator in the table have to occur before VBlank?
Yes and no, respectively. The HDMA tables are copied from $43x[23] to $43x[89] at the beginning of rendering. Not clear about specific timing, it's probably somewhere in Anomie's docs.

Quote:
Secondly, as far as the DMA crash goes, would it be a good idea to disable HDMA when entering the VBlank routine? Or would this be a waste of VBlank time?
Not clear it would help you? Maybe it would give you a glitched out screen instead of a crash...

It's probably just a better idea to make sure there's no chance of DMA running over into the active frame anyway.

Author:  creaothceann [ Wed Jul 26, 2017 3:19 pm ]
Post subject:  Re: HDMA behavior at frame end?

anomie wrote:
If HDMA (init or transfer) occurs while a DMA is in progress, the DMA
will be paused for the duration. If the HDMA happens to involve the
current DMA channel, the DMA will be immediately terminated and the
HDMA will progress using the then-current values of the registers.
Other DMA channels will be unaffected.

[...]

HDMA does not occur during V-Blank, as any writes it might perform are
likely have no visible effect anyway. The start-of-frame processing then resets
all active channels at the end of V-Blank. This allows updating of the HDMA
registers during V-Blank without worrying about the transfer beginning
immediately and scribbling on the PPU state.

Does that help?

Author:  AWJ [ Thu Jul 27, 2017 2:05 am ]
Post subject:  Re: HDMA behavior at frame end?

HihiDanni wrote:
There are a couple things related to the HDMA timeframe that I'd like to see cleared up from a developer's perspective, regarding how HDMA terminates at the end of the frame. Two questions, but they may or may not actually be the same question:

First, is it valid to have an HDMA table that extends outside the active area? More specifically, does the zero terminator in the table have to occur before VBlank? I imagine this would likely simplify HDMA offsetting logic if it is something you can indeed get away with, since you could just change the step size at the top of the table without having to replace any entries in the table with zeroes further down.

Secondly, as far as the DMA crash goes, would it be a good idea to disable HDMA when entering the VBlank routine? Or would this be a waste of VBlank time?


HDMA isn't processed during VBlank, and at the end of VBlank the HDMA engine is completely reset. As a result, table entries that extend past the bottom of the active display are effectively ignored.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/