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.

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.

> And by "enhancement" I mean the SuperFX chip basically ran the game and the SNES just provided power and A/V out.

Sorta—there was no direct video out from the cartridge on the SNES (though oddly enough, there were audio out pins), so the Super FX chip had to actually generate sprites on the fly for the PPU to composite together. This resulted in unfortunate color limitations.

You can see in the debug info for Star Fox 2 that the dynamically allocated sprite count was something that they had to constantly keep track of: https://r.mprd.se/fup/up/35454-Star_Fox_2_(Japan)_(Proto)_(A...

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!)

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.

For one thing, it's the ultimate form of copy protection.

But most cartridges used the same design. So if you had one SuperFX cartridge, you could put it in your copiers cartridge slot and then play all the others.

That was true of the DSP-1, but not true of the SuperFX or SA1.

The DSP-1 was a preprogrammed microcontroller that preformed certain calculations that would have been inefficient to preform on the SNES CPU. The inputs were written to a memory mapped location, and the outputs read back. An interposed copier could simply redirect these reads and writes.

The SuperFX and SA1 used the cartridge's ROM and RAM for program and data, and therefore these enhancement chips are placed between the SNES bus and the cartridge memory. The cartridge memory is unavailable to the SNES bus while the enhancement chip is executing, as in the SuperFX, or the the enhancement chip enters wait states while the CPU is accessing the cartridge memory, as in the SA1.

Ah gotcha. My memory is getting hazy. I had a floppy disk copier many years ago and remember using Mario Kart to play other games. I thought it was SuperFX but I was wrong.

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]