Modern computers use a graphics processing unit in order to provide hardware-accelerated graphical operations. Conceptually, I am used to thinking about graphics as a bidimensional array of pixels obeying a format such as RGBA8. This data gets written to a display device at some fixed rate.

In comparison, it seems older hardware made use of different abstractions. For example, the Nintendo Entertainment System made use of a picture processing unit that apparently implemented the concepts of sprites, tiles, backgrounds and color palettes directly in hardware. Somehow, these concepts get merged into a complete picture and a signal is generated and sent to the TV. The article also mentions that collision detection registers were a common feature at the time.

It seems graphics hardware used to be made with a specific domain in mind. Over time, they became more and more general-purpose. Now they can do general-purpose parallel computing, with many non-graphical applications.

I can see why graphics hardware is evolving towards general parallel computing: the multi-core nature of modern GPUs makes it possible. Similarly, I would like to understand this shift from domain-specific to general-purpose graphics hardware.

  • How exactly do retro graphics hardware differ in relation to modern graphics cards? What did they do that modern hardware doesn't do anymore?
  • What explains these differences? What properties of the technology of the time justified them?
  • Why do we not use the notion of sprites and tiles anymore? There must have been advantages to implementing them in hardware. Why were these concepts thrown away?
  • 5
    This is an interesting series of questions but it's way too broad — off the top of my head, I can think of graphics evolving from oscilloscopes, to vector displays, to "racing the beam" rasters, to display-list driven systems with sprites and collision detection... And that's ignoring PCs! Sep 19, 2016 at 20:47
  • A most general explanation of why the evolution would be that the resource cost has evolved over time (storage, compute and power). Sep 19, 2016 at 21:48
  • Note that sprites haven't gone away: the mouse cursor is usually implemented as a sprite these days. The mouse pixels used to be sent directly to the graphics buffer, but that required the graphics engine to hide the mouse before doing any operations in that area, causing the mouse to blink. Nowadays the current shape and colours of the cursor is defined in an off-screen area, and the graphics card is updated as to where to put it as the mouse moves around. The card imposes the mouse sprite image over the specified area automatically. Sep 20, 2016 at 7:57
  • If you want to learn about some really weird video hardware (or lack thereof), have a look at the Timex/Sinclair ZX81 - That uses the CPU to "execute" the display memory in the NMI (clamping the data bus to have it interpret the contents as "NOP", Line ends are interpreted as "HALT" instructions). About 80% of the Z80 CPU time is so "wasted" for video output to keep the chip count low. A detailed description can be found here: user.dccnet.com/wrigter/index_files/ZX%20Video%20Tutorial.htm
    – tofro
    Sep 20, 2016 at 16:53
  • Something as recent as the Nintendo DS still could work with sprites, backgrounds, tiles and palettes. It also had 3d hardware. Interestingly, NeoDS, a homebrew NeoGeo emulator for the DS, used the 3d hardware to emulate NeoGeo sprites, since the DS couldn't handle as many sprites as the NeoGeo (128 vs 384 per frame, IIRC), but could handle a lot of 3d polygons (6144 vertexes per frame IIRC),
    – ninjalj
    Sep 21, 2016 at 21:27

2 Answers 2


The first notable system to use sprite graphics (Atari 2600) did so because its RAM was nowhere near large enough to hold the contents of an entire display in any kind of bitmap format. Even though it only has 128 bytes of RAM, it can produce a display 160 pixels wide by approximately 200 pixels high (it can go all the way from parts of the screen that are above the top of the bezel, to the parts below the bottom) in 128 colors. By contrast, the RCA Studio 2 has 512 bytes of RAM total, but producing even a 64x32 pixel black and white display gobbles half of that. The Fairchild Channel F has 2Kbytes of DRAM for its display backing store, but even with that is limited to a 102x64 pixel display in 4 colors.

During the 8-bit computer and Nintendo Entertainment System era, it was common for games' backgrounds to be generated using a "tiled graphics" (also sometimes called "character graphics") system which partitioned the screen into 8x8 tiles; for each tile, the display controller would fetch a byte or two of memory and use the fetched values as an index into a collection of 8x8 bitmaps (personal computers would typically fetch one byte and use it to select one of 256 8x8 bitmaps). On some cartridge-based systems, the bitmaps would be stored in a ROM separate from the main RAM; even on computers where they were stored in RAM, changing the contents of a tile by changing a single byte was much faster than having to rewrite the data for an 8x8 block of pixels.

Even after machines got a large enough backing store to handle an entire bitmap display, sprites remained useful because display memory bandwidth was generally rather limited, and about half was generally consumed with hardware-generated fetches to feed the video circuitry. Given that read-modify-write operations required the processor to do some work between the read and the write, the amount of content that could be processed during a frame was limited to about 1/6 to 1/2 of a screen worth of content. By contrast, updating the location registers for a sprite would take almost no time.

In the succeeding years, display memory bandwidth has improved to the point that it's possible to perform multiple full-screen read-modify-write operations in a single frame. There is thus no longer much benefit to having a sprite-based video system merge data from multiple sources on the fly while outputting a video image to the display. In earlier years, however, on-the-fly merging was hugely advantageous.

  • Another advantage of sprites was that they commonly provided collision detection too, which meant that much less to code and keep track of. One ubiquitous use of tiles is character generation for text displays... Sep 20, 2016 at 6:43
  • @StephenKitt: Text displays are indeed a prime example of a tile-map display, though it may be interesting to note that early text displays did not use RAM; the biggest change going from the Apple I from the Apple II was the use of RAM for the text display in the latter.
    – supercat
    Sep 20, 2016 at 14:28
  • Yup, there was a mixture — the 8-bit Ataris supported RAM-based character sets, PCs with MDA or CGA only had ROM-based character sets, etc. Sep 20, 2016 at 14:31
  • 1
    @StephenKitt: Every PC has always used RAM to hold the character selections--just not the character shapes. The Apple II did likewise. The Apple I didn't use RAM for either; the contents of the screen were held in six 1024-bit dynamic shift register chips, plus a seventh for the cursor, which were astonishingly cheap, and had data inputs and outputs that were TTL compatible, but the shift clocks had to be driven hard with weird voltages using high-current drivers since each would have been directly connected to the gates of 1024 PFETs in each chip.
    – supercat
    Sep 20, 2016 at 14:35
  • 1
    To expand on the Atari 2600, it only has 1-color sprites. To get multicolor, there's an instruction that says "wait until the electron beam has reappeared on the left side of the screen." Then you can set the sprite to a different color so when the electron gun has finished painting your sprite, it will appear to be several different colors. A similar technique is used to show more sprites than the hardware supports by moving the sprites around. Both techniques combined are used to display 128-color bitmap images. Later 8-bit consoles could only support 16-64 colors on the screen at a time. Sep 20, 2016 at 22:24

Actually, most of the retro computers I am working with didn't have any fancy extensions to the graphics hardware - They just had simple, plain frame buffer hardware. Dedicated graphics hardware to do fancy things like sprites was expensive, and it had to be custom chips that were even more expensive.

The Sinclair range of computers had a frame buffer and nothing else, and the Atari ST as well (it did get the Blitter chip later on, but that is a rather straightforward memory-move chip with no sprite support whatsoever), and the Acorn and Amstrad computers had pretty straightforward graphics hardware as well AFAIK.

Commodore was in a comfortable situation that they had their own chip factory - Thus it was quite obvious for them to create the VIC as a special graphics chip.

  • 4
    All the Atari computers (including the ST) had sprites ("player/missile graphics" in Atari parlance). The 8-bit Ataris and the Amigas (not surprising, given that Amigas are the true descendants of the 8-bit Ataris) also had a display list, which allowed the display to be constructed programmatically (the Amstrad PCW had something similar). Sep 21, 2016 at 11:12
  • 1
    @StephenKitt Definitely not the ST - The XL computers did have "player missile", as you rightly say, the ST didn't have any hardware support (except the later Blitter chip) for sprites. If you seem to know otherwise, please provide a reference. And the only support for graphics the Joyce and other PCWs had was the so-called "roller RAM" that allowed some kind of full-screen hardware scrolling by changing the start address of the displayed frame buffer. The first CPC to have hardware support for sprites was the CPC+ that hit the market a little (too) late to be of any significance
    – tofro
    Sep 21, 2016 at 11:22
  • Ah yes sorry, sprite support in the ST used line A opcodes and was implemented in software, not hardware. I never said the PCWs had sprites... Roller RAM does allow more than scrolling (by switching row pointers around); but it's nowhere near as powerful as ANTIC, to say the least! Sep 21, 2016 at 11:29
  • The roller RAM in the PCW does allow you to do a lot of things, maybe some of them useful (scrolling or double-buffering just a subset of horizontal scanlines,...) but it's not even close to hardware sprite support like in the C64 (and most of it gave me a headache anyways, when I was working on it).
    – tofro
    Sep 21, 2016 at 11:43

Not the answer you're looking for? Browse other questions tagged .