Blitter

In early computers with raster-graphics output, the frame buffer was normally held in main memory and updated via software running on the CPU. For many simple graphics routines, like compositing a smaller image into a larger one (such as for a video game) or drawing a filled rectangle, large amounts of memory had to be manipulated, and many CPU cycles were spent fetching and decoding instructions for short repetitive loops of load/store instructions. For CPUs without caches, the bus requirement for instructions was as significant as data. Further, as a single byte usually held between 2 (for 16-colors) and 8 (for monochrome) pixels, the data was not naturally aligned for the CPU, so extra shifting and masking operations were required.

Blitters in personal computers and video games

1973: The Xerox Alto, where the term bit blit originated, has a bit block transfer instruction implemented in microcode, making it much faster than the same operation written on the CPU.[1] The microcode was implemented by Dan Ingalls.[1]

1982: The Robotron: 2084 arcade game from Williams Electronics includes two blitter chips which allow the game to have up to 80 simultaneously moving objects.[3] Performance was measured at roughly 910 KB/second.[3] The blitter operates on 4-bit (16 color) pixels where color 0 is transparent, allowing for non-rectangular shapes.[4] Williams used the same hardware in other games from the time period, including Sinistar and Joust.[4]

1984: The MS-DOS compatible Mindset personal computer contains a custom VLSI chip to move rectangular sections of a bitmap. The hardware handles transparency and eight modes for combining the source and destination data.[5] The Mindset was claimed to have graphics up to 50x faster than PCs of the time,[6] but the system was not successful.

1985: One of the hardware coprocessors in the Amiga personal computer is a blitter. The first US patent filing to use the term blitter was "Personal computer apparatus for block transfer of bit-mapped image data," assigned to Commodore-Amiga, Inc.[7] The blitter performs a 4 operand boolean operation:

destination := op(destination, source, mask)

1986: The TMS34010 is a general purpose 32-bit processor with additional blitter-like instructions for manipulating bitmap data. It is optimized for cases that take extra processing on the CPU, such as handling transparent pixels, working with non-byte aligned data, and converting between bit depths. The TMS34010 served as both CPU and GPU for a number of arcade games starting in 1988 with Narc and including Hard Drivin', ', Smash TV, Mortal Kombat, and NBA Jam, [8] It was also used in professional-level graphics accelerator boards in the 1990s.

1986: The Intel 82786 is a programmable graphics processor with a BIT_BLT instruction to move rectangular sections of bitmaps.[9]

1987: The IBM 8514/A display adapter, introduced with the IBM Personal System/2 computers in April 1987, includes bit block transfer hardware.[10]

Atari ST Blitter chip

1987: The Atari Mega ST 2 ships with a blitter chip.[11] Officially called the "Atari ST Bit-Block Transfer Processor", stylized as BLiTTER, it provides 16 options for merging source and destination data.[12] The blitter is supported on most subsequent ST machines, including later revisions of the entry level STfm home computers.

1989: The short-lived Atari Transputer Workstation contains blitter hardware as part of its (Mega ST-based) "Blossom" video system.[13]

1993: The last game console produced by Atari Corporation, the Jaguar, ships with blitter hardware as part of the custom "Tom" chip.[14]

Sprites (Left) and Masks (Right)

Typically, a computer program puts information into certain registers describing what memory transfer needs to be completed and the logical operations to perform on the data. The CPU then triggers the blitter to begin operating. The CPU is free for other processing while the blitter is working, though the blit running in parallel uses memory bandwidth.

To copy data with transparent portions—such as sprites—a color can be designated to be ignored during the blit (such as color 0). On other systems, a second 1 bit per pixel image may be used as a "mask" to indicate which pixels to transfer and which to leave untouched (see image at right). The mask operates like a stencil. The logical operation for transparent-color system (after OR-summing the pixel bits to determine whether or not that pixel is color 0) is destination := (background AND NOT mask) OR sprite. For a separate, precalculated mask plane, where both the masked and unmasked pixels can be any palette entry / combination of 0 and 1 bits (and would, in the previous operation, potentially clash with the background even when supposedly masked-out), the operation is destination := (background AND NOT mask) OR (sprite AND mask) (still three inputs, but using one of them twice), similar in operation to the XOR based method employed by software rendering (of e.g. 1-bit-plus-mask mouse pointers in early monochrome or color-bitplane GUIs, with any additional bitplanes all clamped to 0 in the masked areas).

Hardware sprites are small bitmaps that can be positioned independently, composited together with the background on-the-fly by the video chip, so no actual modification of the frame buffer occurs.[15] Sprite systems are more efficient for moving graphics, typically requiring 1/3 the memory cycles because only image data—not CPU instructions—need to be fetched, with the subsequent compositing happening on-chip. The downside of sprites is a limit of moving graphics per scanline, which can range from three (Atari 2600) to eight (Commodore 64 and Atari 8-bit family) to significantly higher for 16-bit arcade hardware and consoles, and the inability to update a permanent bitmap (making them unsuitable for general desktop GUI acceleration).

• Direct Memory Access (DMA)