From Glitch City Wiki
Jump to navigationJump to search

AutoBgMapTransfer[1] is a mechanic in Pokémon Red, Blue, and Yellow that transfers tile data from a buffer in the WRAM (wTileMap) to the actual VRAM every frame during the VBlank. It is disabled by default in the overworld, but enabled when the player is using menus, talking to sprites, battling, etc. When the player is walking in the overworld map, another mechanic, RedrawRowOrColumn, is used instead to transfer tile data to the VRAM more efficiently (and presumably with less flickering).

An important quirk of AutoBgMapTransfer is that it only transfers one third of the screen each frame, cycling between the top third, the middle third, and the bottom third. Since the height of the Game Boy screen is 9 map tiles, or 18 subtiles, each of these portions is exactly 3 tiles/6 subtiles high. This has a few visible consequences, such as the existence of two frames where the menu text is only partially displayed when opening the Start menu (the Start menu box is drawn with a different method and always appears entirely in one frame[2]), and dialogue text being printed 3 characters at a time every 3 frames when the text delay is set to "Fast" (the dialogue box is located entirely within the bottom third of the screen).


All graphics data to be displayed on the Game Boy screen must first be stored in the VRAM. Due to VRAM inaccessibility, while the screen is on, this can only be done during the VBlank period, which is only a tiny fraction of each frame (about 1.1 milliseconds, or 4560 T-cycles). Therefore, the game logic would usually just record (in the WRAM) what needs to be done to the VRAM, and then during the VBlank interrupt, a function would read the recorded data from the WRAM and manipulate the VRAM accordingly. Since the VBlank period is very short (and trying to update the VRAM outside of it would likely lead to glitches), it is preferred to only update what is actually changed, but doing that for every use case would likely increase the complexity of the interface between the game logic and the VBlank logic. Therefore, in many cases, the game logic would just write to a buffer in the WRAM, wTileMap, which is supposed to be constantly mirrored to the VRAM in its entirety. However, even with coding "hacks" such as using pop instructions to read two bytes at once faster, it is infeasible to copy the entire wTileMap to the VRAM in a single VBlank period. This is why AutoBgMapTransfer only transfers one third of wTileMap each frame, in order to ensure that the transfer can be reliably finished in a VBlank period while leaving time for other tasks that needs to be done during the VBlank.


  1. The function AutoBgMapTransfer in the disassembly
  2. Actually, the main reason is that the menu box is drawn and copied to the VRAM (in 3 frames) before the window is put onto the screen. Also, after this the game needs to load the text font, which takes 17 frames, a quite noticeable delay to the naked eye.