Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Television Interface Adaptor
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Design== [[File:Atari-2600-Six-Switch-Motherboard-Flat.jpg|thumb|right|The motherboard of the original six-switch Atari VCS. The 40-pin TIA chip is on the left. The center 28-pin is the MOS Technology 6507, and to its right, the 40-pin MOS Technology 6352 Ram-I/O-Timer (RIOT) chip. The cartridge insertion slot is to the immediate right of the RIOT chip.]] ===Background=== 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 [[microprocessor]]s had reached the market, but Atari considered them too expensive for a home application.<ref name="ieee decuir"/> They were limited by cost in options for displaying graphics. At this point in time, most computer graphics were generated by using [[sprite (computer graphics)|sprites]] drawn atop a playfield, which then were translated into an analog signal for display on a [[Cathode-ray tube|CRT]]<ref name=antic>Chris Crawford, [http://www.atariarchives.org/dere/chapt02.php "ANTIC and the display list"], ''De Re Atari''</ref> 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.,<ref name="Memprices">{{cite web|url=http://www.jcmit.com/memoryprice.htm|title=Memory Prices (1957-2012)|last=McCallum|first=John C.|date=February 13, 2012|website=jcmit.net|archive-url=https://web.archive.org/web/20121026153229/http://www.jcmit.com/memoryprice.htm|archive-date=October 26, 2012|url-status=dead|access-date=October 27, 2012}}</ref> and to display a two-color playfield on an 80Γ48 display would have cost thousands of dollars in memory.<ref name="ieee decuir">{{cite journal |title = Atari Video Computer System: Bring Entertainment Stories Home | first = Joe | last = Decuir | journal = IEEE Consumer Electronics Magazine | date = July 2015 | doi = 10.1109/MCE.2015.2421572 | pages =59β66 | doi-access = free }}</ref> On a conventional [[NTSC]] [[color television]], maximum resolutions generally fell between 256 and 320 pixels per line, and 192 to 240 lines per screen.<ref>Montfort & Bogost, pg. 27</ref> In September 1975, [[MOS Technology]] introduced the [[MOS Technology 6502|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.<ref name="atari fun chp5">{{cite book | title = Atari Inc: Business is Fun | first1 = Marty | last1 = Goldberg | first2 = Curt | last2 = Vendel | year = 2012 | isbn = 978-0985597405 | publisher = Sygyzy Press | chapter=Chapter 5 }}</ref> 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 (video game)|Tank]]'' game. [[Joseph C. Decuir|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.<ref name="ieee decuir"/> While Decuir worked on the design of the rest of the system, [[Jay Miner]] focused on making an ASIC for the display adapter.<ref name="ieee decuir"/> Early on, the ASIC display adapter was named the Television Interface Adaptor (TIA).<ref name="ieee decuir"/> 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.<ref name="ieee decuir"/> ===RAM-less design=== Due to the lack of RAM, the TIA differs from the conventional framebuffer in that using the TIA, 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.<ref name="wright">Wright, Steve. [http://web.atari.org/stellaes.pdf "Stella Programmer's Guide"], (in Spanish) December 3, 1979. [https://web.archive.org/web/20160305014811/http://web.atari.org/stellaes.pdf Archived] on March 5, 2016.</ref> 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.<ref name=wright /> 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 '[[Sprite (computer graphics)|sprite]]s' 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-flop (electronics)|flip-flop]]s and stores a bitmap of collisions, that are typically read during the VBLANK period.<ref name="ieee decuir"/> 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.<ref name="ieee decuir"/> Lastly, the TIA has inputs for reading up to four analog paddle controllers using [[potentiometer]]s and for two joystick triggers.<ref name="ieee decuir"/> ===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.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)