fork of 9front i guess
e502abe001
H-blank DMA should only transfer 16 bytes per h-blank, rather than waiting for the first h-blank and then transferring the whole size. HDMAC should read 0xff when the transfer is finished, and 0 in the high bit when the transfer is ongoing. Also, if 0 is written in the high bit, the current transfer should be aborted. Introduce two flags, DMAREADY and DMAHBLANK rather than special constants 1 and -1. If dma is non-zero, there is an ongoing DMA. If DMAREADY is set, the next chunk is ready to transfer. Reference: https://gbdev.io/pandocs/#ff55-hdma5-cgb-mode-only-new-dma-length-mode-start Tested with pokemon crystal. What was happening is that when the game was loading N background tiles into vram (each 16 bytes, so one per h-blank), it did something like this: - start an hdma transfer for N+1 tiles - after the Nth tile is transferred, it would read HDMA5, clear the high bit, then write it back to abort the transfer. games/gb would instead transfer all N+1 tiles at once, overwriting one extra tile with whatever was 1 past the end of the source array, and then would interpret the cancel request as the start of a new transfer of 16 bytes, which would copy an additional tile past the end. The end result is that every transfer would end up copying N+2 tiles instead of just N, overwriting certain tiles with whatever was after the end of the source data. |
||
|---|---|---|
| 386 | ||
| 68000 | ||
| 68020 | ||
| acme | ||
| adm/timezone | ||
| amd64 | ||
| arm | ||
| arm64 | ||
| lib | ||
| mips | ||
| power | ||
| power64 | ||
| rc | ||
| sparc | ||
| sparc64 | ||
| spim | ||
| sys | ||
| .hgignore | ||