There was no framebuffer in those consoles [1]. So you pretty much only have to store game state and some auxiliary data in those 128 bytes, which starts sounding a lot easier.

[1] https://en.wikipedia.org/wiki/Television_Interface_Adaptor

Look up 'racing the beam' if you haven't before. The answer is... you can't! It didn't have a frame buffer and lines had to be written to the display one at a time. There was a lot of sprite flicker as many games had more on screen than the console could actually display in one frame.

It's basically only the state in the RAM, the game code is in ROM on the cartridge (you can have up to 4KB of ROM before have to rely on bank switching tricks). Video on the 2600 is weird, there isn't any video memory to speak of, you basically set up the video chip line by line in code.

The program and assets are stored in a ROM cartridge, so only mutable data needs RAM.

Actually drawing things on screen depends on two things:

The first is racing the beam. The display output traces across the entire screen at 60Hz, one scanline at a time. At no point does a complete image exist, instead you just make sure to apply changes so that the machine can draw what needs to be drawn just before the beam traces that part of the image. You will need to cycle count so that your program takes exactly the right time to execute every section, because you certainly won't have time for interrupts or other synchronization.

The second is using dedicated hardware, where you store the location on screen, color and memory address of a sprite, and the hardware draws it for you. There are a very limited amount of sprites available, which limits the amount of things that can happen in a single line.

Great video [1] on how some clever tricks are used to stay within memory constraints.

[1]: https://www.youtube.com/watch?v=sw0VfmXKq54

There is no frame buffer. The graphics are all drawn by manipulating a few registers in the video chip.

Everything is scan lines and cycles. You get a one bit per pixel 40 pixel wide background, a couple of single color 8 bit sprites and a couple more two bit wide sprites and that is pretty much it. A lot can be done by simply changing a color register at specific times too. Reusing sprites happens regularly as well. (Sprite drawn at left of screen can be repositioned to the right to be seen again. That is the "racing the beam" part you may have heard people mention.

Most of the CPU run time available for each frame is spent generating the display a scan line at a time.

The real game happens during the vertical blanking period.

Almost everything comes from ROM, leaving ram for game state and the few objects that may need to be dynamic, and even those are in ROM when there is room for all the states.

It is an odd feeling when you run out of room. The phrase, "I used every BIT of RAM" is literal! Happened to me once. No more bits and I had to either leave out a feature, or take a speed penalty by packing multiple states into single bytes.