5 ms·

Amazing and well-detailed video - kudos to Tom! One question - what, if any, is the difference between the NES's PPU (Picture Processing Unit) and today's GPU?

by smaili 10y ago

white-flame 10y ago
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]
wtallis 10y ago
The most significant difference between a graphics processor like the NES PPU and a modern GPU is that the PPU didn't have a frame buffer. There wasn't enough memory to keep an array of the color of each pixel on screen. The PPU worked instead with sprites and background tiles and color palettes and indexes into those tables. The PPU's job was to composite the scene on the fly while keeping pace with the scan-out to the CRT: the pixels' values were computed in order and just in time for the electron beam to draw them, one pixel being generated per clock cycle. It didn't have the time or memory or programmability to do any fancy 2D effects or transformations, let alone 3D.
- Pulcinella 10y ago
  In terms of 3D SNES graphics, the few later games that did support 3D graphics (e.g. Starfox) had an "enhancement chip" built into the game cart that allowed for it. And by "enhancement" I mean the SuperFX chip basically ran the game and the SNES just provided power and A/V out.
  - seeekr 10y ago
    How was it economically viable to, iiuc, basically include computational power comparable to that of a full console, inside every single game cartridge? That sounds ludicrous! (Starfox on SNES was an excellent game, enjoyed it very much!)
    - gambiting 10y ago
      Well, the CPU they added was probably far less than $1/each when bought in bulk, so if you were making a PCB with chips on it already, you might as well add an extra processing unit.
    - tinus_hn 10y ago
      For one thing, it's the ultimate form of copy protection.
      - planteen 10y ago

Amazing and well-detailed video - kudos to Tom! One question - what, if any, is the difference between the NES's PPU (Picture Processing Unit) and today's GPU?

by smaili 10y ago

Amazing and well-detailed video - kudos to Tom! One question - what, if any, is the difference between the NES's PPU (Picture Processing Unit) and today's GPU?

white-flame 10y ago

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]

wtallis 10y ago

The most significant difference between a graphics processor like the NES PPU and a modern GPU is that the PPU didn't have a frame buffer. There wasn't enough memory to keep an array of the color of each pixel on screen. The PPU worked instead with sprites and background tiles and color palettes and indexes into those tables. The PPU's job was to composite the scene on the fly while keeping pace with the scan-out to the CRT: the pixels' values were computed in order and just in time for the electron beam to draw them, one pixel being generated per clock cycle. It didn't have the time or memory or programmability to do any fancy 2D effects or transformations, let alone 3D.

Pulcinella 10y ago
In terms of 3D SNES graphics, the few later games that did support 3D graphics (e.g. Starfox) had an "enhancement chip" built into the game cart that allowed for it. And by "enhancement" I mean the SuperFX chip basically ran the game and the SNES just provided power and A/V out.
- seeekr 10y ago
  How was it economically viable to, iiuc, basically include computational power comparable to that of a full console, inside every single game cartridge? That sounds ludicrous! (Starfox on SNES was an excellent game, enjoyed it very much!)
  - gambiting 10y ago
    Well, the CPU they added was probably far less than $1/each when bought in bulk, so if you were making a PCB with chips on it already, you might as well add an extra processing unit.
  - tinus_hn 10y ago
    For one thing, it's the ultimate form of copy protection.
    - planteen 10y ago