I wrote an NES emulator. There's a background color, a scrollable background tile-map[0], and 64 hardware sprites, which can each be drawn either on top of or b

I wrote an NES emulator. There's a background color, a scrollable background tile-map[0], and 64 hardware sprites, which can each be drawn either on top of or below the background. The hardware itself doesn't even contain a framebuffer; calculating palette effects and compositing the background and sprite layers into a final image is done by the hardware in realtime, 1 pixel at a time, and fed to the video output pin. However, many game cartridges actually had RAM to store their graphic tiles in, rather than a set group of tiles in ROM. Graphics would be stored within the program code and transferred byte-by-byte into the PPU's (Picture Processing Unit, aka the GPU's) memory space. Legend of Zelda worked this way, along with a lot of other well-known games. Look at Elite for an example of the NES emulating a framebuffer using that method to render 3D polygons: https://www.youtube.com/watch?v=zoBIOi00sEI https://www.youtube.com/watch?v=zoBIOi00sEI [0] The background has 4 screens worth of area in a 2x2 screen grid, and increments addresses during rendering to simulate a toroidal memory space, allowing for smooth scrolling. This is a (perhaps overly) simplified explanation; things are slightly more complicated.