12.09.08
Why the new blitter rules
As I get closer to finishing the implementation of the new GTE blitter architecture, I am just becoming more and more pleased. I really think I got it right this time. Case in point; the Unaligned Blitter.
The on-screen graphics field is constrained to be a multiple of 4 pixels in width (2 bytes). All of the instructions that transfer data to the graphics screen move 2 bytes of data at a time. However, GTE allows the screen to be scrolled in single byte increments. Thus, there are two versions of the blitter — one for aligned transfers and one for unaligned.
Unaligned transfers have to “fix up” the left and right edges by copying just a single byte of graphics data to fill in the edges. As you might imagine, since the graphics data is blitted by executing arbitrary code, grabbing a single byte of data is not exactly a trivial task.
The old blitter code solved the problem by copying the appropriate 3-byte code sequence from the BG0 code buffer, executing it inline and then popping the values of its stack before storing them to the graphics screen. This works fine, but it involved a lot of extra work; over 100 cycles per line. We solve the problem similarly in the new blitter, but we are able to cut the overhead by over 50 percent.
It is possible to modify the existing BG0 blitter code to handle the special case of the odd-aligned edges, but this involves some expensive save/patch/restore operations. Instead, we maintain a minimal parallel code sequence that can be patched with the 3-byte code sequences from the main BG0 code buffer. The specialized code array look like this:
ldx #0000 ; line number ldy #0000 db 3 ; first code sequence db 3 ; second code sequence ldx #0002 ; next line ...
The stack address is set up to place the pixel data in a special Bank $01 buffer and the edge data is copied in during the main blitting. The per-line overhead of this method is broken down as:
- 10 cycles to set the y-register values
- 44 cycles to copy the 3-byte instruction fields
- 6 cycles to execute the code
- 22 cycles to shadow the data
This gives a total overhead of 82 cycles per line. If the BG1 layer is not in use, this shrinks to only 70 cycles per line. Most of the overhead is in copying the data, so finding a more efficient method, such as placing the code in Bank $00 and using direct page addressing, could reduce this cost down to 36 cycles per line. The shadowing cost could similarly be reduced to 16 cycles.
In the best case scenario, the odd-aligned blitter will only incur an additional 55 cycles per line — less than half of the original overhead.