I took another look at 'world_map_gba' to try to resolver the issue. The first thing I did was try out the ROM on GBP to see the expected result:
The interesting scanline is the one with a single brown pixel that sticks out on the right side of the castle into the grass approximately at the height of the player's eyes. This scanline is indicative of audio DMA delaying execution of the code that updates the reference regs when HBL IRQ happens. GBP seems to internally blend frames together, and this is why the effected scanline is slightly duller and blurrier than the others, as it is flickering between frames. In fact this is exactly what NanoboyAdvance gets if you turn on LCD ghosting (without it the flickering is noticeable, but this is a display issue not an emulation issue.)
Then I looked at the code the game was using to see what the driver of the issue is and why GBAHawk wasn't matching hardware. It turns out pretty much everything except FIFO DMA is a non-factor. The timer that ultimately runs the FIFO is turned on after a VBlank IRQ, and the prefetcher isn't turned on at the time, and as these are well studied things, the absolute timing of when FIFO ticks happen is set. The latching of various involved ppu parameters is also well tested. So really the only movable parameter is timing of the FIFO DMAs. Before I could mess with that though I had several small bugs in the audio code (off by one errors and not clearing fifo on reset) as well as the ppu (a mish-mash old and new code from when I was working on reference point latching.) Once those were fixed it was just a matter of checking which FIFO ticks the DMA needed to run on to match hardware.
Having done so however, the results are kind of awkward, new DMAs occur when the sample buffer has 14 samples left, instead of the expected and more natural 16. So something still likely isn't right. I implemented what I had for now though, as it was still better than before and fixes some definite bugs. A more thorough testing of FIFO DMA is still needed.
