Where did the Sprites go ?
One of the things I wondered a while ago was: What happened to sprites ? Why aren't they in a lot of graphics controllers ?
Actually, a lot of graphics controllers do contain at least one and sometimes two "sprites". They are more commonly called hardware cursors. The mouse pointer that moves around the screen in most systems is a "sprite".
Part of the reason the "sprites" are missing is the capability of technology. A sprite was a reasonable way to get a small mobile bitmap into the display. When displays were 256x192 a sprite represented a large graphic area on the screen and was easily visible. With today's screens of 1024 x 768 a sprite which may be quite large (eg 32x32) only appears as a small image on the display. The image size isn't large enough to be useful in many cases. Also, with the increased capability of display controllers, many controllers have "hardware accelerators" which include things like bit-blit engines. A sprite in some ways is like a simple bit-blitted bitmap. The bitmap "accelerators" built into many graphics controllers are capable of performing the same function as a sprite would have.
The problem with sprites and VGA:
There are bandwidth / performance issues with sprites, having the sprite data stored in external SDRAM. Many VGA systems use SDRAM because of the high capacity and bandwidth requirements.
Example:
VGA: 1024x768, 50MHz video clock
Memory: 50 MHz SDRAM, 16 bits wide
Sprites: 32x32 16 bit colour
Random read / write cycles without burst access (necessary to load the sprite data) take anywhere from 4 to 6 clock cycles (approximately). Therefore in order to load the 256 words of data for the sprites (8 sprites * 32 words) on a scan line, 1024 clock cycles would be required (possibly significantly more). The problem: More clock cycles are required than there are available. There are only 331 clocks available max during the retrace and blanking (1355 clocks for the entire scan-line). (Assuming a 50MHz clock and typical VGA display).
Solutions:
The solution is to reduce the bandwidth requirements of the sprite, or to make more bandwidth available (or both).
1) Use a higher performance memory system ($$$). The available bandwidth available can be increased by using a higher performance memory system. For example using 200MHz, 32 bit wide memory would quadruple the available bandwidth for the parameters above.
2) Reduce the screen usage (display resolution). There are several ways to do this. The typical VGA display uses almost 100% of the width of the screen. By reducing the screen usage by placing a "border" area outside of the display area, there are more clock cycles available to fetch data for sprites. For example switching the screen to display only 768 x 768 in a 1024 x 768 display area would add 256 clock cycles to the number available to fetch sprite data (almost doubling it). To eliminate what might be an unsightly border, a scan buffer / fifo could be used during the data fetch to change the data rate.
3) Use an independent memory subsystem for the sprite data. Sprites are typically small and don't require a high capacity memory. Using a small memory to contain the sprite data allows the system to fetch data as it does normally for the screen display, then fetch data from an alternate location when the sprite needs to be displayed. Having an independent sprite memory means that the essentially random memory access required to fetch sprite data don't interfere with the normal burst mode SDRAM access.
4) Shadow (double buffer) the display system.
The high data rate requirements are an aspect of the display device. It's the display device itself that needs data at a high rate.
There are often sprites that don’t move or change at a high rate (frequency - eg. 1Hz). The sprites are updated by the processor at a much lower rate than what is necessary to display them. The typical video system accesses memory for sprite information at a much higher rate than really needed for some sprites.
The sprite image data would simply be bit-blitted (copied) to a shadow video memory, which is then displayed using a simple linear scan. The advantage of doing things this way is that the bandwidth for sprite display can be controlled. Instead of having to display the sprites immediately when the scan reaches the sprite area, the sprites can simply be copied to the shadow memory at any time. The copy process can then be controlled in a prioritized fashion, so that if too much is trying to be displayed, the system can “lose” display quality in a graceful (controlled) fashion. This kind of thing is really just a customized bit-blit engine. A “front end” could be added to the bit-blit engine to make it look like and be backwards compatible with existing sprite register sets.
VGA Controller with Sprites: