run_dma delay actually waits 166 machine cycles

[ReiquelApplegate]

This subroutine in "Best practices" is supposed to delay for 160 machine cycles:

run_dma:
    ld a, HIGH(start address)
    ldh [$FF46], a  ; start DMA transfer (starts right after instruction)
    ld a, 40        ; delay for a total of 4×40 = 160 M-cycles
.wait
    dec a           ; 1 M-cycle
    jr nz, .wait    ; 3 M-cycles
    ret

It actually delays for 166 machine cycles (because ld a, 40 takes 2 and ret takes 4). I have not tested it yet, but can't we load the accumulator with 39 instead of 40 and reduce wait time by about 2.5%?

[calc84maniac]

There are a few errors in your analysis here, though one of them I would consider a defeciency in Pan Docs.

First of all, the final JR NZ takes only 2 cycles, not 3. Secondly, RET can access memory outside of HRAM after its first cycle. That means the HRAM-only access cycles after the write to the DMA register only add up to 162.

The deficiency in Pan Docs, on the other hand, is that it neglects to mention the 1 M-cycle startup delay between the write to the DMA register and the start of the transfer. That means the HRAM-only access cycles after the write must be at least 161. The size-optimized routine in Pan Docs satisfies this requirement by using a conditional RET which starts with 2 HRAM-only cycles, but does not explain why this is needed.

[ReiquelApplegate]

Yeah, probably is a dangerous optimization to try. Though I'd imagine that if the stack is in HRAM, then ret can return a little bit sooner because the return address is in HRAM too. But, according to http://gameboy.mongenel.com/dmg/asmmemmap.html most coders nowadays point the stack to the top of internal RAM instead.

[calc84maniac]

Right, there's not much reason to have the stack in HRAM unless you want to avoid external bus accesses (as in the boot ROM) or you're creating a code golfed ROM and don't want to spend the instruction to move it. HRAM is only faster when using LDH instructions, and being able to put more variables in HRAM will save more cycles in the long run than the 2 or 3 you'd save here.

[ReiquelApplegate]

Maybe it's worth mentioning that if you're going to LDH those 5 saved bytes a lot then eating the time penalty of run_dma_tail is worth it.

[ReiquelApplegate]

A comment after run_dma in the compact procedure says it must be in ROM, but I don't see why it couldn't be in WRAM instead.