Atari 2600 - a newcomer's perspective

Hardware
,
1

This is an interesting and moderately technical take, from Steve Chamberlin at Big Mess o’ Wires:

Atari 2600 Hardware Design: Making Something out of (Almost) Nothing

This wood-grained block of electronics preoccupied my young mind. I wanted one badly, but never succeeded at convincing my parents. I was eleven years old in 1982 when my friend Fred got an Atari, and I was sick with jealousy:

Includes:

  • Atari 2600 Hardware Overview
  • Inside the TIA Chip
  • Atari Hardware Tricks
  • Atari 2600 Development Today

See also
Inventing the Atari 2600

5 Likes
2

Somewhat related, I commited to “racing the beam” for RetroChallenge 2018, my first Atari VCS/2600 project ever. As it was RetroChallenge, there’s also a blog, meant to introduce inquisitive audiencies to the wonders of the VCS.

Epsisode 1 is somewhat similar to this article, subsequently followed by a diary of me stumbling along towards what eventually became a finished game
(Also, some eductional content, like tables for the various registers, their addresses and settings, and some famous algorithms to deal with these registers in ways they were never intended for.)

(You can even play the game there with a partner. It’s a two players game and there’s a twist to it, as you can manipulate the refraction/deflection angle of the missile by pulling the joystick left or right, as is goes through the barrier next to your opponent. Also, avoid the nasty bouncer. The game is explicitly designed for hilarious mishaps, as a two-player game ought to be.)

2 Likes
3

Back then you could get a chip designed for a resonable cost. That must have extended the life of all the 8 bitters, by several years.

4

Apropos of chip costs, the TIA has a little over 6000 transistors, and the 2600 sold in quantities of several tens of millions, well ahead even of the C64. The economies of scale combined with small chip size are very much a winner.

(If I were designing something at all similar now, I’d look at the RP2040, in stock at £0.88 each - which gives you several million transistors, and enough processing power to emulate an entire 8 bit machine (video, technical talk). A custom chip wouldn’t make economic sense, and isn’t needed.)

5

Well FPGA,s have taken over the Custom chip market, So I tend to agree.
For my retro computer design, using cheap 2nd hand FPGA devlopment cards
is better than a full home brew system as I can experiment on good days, with
lots of ideas.

6

The TIA’s design for low transistor count is what makes Atari VCS programming “interesting”:

One of the means to achieve the low transister count was using linear-feedback shift register (LFSR) for the horizontal postion counters (what replaced the counter chains of early video game hardware). On the one hand, this saved a few transisters, on the other hand, these LFSRs are not progressing linearly, but over a pseudo random order.

While there’s still a unique match for each sprite positions and a given screen pixel, we, as a programmer, can’t just tell TIA chip where to place the sprite. Instead, we have to tell the TIA, “now”, and the TIA will latch the counter value. The problem being, the TIA runs at 3 times the clock speed of the 6502 CPU. (It actually clocks the CPU at every three TIA “color clocks” and the 6507 is actually a “slave” [sorry for the term, but I really don’t know a better one in this context] to the TIA. This not being in control of the CPU is also the reason, why we can tell the TIA to put the CPU to sleep until it reaches horisontal sync, in order to synchronize the program with the screen. It is really the TIA, which is in control.) Anyways, the CPU runs at a third of the speed of TIA and we have to wait for a position, with the tightes loop in 6502/6507 code amounting to 5 CPU cycles or 15 screen pixels. Oops.

However, there is also the equivalent of the slipping counter chains of early video games with a stop code of 7, meaning, we can displace a sprite by up to 7 pixels to the left or right, in order to fine adjust the position at up to 15 pixels. Which matches somewhat fortunately the granularity of our 6502/6507 tight delay loop. There are even registers for this, which actually accept somewhat sane vales. (They are only shifted right by 4 bits, in the high nibble. In contrast to this, the bytes for the “fat” backround pixels are not in sequential order. But this saves a few other transistors.) We “only” have to deduce the suitable offset to our coarse postion resulting from the wait loop…

The other way the TIA saves a lot of transistors is by not “knowing” anything about vertical positions, screen extend and refresh. It’s just not implemented. Anything vertical is to be handled by our program. Meaning, we have to count scanlines, turn on video after the end of vertical blank, count visible screen lines and orchestrate them (what’s called a video kernel), switch off the video at the lower border, count up to vertical sync and orchestrate the VSYNC pattern. (The timers of the 6532 “RIOT” PIA are of some help here, as we can set up timers to keep track of VSYNC, for example.)

The interesting part is that this isn’t as horrible as it sounds, at all. Since the TIA is really in control of things and also the main agency to effect anything outside the CPU, we’re talking to the TIA much like we would talk to an operating system. (A small difference is that the TIA doesn’t return anything. Actually, the same addresses are used to instruct the TIA by writing or just strobing them, and for returning any input values on read access. So it is a rather taciturn compagnion, but a trustworthy one.) The effect is really much like programming on bare metal and at the same time talking to an OS, which happens to be bare metal as well.

1 Like
7

There’s an online emulator and IDE of sorts with example code for much learning:
8bitworkshop IDE

image
image1120×648 170 KB

8

Very interesting - this stuff is even more obtuse than I had thought. Whenever I think about trying Atari 2600 development, I think again.

Obviously, for some people the obtuseness is actually the appeal.

OTOH, it does make me think a bit more about the sense of the Atari 2600 design at the time. The whole idea of saving a transistor or two here and there is suggestive of the early video game and home computer design habits of the time - the genius talent required to shave off a component or two here and there. And the way the Atari 2600 required such weird coding just to do basic stuff … I can see why they didn’t think some form of bootleg protection (lock-out chip) would be necessary.

9

Regarding the general idea behind this architecture, I think, this is really an outgrow of developments in early non-CPU arcade video games, of which the TIA is pretty much an offspring as well as an abstraction. First, anything like patterns for sprites, constants etc was stored in diode matrices (famously often representing set pixels in their arrangement on the PCB), but was eventually moved to ROMs. Moving to firmware was a great improvement, especially in cost, but also in flexibility. From this perspective, the idea “what else can we put in software” is pretty tempting. Obviously, anything ragarding horizontal scanline progression wasn’t a candidate for this, as the speed required was still faster than any of the available MPUs of the time, but management of vertical screen rendering was. Thus the TIA and the Atari VCS. Developer comfort wasn’t an issue, as this was expected to replicate just a few, rather simple games, like Pong and Tank. (The architecture turned out to be much more flexible than that, though.)

Regarding the developer experience, it’s actually fun, as it is all about visual feedback. (For the absence of any console or serial communications, which could provide more. Professional development back in the day could have involved logic analysers, though, which provided functionality more similar to a monitor/debugger.)

Regarding game design, there is a further issue to consider, which may not be that obvious. You may read the specs and conclude that this and that of your desing works fine with the resources available. However, in practise, there is another constraint, namely a pipeline along the scanline. Meaning, we can only rewrite one sprite or any of its properties at a time, we’ll have then to fetch the value for the next sprite and write this, and so on. So we have a horizontal progression from sprite A to sprite B to sprite C, and so on, in time and along the horizontal extent of the scanline, from left to right. So we have to consider zones accross the screen, determining, which sprites we can reposition at which position, etc, which puts some serious limitations to the game design.
(I really found out about this only when doing the game mentioned above. Compare Ep. 5.)

1 Like