/Just/ fast enough. One can actually emulate a normal framebuffer on the 2600 if there's extra RAM on the cartridge. Or display a bitmap image from ROM. Since the 2600 can only draw from shift registers, including two 1-bit tall by 8-bit wide "sprites", one has to position the sprites to interleave, and then load the correct byte values into the shift registers, the exact cycle before it's clocked out to the display. There are 76 cycles during a scanline, and without self-modifying code it takes a minimum of 8 cycles to do the right kind of load-store for a single sprite. Add some accounting overhead, and there's just enough time to do this 6 times per line, giving a practical resolution of 48 pixels horizontal. (My attempt has 5 cycles spare in the main loop, IIRC.)
One can double the 48 pixels further by interlacing. Switching between two frames offset by one pixel, yielding an effective 96 x 96 pixels when motion-blurred together. This is the technique by which the high-resolution title screens of some later and homebrew games are displayed.
The processor is lock-stepped with the CRT beam the whole time. It runs the loop of load/store instructions typically 192 times for each of the 192 scanlines drawn. A hard real-time obligation 60 times a second that uses 70% of your CPU time. Any game logic or calculations, detecting the controller inputs, etc. must be left to the short vertical blanking interval. And there's no interrupt so you have to time most of this with cycle counting and polling the timer.
I really don't know how the wizards did it back in the day, without the excellent emulators available today. I found rewinding and single-stepping the 'hardware', comparing the TIA's registers with the scan cycle step-by-step, to be essential for getting it to display basically anything. Developers in the 70s just got an Atari 2600 motherboard with RAM or EEPROMs. No debugging tools per se, really.
Cycle counting is pretty important, but there is the WSYNC register to pause the CPU until the next Horzintal Blanking time. (Of course, this was patented and Nintendo avoided it in the NES/Famicom, although some mappers had a similar thing (and interrupts!)
1) they would start with a working kernel from an existing game, and incrementally modify it to create a new kernel for a new game.
2) they would code 2-dimensionally on large sheets of graph paper, where each cell corresponded to both a 6507 CPU cycle and a portion of the horizontal scan line.
By writing out the instructions this way, they could visually check that the code would execute at the correct time.
Not really true. The Famicom(identical tech specs to the NES) was released in 1983 while the VCS came out in 1977. There's also a big difference betwen 2KB of ram plus 2KB dedicated video vs. the 128 bytes of an Atari 2600.