One last thing to be sure I understand this! So basically what's going on is that when it switches the tilemap with HDMA going, it's doing it one scanline at a time. The tile map is already predetermined in drawn in VRAM, but HDMA does it one line at a time as it displays so it doesn't cause any graphic corruption. After its done with however many lines, it switches back to the original tilemap setting.
Does it then keep repeatedly switch the tilemap byte repeatedly as the dialogue box is there? I'm assuming it does because altering any byte of data that dictates with HDMA going causes graphic corruption.
Err... well... HDMA doesn't display anything. Let's backtrack a bit.BIG PICTURE
The PPU is what draws stuff. It has a chunk of memory in VRAM as well as a bunch of registers. Games tell it what to draw by filling VRAM with graphic tiles, tilemaps... then sets PPU settings by writing appropriate junk to the PPU registers.
When it's time for the frame to be rendered, the PPU will constantly be checking all those regs and doing VRAM fetches to draw the appropriate pixel to the screen. Which means if you change a PPU register in the middle of the frames, that will [more or less] immediately change how the PPU draws.
The thing to note here is that program code on the CPU is run in parallel
with the rendering done on the PPU. So really this is all about timing.
I don't remember the cycle counts exactly, but each scanline takes the PPU roughly ~150 CPU cycles to complete. For a point of reference, LDA immediate takes the CPU 2 cycles to complete. So the game can run maybe 40 instructions or so in the span of one "scanline" worth of time.
On older systems like the NES... games that wanted to split the screen would have to count the number of cycles they executed to keep track of the "time", so that they can know when the PPU is about to start drawing a specific scanline. But with HDMA you don't have to do that.
All HDMA does... is it watches the PPU execute scanlines... counts them as they pass.... then when the desired number of scanlines pass, it cuts in and does a quick write to change how the PPU will draw from that point on.
So if you want the screen to switch to a dialogue box on scanline 100, you'd tell HDMA to count 100 scanlines then do a write to switch tilemaps.
Does it then keep repeatedly switch the tilemap byte repeatedly as the dialogue box is there?
do it that way, but no that's not what you'd want.
To switch the tilemaps you only need the HDMA to do exactly two
writes. One at the start of the dialogue box, and one at the end. That's it.
- HDMA waits for X scanlines while the PPU draws the normal world
- HDMA cuts in, does a single write to switch tilemap
- HDMA waits for Y scanlines while the PPU draws the dialogue box
- HDMA cuts in again, does a single write to switch tilemap back to its original state
- HDMA is done -- PPU draws the normal world for the rest of the frame.
I'm assuming it does because altering any byte of data that dictates with HDMA going causes graphic corruption.
I might not understand what you mean here -- but HDMA does not cause graphic corruption when you use it properly. This is exactly what it was designed to do -- it makes carefully timed writes to PPU registers mid-frame for easy split-screen effects. That's its entire function.