Jump to content

Blitter: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
m minor gr
→‎The historical need for a blitter: 1st mention of sprite should be a link to definition
Line 6: Line 6:


==The historical need for a blitter==
==The historical need for a blitter==
In early [[computer]]s with [[raster graphics| raster-graphics]] output, the screen buffer was normally held in [[main memory]] and drawn under the control of the CPU. For many simple graphics routines, like sprite support or flood filling polygons, large amounts of memory had to be manipulated. A typical reason to move large data areas arose when drawing [[bitmap]]s, such as when drawing the next frame during a [[computer game]] or demo. An image that moves smoothly across the screen might give rise to the need for a bitmap (representing the image) to be moved every frame. Game designers had to design their game's graphics so that the total amount of bitmap data transfer required to draw each frame was within the capacity of the CPU.
In early [[computer]]s with [[raster graphics| raster-graphics]] output, the screen buffer was normally held in [[main memory]] and drawn under the control of the CPU. For many simple graphics routines, like [sprite (computer graphics)|sprite]] support or flood filling polygons, large amounts of memory had to be manipulated. A typical reason to move large data areas arose when drawing [[bitmap]]s, such as when drawing the next frame during a [[computer game]] or demo. An image that moves smoothly across the screen might give rise to the need for a bitmap (representing the image) to be moved every frame. Game designers had to design their game's graphics so that the total amount of bitmap data transfer required to draw each frame was within the capacity of the CPU.


As graphics hardware became more sophisticated, [[frame buffer]]s grew larger with higher resolutions and colour depth. Games designers wanted to use larger images to represent game elements, and to maintain acceptable framerates. Graphics operations then required more and more data transfer speed to accomplish these bitmap moves. This work tied down the CPU, preventing it from operating on other tasks or making it infeasible to transfer large images within the finite time allowed for processing between frames.
As graphics hardware became more sophisticated, [[frame buffer]]s grew larger with higher resolutions and colour depth. Games designers wanted to use larger images to represent game elements, and to maintain acceptable framerates. Graphics operations then required more and more data transfer speed to accomplish these bitmap moves. This work tied down the CPU, preventing it from operating on other tasks or making it infeasible to transfer large images within the finite time allowed for processing between frames.

Revision as of 17:39, 19 February 2009

In a computer system, a blitter is a co-processor or a logic block on a microprocessor that is dedicated to rapid data transfer within that computer's memory. A blitter is capable of copying large quantities of data from one memory area to another relatively quickly, and in parallel with the CPU.

The name comes from the acronym BLIT, which stands for BLock Image Transfer. A typical use for a blitter is the movement of a large bitmap in a 2D computer game or demo.

The historical need for a blitter

In early computers with raster-graphics output, the screen buffer was normally held in main memory and drawn under the control of the CPU. For many simple graphics routines, like [sprite (computer graphics)|sprite]] support or flood filling polygons, large amounts of memory had to be manipulated. A typical reason to move large data areas arose when drawing bitmaps, such as when drawing the next frame during a computer game or demo. An image that moves smoothly across the screen might give rise to the need for a bitmap (representing the image) to be moved every frame. Game designers had to design their game's graphics so that the total amount of bitmap data transfer required to draw each frame was within the capacity of the CPU.

As graphics hardware became more sophisticated, frame buffers grew larger with higher resolutions and colour depth. Games designers wanted to use larger images to represent game elements, and to maintain acceptable framerates. Graphics operations then required more and more data transfer speed to accomplish these bitmap moves. This work tied down the CPU, preventing it from operating on other tasks or making it infeasible to transfer large images within the finite time allowed for processing between frames.

Blitters in home computing

Computer manufacturers introduced blitters to help lessen this graphics burden on the CPU, or to allow more complex graphics. Several home computers manufactured in the 1980s included a graphics co-processor that contained a blitter. The CPU would send a description of the necessary bit blit operations to the blitter, which would then carry out the operation much faster than the CPU could, and in parallel.

One of the first blitter-like units was used in the Bally Astrocade. The Astrocade was set up so all addresses below 0x4000 were dedicated to ROM. The graphics chip was wired to notice all attempts to write to this address range, and then "flip" the address to its own memory area in RAM, applying a function to the data being written. Using XOR as the function, basic blitting operations were very easy to implement.

The Commodore Amiga was the first personal computer to use a full-featured blitter, and 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.[1] On top of the ability to copy and manipulate large areas of graphics, the hardware that contained the Amiga's blitter also included line drawing and area-filling hardware.

Later models of the Atari ST also included a blitter co-processor, which was named in all capitals as the BLITTER chip. One story[citation needed] states that manufacturing delays deferred its introduction into the ST line until after the first STs had shipped. Another is that the Atari ST's main competitor, the Amiga, was famous for its blitter, and so Atari introduced one as well. Although Atari planned an upgrade to allow dealers to install the blitter chip, this plan was later dropped. Instead, the BLITTER was introduced on the Mega series, and then also supported on most later machines (except the Atari TT).

Graphics-oriented software (especially games) running on systems that did not have a blitter needed to find other methods of transferring large bitmaps. Some games were written across platforms, some of which contained a blitter and some of which didn't. A typical example would be a game written for the Atari ST and Amiga. Both machines contained similar hardware, including the MC68000 processor, but the Amiga contained a blitter and the early Ataris did not. Such a game could not rely on the presence of a blitter. One approach to handling this was to load all available 68000 data registers with data from the bitmap in memory, and then push the data into the frame buffer in as few operations as possible.

Blitting was not the only solution to providing high-performance graphics in performance-limited machines. A more common solution in early machines was the use of sprites, which used two different graphics pathways to draw images that were then combined in the video display circuitry into a single image. Sprites were small bitmaps that were positioned on the screen independent of the normal bitmap background, allowing them to be moved on-screen by adjusting the values of several timers. The video circuitry started drawing the sprites after the timer had expired, allowing them to be drawn for little cost, and avoiding the need to move memory around to provide the illusion of motion. The downside of this approach is that the sprite systems generally had hard-coded limits to the number of sprites they could display, often between two (the Atari VCS) and eight (Commodore 64). Blitters offered the ability to have any number of objects, limited only by the performance of the blitter and the memory it talked to. As the performance of these circuits increased, the flexibility of the blitter overwhelmed any performance advantage in the sprite approach, and many sprite systems became blitters in disguise.

Operation

Sprites (Left) and Masks (Right)
Sprites (Left) and Masks (Right)

Typically, a computer program would wait for a blitter to finish a previous operation before giving it its next operation. It would put information into certain registers describing what memory transfer needed to be completed, and then trigger the blitter to begin operating. The program (that is to say, the CPU) would then begin some other operation while the blitter operated.

The destination for the transfer was usually the frame buffer. On some computers such as the Commodore Amiga, the blitter did not have access to the full quantity of memory that the CPU had access to. However, a blitter could also be used for non-graphics work. For example, an area of memory might be zeroed (filled with zeroes) using a blitter relatively faster than can be accomplished with the CPU.

The image at right explains how a blitter may use a 'mask' to decide which pixels to transfer and which to leave untouched. The mask operates like a stencil, showing which pixels in the source image represent content.

Current technology

Today, all modern graphics processing units contain blitter-like hardware, or hardware that can mimic the function of a blitter, that functions quickly and in parallel with the CPU. However, the hardware and software design model used for modern graphics makes blitter function relatively crude and superfluous, especially for 3D work.

Modern APIs such as Direct3D and OpenGL approach the problem of drawing the next frame in a computer game by forcing the programmer to describe the entire frame, and then drawing it from scratch. Movements of data from one area of the frame buffer to another are inefficient and may be considered very bad technique on some hardware or under some APIs. Modern hardware can apply transformations to source images, such as rotation, scaling, and variable transparency, with very little overhead and hardly any extra work for the programmer. The modern use of texture mapping onto polygons makes the function of blitters completely obsolete.

Knowledge of blitter operations is relevant to those seeking to gain historical and conceptual understanding of computer graphics, and for those who are programming legacy hardware.

See also

References

  1. ^ "US Patent 4874164 "Personal computer apparatus for block transfer of bit-mapped image data"".