Television Interface Adaptor

Around 1975, Atari's engineers at Cyan Engineering led by Steve Mayer and Ron Milner had been considering alternatives to the development dedicated hardware such as application-specific integrated circuits (ASIC) for arcade video games and home video game consoles. Programmable microprocessors had reached the market, but Atari considered them too expensive for a home application.[4] They were limited by cost in options for displaying graphics. At this point in time, most computer graphics were generated by using sprites drawn atop a playfield, which then were translated into an analog signal for display on a CRT video monitor.[5] Sprites would be held as a bitmap in a framebuffer, requiring random-access memory (RAM). RAM was still expensive, costing tens of thousands of dollars per megabyte.[6], and to display a two-color playfield on a 80×48 display would have cost thousands of dollars in memory.[4] On a conventional NTSC color television, maximum resolutions generally fell between 256 and 320 pixels per line, and 192 to 240 lines per screen.[7]

In September 1975, MOS Technology introduced the 6502 microprocessor, one of the first low-cost microprocessors on the market. Mayer and Milner arranged to speak to the chip's designer, Chuck Peddle, on using the 6502 as the basis for their programmable video game console. Over the course of a couple of days, the basic design of the Atari VCS was laid out, with Peddle offering Atari the use of the lower-cost MOS Technology 6507 processor and the MOS Technology 6532 RAM-I/O-Timer (RIOT) as the core of the design.[8] Using a breadboard prototype for the display adapter atop a 6502 testbed system, Milner was able to demonstrate the ability to program a simple version of their Tank game. Joe Decuir was hired on to help convert Milner's proof-of-concept to a functional prototype, sufficient for Atari to give the go-ahead for the development to continue.[4]

While Decuir worked on the design of the rest of the system, Jay Miner focused on making an ASIC for the display adapter.[4] Early on, the ASIC display adapter was named the Television Interface Adaptor (TIA).[4] The cost of RAM remained high as the team began its design, and thus the option to use memory-based framebuffers was dropped from the TIA's design.[4]

Due to the lack of RAM, the TIA differs from the conventional framebuffer approach on the screen is composed by manipulating five movable graphic objects (2 players, 2 missiles and 1 ball) and a static playfield object. These are all generated on every scan line from their respective registers, unlike the technique used in a framebuffer-mapped model, requiring the program to update these on every scan line.[9] Horizontal resolution is not uniform, as its size depends on the particular graphics object. The smallest unit of pixel corresponds to 1 color clock cycle of the chip, of which there are 160 visible ones on a line.[9]

The Playfield object consists of a two-and-a-half byte register (20 bits wide), which can be reflected symmetrically or copied as-is to the right half of the screen for 40 bits in total (each bit being 4 color cycles wide). The color that was drawn if the bit was a 1 or a 0 was selected from a pre-defined palette of up to 128 colors (see below) and held in other registers.

The TIA also supported five separate graphics objects consisting of:

• Two 8-pixel horizontal lines which make up the 'sprites' Player 1 and Player 2. These are single color, can be stretched by a factor of 2 or 4, and can be duplicated or triplicated.
• A 'ball' - a horizontal line that is the same color as the playfield. It can be one, two, four, or eight pixels wide.
• Two 'missiles' - another horizontal line that is the same color as its respective player. It can be one, two, four, or eight pixels wide.

Without RAM-based framebuffers, collision detection is also complicated. The TIA has hardware collision detection for all of these objects through the use of 15 set/reset flip-flops and stores a bitmap of collisions, that are typically read during the VBLANK period.[4] Registers in the TIA allow the programmer to control the positioning of the graphical objects and their color.

The TIA also provides two channels of one-bit sound. Each channel provides for 32 pitch values and 16 possible bit sequences. There is a 4 bit volume control.[4]

Lastly, the TIA has inputs for reading up to four analog paddle controllers using potentiometers and for two joystick triggers.[4]

As the registers hold data for only a single line of the display, creating a full screen requires the game program to update the registers on the fly, a process known as "racing the beam".[10]

To start the process, the game program running on the MOS Technology 6502-based CPU loads the TIA's registers with the data needed to draw the first line of the display. The TIA then waits until the television is ready to draw the line (under the command of the TIA's associated analog hardware) and read out the registers to produce a signal for that line. During the horizontal blanking period between lines, the 6502 quickly changes the TIA's registers as needed for the next line. This process continues down the screen.

This is made more difficult because the MOS Technology 6507 in the 2600 is a pin-reduced version of the 6502 with no support for hardware interrupts. Generally the analog side of the display system generates an interrupt when it finishes drawing a raster line and is getting ready for the next one. The interrupt triggers the code needed to update the screen, and then returns to the "main" program. The 6507 left these pins off of the CPU to save money, however it does have a "RDY" pin to insert wait states into CPU bus cycles. The TIA was specifically designed to use the RDY pin to synchronize the CPU with the raster line timing of the video generated by the TIA: when the CPU writes to a certain register address of the TIA, the TIA lowers its RDY output signal until the beginning of the next line, a "wait for sync" command.[4] This suspends the operation of the CPU until the start (color clock cycle 0) of the next line, providing a measure of automatic synchronization. The intended use of this mechanism is for the CPU to set up the TIA registers for the following line before the TIA reaches the end of the current line, then write to the register that triggers the synchronization delay via RDY, throwing away a variable amount of CPU time for the benefit of easier video timing synchronization.[4]

In addition, the TIA only semi-automatically generates vertical sync timing signals (to mark the end of each video frame and the start of the next). The TIA is capable of inserting a vertical sync signal into the analog output video signal, but it does not have a frame line-counter and so cannot tell when a frame should end. Instead, it is left to the CPU program to trigger vertical sync signals and to count the lines in each frame to determine when a vertical sync signal should be generated. Like for the RDY-wait hardware, the vertical sync signal is triggered by the CPU writing to a specific TIA register address. If no write to that address was ever done and the TIA was allowed to free-run, it would generate a single infinite frame of active raster lines, which would typically appear on the TV as a rolling picture. Most published games for the Atari 2600 generated vertical sync after either every 262 or every 263 lines (but nothing about the TIA prevents it from generating frames of any length, shorter or longer, though the resulting video displays would roll vertically on normal TVs).

These and other details of TIA programming mean that programmers need to time their programs carefully to run in the exact number of cycles needed for various screen-related events. Getting this wrong means the screen is not drawn properly. The part of a program that does this is known as the "kernel" of that program.[11]

Given this complexity, early games using the system tended to be simple in layout, using the TIA to create symmetric playfields with players on top. This was the original intention of the system: to run the handful of arcade games Atari had already produced like Tank and Pong. In these cases the playfield data was typically laid out in the 2 kB ROM memory in the game cartridge. As each line used 20 bits of data, and there were 192 lines on an NTSC display,[12] a display with a different layout on every line needed only 480 bytes (192 x 20 / 8) of the cartridge's 4 kB to hold a single hard-coded display. In this case the kernel simply advanced 20 bits through ROM for every line as the TIA advanced down the screen, a task that took only a few cycles of CPU time. This can be further reduced by using the same data for multiple lines, either doubling them vertically, or reading one way through the list for the top and then back the other way for the bottom, producing a vertically mirrored display of only 240 bytes.

Rainbow effect visible in Barnstorming game

A key advance was the licensing of Space Invaders for the platform, which required many more player graphics to draw the enemy aliens. The solution was to change the player data for every line as the image was being drawn, creating an apparent large number of players. Another advance was made by (partially) coding the display as CPU instructions instead of storing it as fixed data in ROM. Adventure uses this concept to produce a wide variety of maps by combining different portions of the data in ROM, jumping back and forth through it during the screen drawing.[13] This allowed the game to have 30 rooms, which would have otherwise required 14 kB of ROM.

As programmers grew more accustomed to the odd timing needed to get things to work properly on-screen, they began to use the inherent flexibility in the TIA to greatly improve the displays. One common technique was to change the color registers that were used to draw the 1 and 0 states of the playfield, resulting in displays with rainbow-like effects. Later games could modify the playfield mid-line to generate asymmetric patterns, repositioning and changing player sprites mid-screen to generate additional sprites.

Frequencies are generated by taking 30 kHz and dividing by the 5-bit value supplied. The result is a cheap frequency divider capable of detuned notes and the odd tuned frequency. The TIA is not a musical chip unless the composer works within the frequency limits or modulates between two detuned frequencies to create a vibrato tuned note.

The Audio Control register generates and manipulates a pulse wave to create complex pulses or noise. The following table (with designed duplicates) explains how its tones are generated: