The NES had 16 times Atari 2600’s work RAM, plus a different way to draw
A like-for-like RAM comparison gives 2,048 bytes against 128. Dedicated NES picture hardware explains why the display leap needs more than that ratio.
The Atari 2600 could keep its working state in 128 bytes.
The NES supplied 2,048 bytes of work RAM, plus separate picture hardware and memory. The distinction matters if you are tempted to reduce a generation of games to one multiplication problem. Atari’s Stella programming guide describes generating the display by supplying data in time with the television. Programs changed display settings in time with the television beam. The NES hardware reference lists its work RAM separately from its video RAM.
| Resource | Atari 2600 | NES |
|---|---|---|
| Work RAM | 128 bytes (hardware documentation) | 2KB, or 2,048 bytes (hardware documentation) |
| Separate video RAM | No framebuffer (hardware documentation) | 2KB (hardware documentation) |
| Work-RAM ratio | 1 | 2,048 ÷ 128 = 16, calculated |
The table deliberately keeps work RAM against work RAM. Folding NES graphics storage into one side would produce a bigger, less useful headline.
Atari’s original Stella programming guide locates those 128 bytes in the PIA chip. It describes variables growing upward from one end of the area while the processor stack grows downward from the other. Keeping both in the same small space meant a programmer had to consider their combined demand. A memory total that fits on a single line in a table could still involve two things approaching each other inside it.
The Stella guide also makes the display work explicit. The program waits for the television’s horizontal synchronization and supplies values for the objects being drawn. Without a full-screen image waiting in memory, the timing of those writes becomes part of the picture the viewer sees.
The NES has its own split to respect. Its hardware memory map separates CPU work RAM, picture memory and sprite attributes. Cartridge memory occupies other parts of the map, so the console’s built-in working area never describes every byte available to every game. A cartridge can change the resources a particular title uses without changing the base machine’s RAM figure.
That helps explain why shrinking a game’s data would only begin a port. The destination also decides how that data reaches the display. A display routine that assumes one machine’s registers cannot acquire the other’s behavior by fitting into a smaller buffer. The work has to be scheduled in the form the target hardware accepts.
For someone comparing the machines through emulation, the revealing experiment would track one moving object. Watch the position stored in working memory, then follow the writes that put it on screen. The sixteenfold ratio remains correct, but the debugger would show the separate obligations hidden behind the same word, graphics.
A side-by-side port would show where the architecture changes the code most. The interesting measurement would be what the programmer must schedule, beyond how many bytes fit.