Atari 2600 Service Manual [pdf] | Hacker News Reader

Atari 2600 Service Manual [pdf]

console5.com

79 pointsgrunthos19 comments

I used to love playing my family Atari 2600 as a 5 year old kid. Here’s the same Atari, 40 years on (in original condition) being played by my own 4 and 5 year old kids! https://twitter.com/sunpazed/status/1332832920101240833

40 years? How many controllers have you broken/replaced?

Great games are still being made for it [0] and there’s an awesome show called ZeroPage Homebrew [1] that streams twice or more a week. They exclusively play homebrews for Atari systems and the developers are often in the chat.

[0] https://atariage.com/store/index.php?l=product_list&c=24

[1] https://atariage.com/forums/topic/276956-zeropage-homebrew-t...

you should try "Secret Collect." https://atariage.com/forums/topic/338131-secret-collect-home... and "Myst" https://atariage.com/forums/topic/338659-myst-homebrew-proof... which both came out this past month

The thing I found fascinating about this machine is it has no video RAM at all. I couldn't initially understand how it could possibly work without a frame buffer. What it does is you have to redraw the screen dynamically on every frame with precise timing in sync with the sweep of the CRT beam. It also has little memory generally. There's no dedicated RAM chips, there's 128 bytes (not kilobytes) on the PIA you can use and that's it.

Basically you have some CPU cycles in the "horizontal blank" part of each line that you can use to change chip registers for that line.

The TIA had some delay bits/latches so you could write player 1 data and player 2 data on alternate lines, but with one delayed so they'd appear on the same line.

Your actual game code was expected to run in VBLANK.

You can of course alter registers while the line is being drawn, if your timing is precise and your data is prepared, and that's the basis of doing advanced things like 6 digit scores and non-symmetrical playfields.

There were other computers from that era that did the same thing but the 2600 did it more elegantly:

https://www.timexsinclair.com/computers/sinclair-zx80/

And the Apple-1 which is also a very elegant solution to the same problem but without some of the drawbacks (it does have video memory but the CPU isn't slowed down much):

http://forum.6502.org/viewtopic.php?t=1352

Viewed from today, both the ZX80 and the 2600 are very limited, but viewed from either machine, not the same thing, IMO.

The ZX81 used the CPU for generating the video signal, but it had a character ROM (small, of course. https://en.wikipedia.org/wiki/ZX80_character_set), used its copious (ha!) memory for storing data for the entire screen, and shipped with the necessary software so that it, when left alone, would show the contents of the current screen without aid from the currently running program.

IIRC, ZX80 video memory wasn’t a width × height matrix, but more like in a text file, with a special byte value separating lines, making empty lines cheap (you only needed to store the EOL token), and left-aligned text cheaper than right-aligned text, memory-wise (leading spaces ate into memory use, trailing ones needn’t be stored). The system needed that because that memory came from your one kilobyte of RAM. Filling the screen would use a large fraction of available memory)

Also called „racing the beam“, like the highly recommended book.

If you’re interested in a quick writeup with some pointers to reference material and sample code, check out my post: https://blog.classycode.com/the-atari-2600-a-personal-journe...

You might enjoy it.

You have an extra 8 bits in the PIA's I/O port direction register. If you're not using inputs right now you can use that as temporary memory. It's not like the joystick cares if it's getting a little backwards current.

Oh, there are lots of tricks. And when the tricks run out, you run on desperation, you rewrite your display kernel for the fifth time, to get 8 precious cycles back just before the score line. Victory is sweet.

I had a cow-orker (we were both out of the 8-bit computer games division) who decided it would be good for his career (at Atari) to learn 2600 game programming. He got a Stella devkit, a copy of the same dev documentation that has been published everywhere (that's all that anyone got at the time), and over the next four months or so I watched him slowly go mad. I'm not kidding, his mental state was terrible. About then Jack Tramiel bought the company and we all got to work on different stuff, yay.

The 2600 hackers over in Consumer games had a reputation for being pretty wild and unhinged. I am half serious when I say that it was the machine that did it to them.

There are also three bits available in Port B of the RIOT, which controls the front panel. I don't know of any real world examples of ROMs that make use of it but if you ever desperately needed an additional boolean value then it would come in handy.

It does have video RAM, at least sort of. There's about 20 registers on the graphics chip that control the display of the playfield bits and sprite objects. They hold the values persistently until rewritten, so in a way that is functioning as video RAM, just not as a bitmap, and it holds a one-dimensional scanline rather than a two-dimensional frame.

Another way of looking at it is that the video "RAM" is actually the phosphor on the display screen, persisting each scanline when written until refreshed on the next frame.

> a one-dimensional scanline

And iiuc it's only abt 40% of the line. You have to update it during the line! and sometimes it's fwd and sometimes bkwd so you can't simply let it repeat a simple pattern!

I don't know where you're getting that from. You can indeed leave all the registers alone and it will repeat whatever is there for any number of scanlines until you do change it. In fact, this is what happens if you power up the 2600 without a cartridge - you see vertical stripes, because whatever garbage was in the registers on powerup just stays there and repeats onto every scanline, with no software changing it.

"Sometimes forward and sometimes backward" would only apply to the three registers of playfield bits, and is fully controllable by software, in the CTRLPF register.

I'm sure they're talking about manipulating a single line and the fact that you're extremely limited by the behavior of machine for that particular line. Anything that doesn't fit within the hardware design constraints needs mid-line changes and/or clever hacks and, even with those, what you want to output might just not be physically possible.

Don't flowcharts suck? They are bad enough when you have Visio or whatever to help you copypaste through the busywork, but in the old days they had to put them together with one of these toys:

https://www.ecosia.org/images?q=plastic%20flowchart%20templa...

I'll tell you how to service an Atari 2600, though. Even in 1982, chuck it in the dumpster and head down to K Mart for a new one. Put that in a flowchart.

Lol a new Atari was $200 in 1982 dollars, so if it could be serviced it'd probably be worth it then. The cheapo $50 ones didn't come out until '86 or '87 I think.

Not to mention that cost/money is not the only reason to repair something and continue using it. This "throw it away and buy a new one" disposable everything mentality has led to problems like a freakin' giant garbage patch out in the middle of the ocean, and micro-plastics nearly everywhere imaginable. Humans are planetary cancer…

Did this manual ship with the console? Or was it just for repair guys?

Reply on news.ycombinator.com