GPUs deal with rendering to framebuffers. Old school graphics chips didn't have the memory to hold an entire framebuffer (memory was expensive!), nor the speed

GPUs deal with rendering to framebuffers. Old school graphics chips didn't have the memory to hold an entire framebuffer (memory was expensive!), nor the speed to clear & repaint a full framebuffer at 60Hz, so they'd generate the pixel colors for each screen location on the fly in real-time as the raster scanned the CRT picture, from tile-based graphics definitions and a bunch of registers that controlled positions, scrolling, and other properties of a generally fixed set of graphics capabilities. Many game consoles gave their video chip its own internal memory, so the CPU would hit memory mapped I/O ports to set registers, like palette values or the position of sprites.* At each line (or character, or however it's timed), the video chip would read the current value of the palette & graphics bitmap data and stream it out the analog video generator pixel by pixel in sync. Multiple layers (SNES, etc) or sprites would all be read "live" per scanline, and the chip would decide, based on transparency & priority, which object's color would be visible for that final pixel output. Graphic screens were usually a grid with a byte per "tile" or "character", often an 8x8 pixel chunk, which offers a form of dictionary compression. The tile ID byte + tile gfx dictionary (gfx were usually 1-4 bits per pixel, for 256 8x8 pixel tiles) + palette info constitued the screen graphics formats, with a similar setup for independently movable sprites. Many effects could be achieved by having the CPU change registers mid-way down the screen. It can do color gradients by updating the palette every line, change tile or scroll definitions for different sections of the screen (like having a non-scrolling score/inventory section, then flipping to scrolling graphics for the other part of the screen). Many video chips signaled CPU interrupts at configurable scanlines, or allowed the CPU to set up display lists which had address/value/screen-location tuples that it would execute as it drew the screen. Because all of this was real-time generated, most games were 60fps. If there was too much going on in some frame then graphics were simply lost or ended up in the next frame with wild visual glitches because the timed gfx changes happened at the wrong time & place. Nowadays, GPUs paint a framebuffer, and display that framebuffer when it's done being drawn, yielding variable frame rate. Some non-action games did that back in the 80s as well, and it was often slow enough to see each step of the image being drawn. [* = most home computers held gfx and palette info in their "large" main memory, with the video chip having exposed configuration registers on the memory bus, instead of tunneling through I/O ports]