Inventing the Atari 2600 (1983)(spectrum.ieee.org)
spectrum.ieee.org
Inventing the Atari 2600 (1983)
https://spectrum.ieee.org/atari-2600
49 comments
The player-missile graphics were hardware sprites, albeit more cumbersome to use. So far as I know, sprites as you know them -- reprogrammable two-dimensional bitmaps whose x and y coordinates can be set with hardware registers -- didn't even come about in a non-cost-prohibitive manner until the TI-99/4 in 1979. (Edit: The Intellivision had similar capabilities around the same time. The first Atari 8-bit computers were also contemporary, but used a more advanced variant of the 2600's technology involving per-scanline display lists, which approach would be used also by the 7800.) The designers of the TI-99/4 and TI-99/4A certainly did coin the term "sprite" as it's used in the computer graphics sense.
Even arcade games of the era (late 1970s) tended to use framebuffer displays. The mechanic of the invaders slowly speeding up as they were picked off in Space Invaders (1978) stems from the fact that the fewer invaders on screen, the faster the CPU could blit them all.
Even arcade games of the era (late 1970s) tended to use framebuffer displays. The mechanic of the invaders slowly speeding up as they were picked off in Space Invaders (1978) stems from the fact that the fewer invaders on screen, the faster the CPU could blit them all.
At the same time, the 4a didn't have Vector graphics...you HAD to program with sprites with the included basic.
So much graph paper...so much conversions of binary to hex.
So much graph paper...so much conversions of binary to hex.
The 4A did have a framebuffer graphics mode, it was just not available from BASIC. Vector graphics were thus available in software such as TI Logo II. You could even use sprites with it. Bitmap mode, as it was called, was also used for the graphics in games such as Parsec, where a fast software scrolling routine provided the game's smooth scrolling background.
The 4A was a nerfed machine in general: its powerful 16-bit CPU could only access directly 256 bytes of RAM, with the rest being mediated through the video chip. Its built-in BASIC was both slow, being written in GPL bytecode, and nerfed in that it provided virtually no direct access to the machine's features and actually locked you out of some of them, like bitmap and multicolor mode and even sprites. Extended BASIC got you sprites and some other features, but you still needed the expensive PEB in order to load machine code routines.
These limitations were tragic, as the machine itself was rather powerful even compared to machines from a few years later, and there wasn't much reason to limit it except that TI saw it as a giant version of their calculators and wanted it to be cartridge-driven with only the barest allowable user programmability.
The 4A was a nerfed machine in general: its powerful 16-bit CPU could only access directly 256 bytes of RAM, with the rest being mediated through the video chip. Its built-in BASIC was both slow, being written in GPL bytecode, and nerfed in that it provided virtually no direct access to the machine's features and actually locked you out of some of them, like bitmap and multicolor mode and even sprites. Extended BASIC got you sprites and some other features, but you still needed the expensive PEB in order to load machine code routines.
These limitations were tragic, as the machine itself was rather powerful even compared to machines from a few years later, and there wasn't much reason to limit it except that TI saw it as a giant version of their calculators and wanted it to be cartridge-driven with only the barest allowable user programmability.
The DNOS minicomputer division demanded that the 99/4 be absolutely crippled, so powerful operating systems could not be run on the machine.
I was "lucky" enough to get a 99/4a early on, then a job at Deere converting DNOS systems to Xenix and TI System V on 68000 NuBus.
https://en.m.wikipedia.org/wiki/TI-DNOS
I was "lucky" enough to get a 99/4a early on, then a job at Deere converting DNOS systems to Xenix and TI System V on 68000 NuBus.
https://en.m.wikipedia.org/wiki/TI-DNOS
Holy cow!
That's unfortunate...as a kid in the styx with the documentation that came with the computer by default, I would have loved a little more accessibility to it's capabilities...I couldn't rationalize how it came with a 'powerful 16 bit TMS-9900 processor...but it was pig slow doing anything compared to the 8 bit Apples I was using in school and the graphics weren't great...and 3 months after we paid $350 for ours, they were going for $50 on fire sale.
Yeah, that's the thing, the TMS9900 was a TI-990 minicomputer CPU in a single-chip design. Per another comment, the minicomputer division didn't want competition from a home computer, so they had the TI-99/4A engineers cripple the design in various ways.
But you look at that fast scrolling routine in Parsec, or something like "Don't Mess with Texas" (https://www.youtube.com/watch?v=ZhSUhE03XFw) and you wonder what might've been.
But you look at that fast scrolling routine in Parsec, or something like "Don't Mess with Texas" (https://www.youtube.com/watch?v=ZhSUhE03XFw) and you wonder what might've been.
Yes you are correct. The reason it was designed the way it was, was to eliminate the need for a framebuffer. RAM was very expensive in 1977, but a 6502 running at about 1.2MHz was just fast enough to keep up with the requirements of drawing each line on the fly. It was basically an extreme example of the old 'CPU time vs. RAM space' tradeoff.
> a 6502 running at about 1.2MHz was just fast enough to keep up with the requirements of drawing each line on the fly
/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.
/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.
Back in the day, I saw VCS game developers use two techniques:
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.
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.
> And there's no interrupt so you have to time most of this with cycle counting and polling the timer
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!)
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!)
I dabbled with Atari 2600 game programming. I can appreciate how the frugality of the VCS design put really tight constraints on game devs and in hindsight the VCS could’ve been worlds better if a bit more was invested in hardware. As a game dev on VCS, the kernel of your game loop is essentially drawing each horizontal scanline (on a CRT screen) in realtime, so you have a budget of about 20 assembly instructions (during the hblank at the start of each scan line) to describe what gets drawn on that line as it’s being drawn, including players and missles, and playfield. Then between each frame (during the vblank and overscan) you have a budget of about 30 assembly op codes to detect collisions, change the playfield graphics, adjust the sound, check paddle/joystick inputs, etc. It’s a crazy tight clock cycle budget to work with. I honestly struggled with writing a simple game that could use so few machine op codes per frame, I couldn’t stay in budget so my frames were a mess. I wonder what could’ve been if Atari invested a bit more in giving developers a little bit more to work with. Nintendo NES came out soon after and seemed to learn from Ataris mistakes with the VCS.
>> Nintendo NES came out soon after
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.
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.
The NES came out much later. 6 years later in Japan and 8 years later in the US.
Racing the Beam is an excellent book.
Indeed. https://en.m.wikipedia.org/wiki/Atari_2600#MOS_Technology_65...:
“Over two days, MOS and Cyan engineers sketched out a 6502-based console design by Meyer and Milner's specifications. Financial models showed that even at $25, the 6502 would be too expensive, and Peddle offered them a planned 6507 microprocessor, a cost-reduced version of the 6502, and MOS's RIOT chip for input/output. Cyan and MOS negotiated the 6507 and RIOT chips at $12 a pair“
“Over two days, MOS and Cyan engineers sketched out a 6502-based console design by Meyer and Milner's specifications. Financial models showed that even at $25, the 6502 would be too expensive, and Peddle offered them a planned 6507 microprocessor, a cost-reduced version of the 6502, and MOS's RIOT chip for input/output. Cyan and MOS negotiated the 6507 and RIOT chips at $12 a pair“
The 2600 was designed to be a Pong and Combat machine. Players, missiles, balls, background. Its designers had absolutely no idea programmers would write things like Adventure and Pitfall for it.
Artists very often thrive when constrained.
Programming used to be an art.
Programming used to be an art.
Whenever this topic comes up, some inevitably points to the book "Racing The Beam". Maybe this time I'll be first? :)
https://mitpress.mit.edu/books/racing-beam
https://en.wikipedia.org/wiki/Racing_the_Beam
https://www.amazon.com/Racing-Beam-Computer-Platform-Studies...
It goes in to deep detail on a handful of Atari games, and discusses the tricks and hacks the programmers used. If you're in development now and grew up on these games, it's a great book.
https://mitpress.mit.edu/books/racing-beam
https://en.wikipedia.org/wiki/Racing_the_Beam
https://www.amazon.com/Racing-Beam-Computer-Platform-Studies...
It goes in to deep detail on a handful of Atari games, and discusses the tricks and hacks the programmers used. If you're in development now and grew up on these games, it's a great book.
There's also some good 2600 discussion in Hackers: Heroes of the Computer Revolution. Personally I found both of them sort of middle quality books even though I admit that Hackers is a kind of required reading. I think I was spoiled for all other computer writing by the extreme excellence of Soul of a New Machine. While I'm rambling on the subject I'll give quick shouts out to Where Wizards Stay Up Late and Kernighan's UNIX A History and a Memoir.
How it Happened, The Idea Factory, Dealers of Lightning, The Innovators, and Weaving the Web are still on the to-read list. If anyone has suggestions of which of those to read first I appreciate it.
How it Happened, The Idea Factory, Dealers of Lightning, The Innovators, and Weaving the Web are still on the to-read list. If anyone has suggestions of which of those to read first I appreciate it.
If you're into mainframe systems, A Few Good Men From UNIVAC is pretty interesting.
Also recommend The Friendly Orange Glow, which is about PLATO
Also recommend The Friendly Orange Glow, which is about PLATO
+1 for The Friendly Orange Glow.
Also interesting: Konrad Zuse's "The Computer, My Life".
Also interesting: Konrad Zuse's "The Computer, My Life".
"Whenever this topic comes up, some inevitably points to the book "Racing The Beam". Maybe this time I'll be first?"
You beat me to it :)
I had an 18-month-old and a newborn and our lives were completely upside-down ... and I could not put that book down.
At 4am ...
You beat me to it :)
I had an 18-month-old and a newborn and our lives were completely upside-down ... and I could not put that book down.
At 4am ...
I had the same situation, but the book was the Masters of Doom.
Masters of Doom was similar for me - hard to put down. I seem to remember a sense of drama and a story arc. Racing the Beam was not in the same style of writing, but was still entirely fascinating to me.
The Atari age (late 70s - mid 80s) was my 'golden era' and RtB gave so much tech detail and explained the 'magic' I remembered. The doom era was... a bit beyond me. I played it a bit and I was impressed with what I saw at the time, but was working 3 jobs while going to college, so never got immersed in that world.
The Atari age (late 70s - mid 80s) was my 'golden era' and RtB gave so much tech detail and explained the 'magic' I remembered. The doom era was... a bit beyond me. I played it a bit and I was impressed with what I saw at the time, but was working 3 jobs while going to college, so never got immersed in that world.
I always like to mention ZeroPage Homebrew too. It's a Twitch channel that usually streams twice a week that features homebrew games for the 2600 and recently branched out to other Atari consoles and 8-bit systems. The devs for the games are usually in the chat. It's my absolute favorite community on the internet today.
You beat me by 18 hours.
> It is popular today, not because it does an admirable job of playing Jet Fighter and Tank, but because its flexible design also allows it to play chess and baseball, as well as Space Invaders, Pac-Man and many of the other arcade games that have been invented since the VCS came on the market.
Yeah, the original Pac-Man on the Atari 2600 sucked, and has nothing to do with why it's popular today. Any of the Atari 2600 baseball games of its era also sucked.
> its flexible design
The only thing "flexible" about the Atari's video chip, the TIA, is that you can choose what to do with each scan line. Too bad you are so limited on what you can actually do on that scan line and need insane tricks to get things like 48 useable 160x200 resolution pixels in a row for score display. On top of that, you only have 128 bytes of RAM.
It's fun to program if you like constraints, but programmable sprites, nametables, and sound channels that can play musical notes might be considered funner.
The Atari 2600 has great charm because so much was done with something so primitive, and it's awesome to see new games developed with it with increased RAM and mapper chips. A new chess game But hardware with better capabilities may have been just as popular if available for $199 in late 1970's dollars. Arcade games of the time with much more flexible display hardware were also popular.
Yeah, the original Pac-Man on the Atari 2600 sucked, and has nothing to do with why it's popular today. Any of the Atari 2600 baseball games of its era also sucked.
> its flexible design
The only thing "flexible" about the Atari's video chip, the TIA, is that you can choose what to do with each scan line. Too bad you are so limited on what you can actually do on that scan line and need insane tricks to get things like 48 useable 160x200 resolution pixels in a row for score display. On top of that, you only have 128 bytes of RAM.
It's fun to program if you like constraints, but programmable sprites, nametables, and sound channels that can play musical notes might be considered funner.
The Atari 2600 has great charm because so much was done with something so primitive, and it's awesome to see new games developed with it with increased RAM and mapper chips. A new chess game But hardware with better capabilities may have been just as popular if available for $199 in late 1970's dollars. Arcade games of the time with much more flexible display hardware were also popular.
It was definitely a minimum viable product, but:
2600: US$190 in 1977, sold 30 million units as of 2004.
Colecovision: $175, 1982. 2 million units sold.
Intellivision: US$275 in 1979, sold 3 million.
Pac-Man for the 2600: 1982, 8 million units sold.
The 2600 was discontinued after the technologically-superior Intellivision and Colecovision were discontinued. The Colecovision cost less than the Atari when it came out and still couldn't move more consoles than Atari moved copies of Pac-Man.
Technically I guess the Intellivision and Colecovision were competing with the 5200 (1982, $270, 1 million sold) but none of them lasted more than a couple of years, versus the 2600 finally going out of production for good in 1992.
(All data from Wikipedia except for the Coleco and 5200's launch prices, which came from an IGN page listing launch prices.)
2600: US$190 in 1977, sold 30 million units as of 2004.
Colecovision: $175, 1982. 2 million units sold.
Intellivision: US$275 in 1979, sold 3 million.
Pac-Man for the 2600: 1982, 8 million units sold.
The 2600 was discontinued after the technologically-superior Intellivision and Colecovision were discontinued. The Colecovision cost less than the Atari when it came out and still couldn't move more consoles than Atari moved copies of Pac-Man.
Technically I guess the Intellivision and Colecovision were competing with the 5200 (1982, $270, 1 million sold) but none of them lasted more than a couple of years, versus the 2600 finally going out of production for good in 1992.
(All data from Wikipedia except for the Coleco and 5200's launch prices, which came from an IGN page listing launch prices.)
Weren't a lot of those Pac-Mans for the 2600 pack-ins?
While the Atari 800 and Amigas are my favourite systems, I'm not a fan of the Atari 2600. I'll take the Mattel Intellivision or Coleco ColecoVision any day.
The only 2600 game I liked was Frostbite but it's available on the Commodore 64 now so...
While the Atari 800 and Amigas are my favourite systems, I'm not a fan of the Atari 2600. I'll take the Mattel Intellivision or Coleco ColecoVision any day.
The only 2600 game I liked was Frostbite but it's available on the Commodore 64 now so...
[deleted]
Ms. Pac Man, on the other hand, is fantastic on the 2600. It looks a lot like the same bad game, but it plays very close to the arcade.
I was always really impressed by Space Invaders on the 2600. About as faithful a port as you could get imagine with solid graphics and sound effects, appropriate levels of difficulty, and lots of options. I played the hell out of it.
IIRC, it was because they opted for 8k ROM instead of 4k (or perhaps 4k instead of 2k?). Whatever the choice, it was definitely a big difference.
I'm a little disappointed that they keep referencing the "Stella chip". They're referring to the Television Interface Adapter[0] (TIA), ancestor of the custom chips that ended up in the Atari 400/800 and the Amiga.
[0] https://en.wikipedia.org/wiki/Television_Interface_Adaptor
[0] https://en.wikipedia.org/wiki/Television_Interface_Adaptor
It’s easy to get confused about that. Reading https://en.wikipedia.org/wiki/Atari_2600, the code name for the Atari 2600 was Stella.
There also was a “Stella Programmer’s Guide”, which discussed how to program the TIA (https://cdn.hackaday.io/files/1646277043401568/stella.pdf)
There also was a “Stella Programmer’s Guide”, which discussed how to program the TIA (https://cdn.hackaday.io/files/1646277043401568/stella.pdf)
It's really neat to trace the origin of those custom chips. Descendants of the TMS9918A chip found in the TI-99/4A could be found in systems at least as late as the Sega Genesis.
Correct, it was the project that was codenamed Stella by Joseph Decuir after his Stella bicycle.
You can see some recent homebrew games for the Atari 2600 here. All are pretty impressive given the limitation of the hardware.
https://www.youtube.com/c/AtariAge/videos
https://www.youtube.com/c/AtariAge/videos
The 2600 even has a thriving demoscene, with prods like this: https://youtu.be/04Wk9Oi_Fsk
Always interesting to see how small things make cool effects (even though any detail of "this small thing is actually really really tricky" is lost on me, lacking knowledge of the platform)
Also worth mentioning is Jax uses some atari code in their py files.
Disambiguation:
https://www.cs.toronto.edu/~vmnih/docs/dqn.pdf
> "Of course, no one knew that he only had one barrel to his name," recalls Steve Mayer
Elsewhere, Chuck Peddle claimed only the chips on the top of the barrel worked. The rest underneath were duds.
Elsewhere, Chuck Peddle claimed only the chips on the top of the barrel worked. The rest underneath were duds.
Restriction has always been a engine for innovation.
needs tag [1983]
[deleted]
That's some rose-coloured glasses right there if there ever were any.
"You know, we COULD give this thing hardware sprites, independent video and audio chips!" "No! Think of the game programmers! They thrive on constraint!"
My money is on the money.. The cheapest design that still allowed (the best programmers to make) reasonably good games.
That said, the system was enjoyable to play when I was a kid, and it's enjoyable to read about now, great article!