> "It's awesome to be credited with single-handedly bringing down a billion-dollar industry with eight kilobytes of code. But the truth is a little more complex."
Eight kilobytes?! How do you build anything meaningful, especially a game, with just eight kilobytes?
Get a copy of Racing the Beam to get some insight into how programmers were able to wring out every bit[1] of potential from the Atari 2600: https://mitpress.mit.edu/books/racing-beam
I tried running it back then - the textures, the music, the models, all of the content is generated "from scratch", which is why it takes forever to start, it has to create all content first
- In 2600 coding you often don't need a stack, so you can use 'S' as a temp register. Very useful in the display kernel.
- The 2600 has a standard parallel port chip. There are configuration registers (e.g., port direction) that can be temporarily hijacked as RAM, when you don't care about input or output (which you generally only sample once a frame). That's a whole 8 more bits of RAM, not to be sneezed at.
One of my cow-orkers at Atari decided that he'd try to learn 2600 programming (he was mostly doing Atari Home Computer stuff). Over three or four months I saw him go through what I can only describe as deterioration and utter discouragement. The people who could get even an awful game out of the 2600 were pretty damned good hackers.
8K is 8192 bytes. Atari runs on MOS 6502, for which each instruction takes up between 1 and 3 bytes. This gives you about 2K instructions, give or take (you probably want to make space for some data). Given how simple most atari games are, I think you could reasonably get away with 1-1.5K instructions for code if you hand-write the assembly and optimize for size.
Actually, the Atari 2600 runs a 6507 which is a cheaper version of a 6502. Unlike the 64kbytes a 6502 can address, the 6507 is limited to 8kbytes. Worse, the cartridge design limited you to 4kbytes unless you bank switched.
But that was storages, which was huge compared to the 128 bytes of RAM. Further complications happen because you need to time things with the scan lines of the display.
Eight kilobytes is plenty of space. How about doing something meaningful in 128 bytes (yes, bytes!): https://www.youtube.com/watch?v=cD49RXnEGNE - it's a mouse-controlled 3d Wolfenstein-like maze. All with the code about half the size of this comment.
It doesn't even have a screen buffer, just a half a line buffer. You have to count scan lines and keep track of what's being drawn on a cycle by cycle basis, then update the line buffer live to get what you want on screen.
Eight kilobytes?! How do you build anything meaningful, especially a game, with just eight kilobytes?