HDMA behavior at frame end?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

HDMA behavior at frame end?

Post by HihiDanni »

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?
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: HDMA behavior at frame end?

Post by lidnariq »

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.
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.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: HDMA behavior at frame end?

Post by creaothceann »

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?
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: HDMA behavior at frame end?

Post by AWJ »

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.
Post Reply