Editing Television Interface Adaptor (section)

===Drawing the display===
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]]".<ref>{{Cite magazine|url=https://www.wired.com/2009/03/racing-the-beam/|title=Racing the Beam: How Atari 2600's Crazy Hardware Changed Game Design|last=Kohler|first=Chris|date=March 13, 2009|magazine=[[Wired (magazine)|Wired]]|archive-url=https://web.archive.org/web/20140712094639/https://www.wired.com/2009/03/racing-the-beam/|archive-date=July 12, 2014|url-status=live}}</ref>

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 [[interrupt]]s. 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 end of the current line, a "wait for sync" command.<ref name="ieee decuir"/> This suspends the operation of the CPU until the start (color clock cycle 0) of the horizontal blanking period right ahead of the next line, providing a measure of automatic synchronization. The intended use of this mechanism is for the CPU to run code that sets up the TIA registers for the line about to be drawn, and which usually runs to completion some time before the TIA reaches the end of that line. To make video timing synchronization easier, the CPU then writes to the register that triggers the synchronization delay via RDY, throwing away a variable amount of CPU time.<ref name="ieee decuir"/>

In addition, the TIA only semi-automatically generates [[Analog television#Vertical synchronization|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 [[Analog television#Vertical synchronization|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.<ref>Montfort & Bogost, pg. 34</ref>

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 game]]s Atari had already produced like ''[[Tank (arcade game)|Tank]]'' and ''[[Pong]]''. In these cases the playfield data was typically laid out in the 2 kB [[Read-only memory|ROM]] memory in the [[ROM cartridge|game cartridge]]. As each line used 20 bits of data, and there were 192 lines on an NTSC display,<ref>More on PAL, see [http://nocash.emubase.de/2k6specs.htm "Atari 2600 Specifications"] {{webarchive|url=https://web.archive.org/web/20110524014918/http://nocash.emubase.de/2k6specs.htm|date=May 24, 2011|title=}}</ref> 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.

[[File:Barnstorming Atari 2600.jpg|thumb|Rainbow effect visible in [[Barnstorming (video game)|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 (Atari 2600)|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.<ref>Robinett, Warren, [http://www.warrenrobinett.com/adventure/adventure_lecture.ppt "Adventure"], [[University of North Carolina at Chapel Hill|University of North Carolina]]. [https://web.archive.org/web/20180107145056/http://www.warrenrobinett.com/adventure/adventure_lecture.ppt Archived] on January 27, 2018.</ref> 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.