> with instruction- and register-level hacks to save the 128 bytes of memory, with no source control aside from sneaker net, how many developers can reasonably work on it at the same time? 1? 2?
I don't know from first-hand experience, but my impression has always been that the main game loop would be virtually impossible to develop as a team effort.
To give a bit of back story for those that are unaware, the 2600 did not have a frame buffer for storing the current contents of the screen. To save memory, what it did instead is use a line buffer. This was a small amount of memory on the graphics controller chip (Stella) that it used (in combination with some minimal sprite logic) to render the current scan line on the screen. To display anything other than vertical stripes on the screen, the CPU had to update the line buffer and sprite registers for every change. (This is why you see vertical stripes when the 2600 crashes... the CPU isn't updating Stella, so it just keeps rendering one scan line for the whole screen.)
The other consequence of this line-buffer design is that to execute, the CPU had to run in lock step with the display update process. Developers had to know how many CPU cycles it took to render a line and frame of the screen, and write code that executed in just that many cycles. Otherwise, the CPU's display update would happen out of phase with the refresh process and you'd wind up with garbage on the screen. It is hard for me to imagine how a team of two developers could collaborate on such a small and sensitive section of code.
Another way to look at this is that developers that programmed the 2600 were almost working as hardware designers more than software designers. The 2600 CPU was essentially a super-complicated state machine sitting aside the graphics update logic. (Later Atari PC's offloaded display update to a separate chip called Antic that could pull data from a frame buffer, etc.)