CTIA and GTIA

Atari had built their first display driver chip, the Television Interface Adaptor universally referred to as the TIA, as part of the Atari 2600 console.^[8] The TIA display logically consisted of two primary sets of objects, the "players" and "missiles" that represented moving objects, and the "playfield" which represented the static background image on which the action took place. The chip used data in memory registers to produce digital signals that were converted in realtime via a digital-to-analog converter and RF modulator to produce a television display.

The conventional way to draw the playfield is to use a bitmap held in a frame buffer, in which each memory location in the frame buffer represents one or more locations on the screen. In the case of the 2600, which normally used a resolution of 160x192 pixels, a frame buffer would need to have at least 160x192/8 = 3840 bytes of memory. Built in an era where RAM was very expensive, the TIA could not afford this solution.

Instead, the system implemented a display system that used a single 20-bit memory register that could be copied or mirrored on the right half of the screen to make what was effectively a 40-bit display. Each location could be displayed in one of four colors, from a palette of 128 possible colors. The TIA also included several other display objects, the "players" and "missiles". These consisted of two 8-bit wide objects known as "players", a single 1-bit object known as the "ball", and two 1-bit "missiles". All of these objects could be moved to arbitrary horizontal locations via settings in other registers.

The key to the TIA system, and the 2600's low price, was that the system implemented only enough memory to draw a single line of the display, all of which held in registers. To draw an entire screen full of data, the user code would wait until the television display reached the right side of the screen and update the registers for the playfield and player/missiles to correctly reflect the next line on the display. This scheme drew the screen line-by-line from program code on the ROM cartridge, a technique known as "racing the beam".

Atari initially estimated that the 2600 would have short market lifetime of three years when it was designed in 1976, which meant the company would need a new design by 1979.^[8] Initially this new design was simply an updated 2600-like game console, and was built around a similar basic design, simply updated. Work on what would become the CTIA started in 1977, and aimed at delivering a system with twice the resolution and twice the number of colours. Moreover, by varying the number of colours in the playfield, much higher resolutions up to 320 pixels horizontally could be supported. Players and missiles were also updated, including four 8-bit players and four 2-bit missiles, but also allowing an additional mode to combine the four missiles into a fifth player.

Shortly after design began, the home computer revolution started in earnest in the later half of 1977. In response, Atari decided to release two versions of the new machine, a low-end model as a games console, and a high-end version as a home computer.^[8] In either role, a more complex playfield would be needed, especially support for character graphics in the computer role. Design of the CTIA was well advanced at this point, so instead of a redesign a clever solution was provided by adding a second chip that would effectively automate the process of racing the beam. Instead of the user's programming updating the CTIA's registers based on its interrupt timing, the new ANTIC would handle this chore, reading data from a framebuffer and feeding that to the CTIA on the fly.

As a result of these changes, the new chips provide greatly improved number and selection of graphics modes over the TIA. Instead of a single playfield mode with 20 or 40 bits of resolution, the CTIA/ANTIC pair can display six text modes and eight graphics modes with various resolutions and color depths, allowing the programmer to choose a balance between resolution, colours, and memory use for their display.

The original design of the CTIA chip also included three additional color interpretations of the normal graphics modes. This feature provides alternate expressions of ANTIC's high-resolution graphics modes presenting 1 bit per pixel, 2 colors with one-half color clock wide pixels as 4 bits per pixel, up to 16 colors, two-color clock wide pixels. This feature was ready before the computers' November 1979 debut, but was delayed so much in the development cycle that Atari had already ordered a batch of about 100,000 CTIA chips with the graphics modes missing. Not wanting to throw away the already-produced chips, the company decided to use them in the initial release of the Atari 400 and 800 models in the US market. The CTIA-equipped computers, lacking the 3 extra color modes, were shipped until October–November 1981.^[5][6] From this point, all new Atari units were equipped with the new chip, now called GTIA, that supported the new color interpretation modes.^[6][9]

The original Atari 800/400 operating system supported the GTIA alternate color interpretation modes from the start,^[9] which allowed for easy replacement of the CTIA with the GTIA once it was ready. Atari authorized service centers would install a GTIA chip in CTIA-equipped computers free of charge if the computer was under warranty; otherwise the replacement would cost $62.52.^[6][7]

GTIA was also mounted in all later Atari XL and XE computers and Atari 5200 consoles.

The list below describes CTIA/GTIA's inherent hardware capabilities meaning the intended functionality of the hardware itself, not including results achieved by CPU-serviced interrupts or display kernels driving frequent register changes.

CTIA/GTIA is a television interface device with the following features:

• Interprets the Playfield graphics data stream from ANTIC to apply color to the display.
• Merges four Player and four Missile overlay objects (aka sprites) with ANTIC's Playfield graphics. Player/Missile features include:
  • Player/Missile pixel positioning is independent of the Playfield:
    • Player/Missile objects function normally in the vertical and horizontal overscan areas beyond the displayed Playfield.
    • Player/Missile objects function normally without an ANTIC Playfield.
  • Eight-bit wide Player objects and two-bit wide Missile objects where each bit represents one displayed pixel.
  • Variable pixel width (1, 2, or 4 color clocks wide)
  • Each Player/Missile object is vertically the height of the entire screen.
  • Variable pixel height when the data is supplied by ANTIC DMA (single or double scan lines per data)
  • Ability to independently shift each P/M object by one scan line vertically when operating on double scan lines per data.
  • Each Player and its associated Missile has a dedicated color register separate from the Playfield colors.
  • Multiple priority schemes for the order of graphics layers (P/M Graphics vs playfield)
  • Color merging between Players and Playfield producing extra colors.
  • Color merging between pairs of Players producing multi-color Players.
  • Missiles can be grouped together into a Fifth Player that uses a separate color register.
  • Collision detection between Players, Missiles, and Playfield graphics.
• There are no fixed colors for normal (CTIA) color interpretation mode. All colors are generated via indirection through nine color registers. (Four for Player/Missile graphics, four for the Playfield, and one shared between the Playfield and the Fifth Player feature.)
  • Normal color interpretation mode provides choice of colors from a 128 color palette (16 colors with 8 luminance values for each)
  • A GTIA color interpretation mode can generate 16 luminances per color providing a 256 color palette.
• The GTIA version of the chip adds three alternate color interpretation modes for the Playfield graphics.
  • 16 shades of a single hue from the 16 possible hues in the Atari palette. This is accessible in Atari BASIC as Graphics 9.
  • 15 hues in a single shade/luminance value plus background. This is accessible in Atari BASIC as Graphics 11.
  • 9 colors in any hue and luminance from the palette accomplished using all the Player/Missile and Playfield color registers for the Playfield colors. This is accessible in Atari BASIC as Graphics 10.
• Reads the state of the joystick triggers (bottom buttons only for the Atari 5200 controllers).
• It includes four input/output pins that are used in different ways depending on the system:
  • In Atari 8-bit computers, three of the pins are used to read state of the console keys (Start/Select/Option).
  • The fourth pin controls the speaker built into the Atari 400/800 to generate keyboard clicks. On later models there is no speaker, but the key click is still generated by GTIA and mixed with the regular audio output.
  • In the Atari 5200, the pins are used as part of the process to read the controller keyboards.

by part number

• C012295 — NTSC CTIA^[10][11]
• C014805 — NTSC GTIA^[12]
• C014889 — PAL GTIA^[12]
• C020120 — French SECAM GTIA (FGTIA)^[12]

Atari, Inc. intended to combine functions of the ANTIC and GTIA chips in one integrated circuit to reduce production costs of Atari computers and 5200 consoles. Two such prototype circuits were being developed, however none of them entered production.

• C020577 — CGIA^[12]
• C021737 — KERI^[12][13][14]

The Atari 8-bit computers map CTIA/GTIA to the $D0xx_hex page and the Atari 5200 console maps it to the $C0xx_hex page.

CTIA/GTIA provides 54 Read/Write registers controlling Player/Missile graphics, Playfield colors, joystick triggers, and console keys. Many CTIA/GTIA register addresses have dual purposes performing different functions as a Read vs a Write register. Therefore, no code should read Hardware registers expecting to retrieve the previously written value.

This problem is solved for many write registers by Operating System Shadow registers implemented in regular RAM as places to store the last value written to registers. Operating System Shadow registers are copied from RAM to the hardware registers during the vertical blank. Therefore, any write to hardware registers which have corresponding shadow registers will be overwritten by the value of the Shadow registers during the next vertical blank.

Some Write registers do not have corresponding Shadow registers. They can be safely written by an application without the value being overwritten during the vertical blank. If the application needs to know the last state of the register then it is the responsibility of the application to remember what it wrote.

Operating System Shadow registers also exist for some Read registers where reading the value directly from hardware at an unknown stage in the display cycle may return inconsistent results.

In the individual register listings below the following legend applies:

These registers specify the horizontal position in color clocks of the left edge (the high bit of the GRAF* byte patterns) of Player/Missile objects. Coordinates are always based on the display hardware's color clock engine, NOT simply the current Playfield display mode. This also means Player/Missile objects can be moved into overscan areas beyond the current Playfield mode.

Note that while Missile objects bit patterns share the same byte for displayed pixels (GRAFM) each Missile can be independently positioned. When the "fifth Player" option is enabled (See PRIOR/GPRIOR register) turning the four Missiles into one "Player" the Missiles switch from displaying the color of the associated Player object to displaying the value of COLPF3. The new "Player's" position on screen must be set by specifying the position of each Missile individually.

Player/Missile pixels are only rendered within the visible portions of the GTIA's pixel engine. Player/Missile objects are not rendered during the horizontal blank or the vertical blank. However, an object can be partially within the horizontal blank. The objects' pixels that fall outside of the horizontal blank are then within the visible portion of the display and can still register collisions. The horizontal position range of visible color clocks is $22_hex/34_dec to $DD_hex/221_dec.

To remove a Player/Missile object from the visible display area horizontal positions (left) 0 and (right) $DE_hex/222_dec (or greater) will insure no pixels are rendered regardless of the size of the Player/Missile object and so no unintentional collisions can be flagged.

Horizontal Position of Player 0

Horizontal Position of Player 1

Horizontal Position of Player 2

Horizontal Position of Player 3

Horizontal Position of Missile 0

Horizontal Position of Missile 1

Horizontal Position of Missile 2

Horizontal Position of Missile 3

Below are the color clock coordinates of the left and right edges of the possible Playfield sizes, useful when aligning Player/Missile objects to Playfield components:

Three sizes can be chosen: Normal, Double, and Quad width. The left edge (See Horizontal Coordinates) is fixed and the size adjustment expands the Player or Missile toward the right in all cases.

• Normal - 1 bit (pixel) is 1 color clock wide
• Double - 1 bit (pixel) is 2 color clocks wide
• Quad - 1 bit (pixel) is 4 color clocks wide

Note that in Quad size a single Player/Missile pixel is the same width as an Antic Mode 2 text character. Player/Missile priority selection mixed with Quad width Player Missile graphics can be used to create multiple text colors per Mode line.

Each Player has its own size control register:

Size of Player 0

Size of Player 1

Size of Player 2

Size of Player 3

Player size controls:

Values:

All Missile sizes are controlled by one register, but each Missile can be sized independently of the others. When the "fifth Player" option is enabled (See PRIOR/GPRIOR register) turning the four Missiles into one "Player" the width is still set by specifying the size for each Missile individually.

Values:

Each Player object has its own 8-bit pattern register. Missile objects share one register with 2 bits per each Missile. Once a value is set it will continue to be displayed on each scan line. With no other intervention by CPU or ANTIC DMA to update the values the result is vertical stripe patterns the height of the screen including overscan areas. This mode of operation does not incur a CPU or DMA toll on the computer. It is useful for displaying alternate colored borders and vertical lines separating screen regions.

Graphics pattern for Player 0

Graphics pattern for Player 1

Graphics pattern for Player 2

Graphics pattern for Player 3

Each Player is 8 bits (pixels) wide. Where a bit is set, a pixel is displayed in the color assigned to the color register associated to the Player. Where a bit is not set the Player object is transparent, showing Players, Missiles, Playfield pixels, or the background color. Pixel output begins at the horizontal position specified by the Player's HPOS value with the highest bit output first.

Graphics pattern for all Missiles

Each Missile is 2 bits (pixels) wide. Where a bit is set, a pixel is displayed in the color assigned to the color register for the Player associated to the Missile. When Fifth Player is enabled (see PRIOR/GPRIOR) the Missiles pixels all display COLPF3. Where a bit is not set the Missile object is transparent, showing Players, Missiles, Playfield pixels, or the background color. Pixel output begins at the horizontal position specified by the Missile's HPOS value with the highest bit output first.

Missile Values:

CTIA/GTIA has 60 bits providing automatic detection of collisions when Player, Missile, and Playfield pixels intersect. A single bit indicates a non-zero pixel of the Player/Missile object has intersected a pixel of a specific color register. There is no collision registered for pixels rendered using the background color register/value. This system provides instant, pixel-perfect overlap comparison without expensive CPU evaluation of bounding box or image bitmap masking.

The actual color value of an object is not considered. If Player, Missile, Playfield, and Background color registers are all the same value making the objects effectively "invisible", the intersections of objects will still register collisions. This is useful for making hidden or secret objects and walls.

Obscured intersections will also register collisions. If a Player object priority is behind a Playfield color register and another Player object priority is higher (foreground) than the Playfield, and the foreground Player pixels obscure both the Playfield and the Player object behind the Playfield, then the collision between the Playfield and both the background and foreground Player objects will register along with the collision between the foreground and background Player objects.

Note that there is no Missile to Missile collision.

Player/Missile collisions can only occur when Player/Missile object pixels occur within the visible portions of the display. Player/Missile objects are not rendered during the horizontal blank or the vertical blank. The range of visible color clocks is 34 to 221, and the visible scan lines range from line 8 through line 247. Player/Missile data outside of these coordinates are not rendered and will not register collisions. An object can be partially within the horizontal blank. The objects' pixels that fall outside of the horizontal blank are within the visible portion of the display and can still register collisions.

To remove a Player/Missile object from the visible display area horizontal positions (left) 0 and (right) 222 (or greater) will insure no pixels are rendered regardless of the size of the Player/Missile object and so no unintentional collisions can be flagged.

Finally, Player, Missile, and Playfield objects collision detection is real-time, registering a collision as the image pixels are merged and output for display. Checking an object's collision bits before the object has been rendered by CTIA/GTIA will show no collision.

Once set, collisions remain in effect until cleared by writing to the HITCLR register. Effective collision response routines should occur after the targeted objects have been displayed, or at the end of a frame or during the vertical blank to react to the collisions and clear collisions before the next frame begins.

Because collisions are only a single bit, collisions are quite obviously not additive. No matter how many times and different locations a collision between pixels occurs within one frame there is only 1 bit to indicate there was a collision. A set collision bit informs a program that it can examine the related objects to identify collision locations and then decide how to react for each location.

Since HITCLR and collision detection is real-time, Display List Interrupts can divide the display into sections with HITCLR used at the beginning of each section and separate collision evaluation at the end of each section.

When the "fifth Player" option is enabled (See PRIOR/GPRIOR register) the only change is the Missiles 0 to 3 switch from displaying the color of the associated Player object to displaying the value of COLPF3. The new "Player's" collisions are still reported for the individual Missiles.

Each bit indicates a pixel of the Player/Missile object has intersected a pixel of the specified Playfield color object. There is no collision registered for the background color.

Obscured intersections will also register collisions. If a Player/Missile object priority is behind a Playfield color register and another Player/Missile object priority is higher (foreground) than the Playfield, and the foreground Player/Missile pixels obscure both the Playfield and the Player/Missile object behind the Playfield, then the collision between the Playfield and both the background and foreground Player/Missile objects will register.

High-resolution, 1/2 color clock pixel modes (ANTIC Modes 2, 3, and F) are treated differently. The "background" color rendered as COLPF2 where pixel values are 0 does not register a collision. High-resolution pixels are rendered as the luminance value from COLPF1. The pixels are grouped together in color clock-wide pairs (pixels 0 and 1, pixels 2 and 3, continuing to pixels 318 and 319). Where either pixel of the pair is 1 a collision is detected between the Player or Missile pixels and Playfield color COLPF2.

GTIA modes 9 and 11 do not process playfield collisions. In GTIA mode 10 Playfield collisions will register where Playfield pixels use COLPF0 through COLPF3

Missile 0 to Playfield collisions

Missile 1 to Playfield collisions

Missile 2 to Playfield collisions

Missile 3 to Playfield collisions

Player 0 to Playfield collisions

Player 1 to Playfield collisions

Player 2 to Playfield collisions

Player 3 to Playfield collisions

Missiles collide with Players and Playfields. There is no Missile to Missile collision.

Missile 0 to Player collisions

Missile 1 to Player collisions

Missile 2 to Player collisions

Missile 3 to Player collisions

A collision between two players sets the collision bit in both Players' collision registers. When Player 0 and Player 1 collide, Player 0's collision bit for Player 1 is set, and Player 1's collision bit for Player 0 is set.

A Player cannot collide with itself, so its bit is always 0.

Player 0 to Player collisions

Player 1 to Player collisions

Player 2 to Player collisions

Player 3 to Player collisions

All Player/Missile objects' pixels and all Playfield pixels in the default CTIA/GTIA color interpretation mode use indirection to specify color. Indirection means that the values of the pixel data do not directly specify the color, but point to another source of information for color. CTIA/GTIA contain hardware registers that set the values used for colors, and the pixels' information refer to these registers. The palette on the Atari is 8 luminance levels of 16 colors for a total 128 colors. The color indirection flexibility allows a program to tailor the screen's colors to fit the purpose of the program's display.

All hardware color registers have corresponding shadow registers.

SHADOW: PCOLOR0 $02C0

Color/luminance of Player and Missile 0.

When GTIA 9-color mode is enabled (PRIOR/GPRIOR value $80) this register is used for the border and background (Playfield pixel value 0), rather than COLBK.

SHADOW: PCOLOR1 $02C1

Color/luminance of Player and Missile 1.

SHADOW: PCOLOR2 $02C2

Color/luminance of Player and Missile 2.

SHADOW: PCOLOR3 $02C3

Color/luminance of Player and Missile 3.

SHADOW: COLOR0 $02C4

Color/luminance of Playfield 0.

SHADOW: COLOR1 $02C5

Color/luminance of Playfield 1.

This register is used for the set pixels (value 1) in ANTIC text modes 2 and 3, and map mode F. Only the luminance portion is used and is OR'd with the color value of COLPF2. In other Character and Map modes this register provides the expected color and luminance for a pixel.

SHADOW: COLOR2 $02C6

Color/luminance of Playfield 2.

This register is used for Playfield background color of ANTIC text modes 2 and 3, and map mode F. That is, where pixel value 0 is used. In other Character and Map modes this register provides the expected color and luminance for a pixel.

SHADOW: COLOR3 $02C7

Color/luminance of Playfield 3

COLPF3 is available is several special circumstances:

• When Missiles are converted to the "fifth Player" they switch from displaying the color of the associated Player object to displaying COLPF3 and change priority. See PRIOR/GPRIOR register.
• Playfield Text Modes 4 and 5. Inverse video characters (high bit $80 set) cause CTIA/GTIA to substitute COLPF3 value for COLPF2 pixels in the character matrix. (See ANTIC's Glyph Rendering)
• Playfield Text Modes 6 and 7. When the character value has bits 6 and 7 set (character range $C0-FF) the entire character pixel matrix is displayed in COLPF3. (See ANTIC's Glyph Rendering)
• This register is also available in GTIA's special 9 color, pixel indirection color mode.

SHADOW: COLOR4 $02C8

Color/luminance of Playfield background.

The background color is displayed where no other pixel occurs through the entire overscan display area. The following exceptions occur for the background:

• In ANTIC text modes 2 and 3, and map mode F the background of the playfield area where pixels may be rendered is from COLPF2 and the COLBK color appears as a border around the playfield.
• In GTIA color interpretation mode $8 (9 color indirection) the display background color is provided by color register COLPM0 while COLBAK is used for Playfield pixel value $8.
• In GTIA color interpretation mode $C (15 colors in one luminance level, plus background) uses COLBK to set the luminance level of all other pixels (pixel value $1 through $F). However, the background itself uses only the color component set in the COLBK register. The luminance value of the background is forced to 0.

Color Registers' Bits:

The high nybble of the color register specifies one of 16 colors color ($00, $10, $20... to $F0).

The low nybble of the register specifies one of 16 luminance values ($00, $01, $02... to $0F).

In the normal color interpretation mode the lowest bit is not significant and only 8 luminance values are available ($00, $02, $04, $06, $08, $0A, $0C, $0E), so the complete color palette is 128 color values.

In GTIA color interpretation mode $4 (luminance-only mode) the full 16 bits of luminance values are available for Playfield pixels providing a palette of 256 colors. Any Player/Missile objects displayed in this mode are colored by indirection which still uses the 128 color palette.

In normal color interpretation mode the pixel values range from $0 to $3 ordinarily pointing to color registers COLBK, COLPF0, COLPF1, COLPF2 respectively. The color text modes also include options to use COLPF3 for certain ranges of character values. See ANTIC's graphics modes for more information.

When Player/Missile graphics patterns are enabled for display where the graphics patterns bits are set the color displayed comes from the registers assigned to the objects.

There are exceptions for color generation and display:

• ANTIC Text modes 2 and 3, and Map mode F:
  • The pixel values in these modes is only $0 and $1. The $0 pixels specify the Playfield background which is color register COLPF2. The $1 pixels use the color component of COLPF2, and the luminance specified by COLPF1. The border around the Playfield uses the color from COLBK.
  • ANTIC Text modes 2 and 3, and Map mode F behave differently with Player/Missile graphics from the other modes. COLPF1 used for the glyph or graphics pixels always has the highest priority and cannot be obscured by Players or Missiles. The color of COLPF1 always comes from the "background" which is ordinarily COLPF2. Therefore, where Players/Missiles and Fifth Player have priority over COLPF2 the COLPF1 glyph/graphics pixels use the color component of the highest priority color (Player or Missile), and the luminance component of COLPF1. This behavior is consistent where Player/Missile priority conflicts result in true black for the "background". In summary, the color CTIA/GTIA finally determines to use "behind" the high-res pixel is then used to "tint" the COLPF1 foreground glyph/graphics pixels.
• GTIA Exceptions
  • GTIA color interpretation mode $8 (9 color indirection) uses color register COLPM0 for the display background and border color while COLBAK is used for Playfield pixel value $8.
  • GTIA color interpretation mode $C (15 colors in one luminance level, plus background) uses COLBK to set the luminance level of all other pixels (pixel value $1 through $F). However, the background itself uses only the color component set in the COLBK register. The luminance value of the background is forced to 0. Note that the background's color component is also OR'd with the other pixels' colors. Therefore, the overall number of colors in the mode is reduced when the background color component is not black (numerically zero).
• Player/Missile Exceptions:
  • Player/Missile Priority value $0 (See PRIOR/GPRIOR) will cause overlapping Player and Playfield pixels to be OR'd together displaying a different color.
  • Conflicting Player/Missile Priority configuration will cause true black (color 0, luma 0) to be output where conflicts occur.
  • The Player/Missile Multi-Color option will cause overlapping Player pixels to be OR'd together displaying a different color.

Color Registers' Use per ANTIC Character Modes:

Color Registers' Use per ANTIC Map Modes:

Color Registers' Use per GTIA Modes (ANTIC F):

Player/Missile colors are always available for Player/Missile objects in all modes, though colors may be modified when the special GTIA modes (16 shades/16 color) are in effect.

SHADOW: GPRIOR $026F

This register controls several CTIA/GTIA color management features: The GTIA Playfield color interpretation mode, Multi-Color Player objects, the Fifth Player, and Player/Missile/Playfield priority.

CTIA includes only one default color interpretation mode for the ANTIC Playfield data stream. That is the basic functionality assumed in the majority of the ANTIC and CTIA/GTIA discussion unless otherwise noted. GTIA includes three alternate color interpretations modes for Playfield data. These modes work by pairing adjacent color clocks from ANTIC, thus the pixels output by GTIA are always two color clocks wide. Although these modes can be engaged while displaying any ANTIC Playfield Mode, the full color palette possible with these GTIA color processing options are only realized in the ANTIC Modes based on 1⁄2 color clock pixels (ANTIC modes 2, 3, F.) These GTIA options are most often used with a Mode F display. The special GTIA color processing modes also alter the display or behavior of Player/Missile graphics in various ways.

The color interpretation control is a global function of GTIA affecting the entire screen. GTIA is not inherently capable of mixing on one display the various GTIA color interpretation modes and the default CTIA mode needed for most ANTIC Playfields. Mixing color interpretation modes requires software writing to the PRIOR register as the display is generated (usually, by a Display List Interrupt).

PRIOR bits 7 and 6 provide four values specifying the color interpretation modes:

This mode uses the COLBK register to specify the background color. Rather than using indirection, pixel values directly represent Luminance. This mode allows all four luminance bits to be used in the Atari color palette and so is capable of displaying 256 colors.

Player/Missile graphics (without the fifth Player option) display properly in this mode, however collision detection with the Playfield is disabled. Playfield priority is always on the bottom. When the Missiles are switched to act as a fifth Player then where the Missile objects overlap the Playfield the Missile pixels luminance merges with the Playfield pixels' Luminance value.

Unlike the other two special GTIA modes, this mode is entirely driven by color indirection. All nine color registers work on the display for pixel values 0 through 8. The remaining 7 pixel values repeat previous color registers.

The pixels are delayed by one color clock (half a GTIA mode pixel) when output. This offset permits interesting effects. For an example, page flipping rapidly between this mode and a different GTIA mode produces a display with apparent higher resolution and greater number of colors.

This mode is unique in that is uses color register COLPM0 for the border and background (Playfield 0 value pixels) rather than COLBK.

Player/Missile graphics display properly with the exception that Player/Missile 0 are not distinguishable from the background pixels, since they use the same color register, COLPM0. The Playfield pixels using the Player/Missile colors are modified by priority settings as if they were Player/Missile objects and so can affect the display of Players/Missiles. (See discussion later about Player/Missile/Playfield priorities).

The Playfield pixels using Player/Missile colors do not trigger collisions when Player/Missile objects overlay them. However, Player/Missile graphics overlapping Playfield colors COLPF0 to COLPF3 will trigger the expected collision.

This mode uses the COLBK register to specify the luminance of all Playfield pixels (values 1_hex/1_dec through F_hex/15_dec.) The least significant bit of the luminance value is not observed, so only the standard/CTIA 8 luminance values are available ($0, $2, $4, $6, $8, $A, $C, $E). Additionally, the background itself uses only the color component set in the COLBK register. The luminance value of the background is forced to 0. As with the Luminance mode indirection is disabled and pixel values directly represent a color.

Note that the color component of the background also merges with the playfield pixels. Colors other than black for the background reduce the overall number of colors displayed in the mode.

Player/Missile graphics (without the fifth Player option) display properly in this mode, however collision detection with the Playfield is disabled. Playfield priority is always on the bottom. When the Missiles are switched to act as a fifth Player then where the Missile objects overlap the Playfield the Missile pixels inherit the Playfield pixels' Color value.

PRIOR bit 5, value 20_hex/32_dec enables Multi-Color Player objects. Where pixels of two Player/Missile objects overlap a third color appears. This is implemented by eliminating priority processing between pairs of Player/Missile objects resulting in CTIA/GTIA performing a bitwise OR of the two colored pixels to output a new color.

Example: A Player pixel with color value 98_hex/152_dec (blue) overlaps a Player pixel with color value 46_hex/70_dec (red) resulting in a pixel color of DE_hex/228_dec (light green/yellow).

The Players/Missiles pairs capable of Multi-Color output:

• Player 0 + Player 1
• Missile 0 + Missile 1
• Player 2 + Player 3
• Missile 2 + Missile 3

PRIOR bit 4, value $10_hex/16_dec enables Missiles to become a fifth Player. No functional change occurs to the Missile other than the color processing of the Missiles. Normally the Missiles display using the color of the associated Player. When Fifth Player is enabled all Missiles display the color of Playfield 3 (COLPF3). Horizontal position, size, vertical delay, and Player/Missile collisions all continue to operate the same way. The priority of the Fifth Player for Player objects pixel intersections is COLPF3, but the Fifth Player's pixels have priority over all Playfield colors.

The color processing change also causes some exceptions for the Missiles' display in GTIA's alternative color modes:

• GTIA 16 Shades mode: Where Missile pixels overlap the Playfield the pixels inherit the Playfield pixels' Luminance value.
• GTIA 16 Colors mode: Where Missile pixels overlap the Playfield the pixels inherit the Playfield pixels' Color value.

The Fifth Player introduces an exception for Priority value $8 (bits 1000) (See Priority discussion below.)

PRIOR bits 3 to 0 provide four Player/Missile and Playfield priority values that determine which pixel value is displayed when Player/Missile objects pixels and Playfield pixels intersect. The four values provide specific options listed in the Priority chart below. "PM" mean normal Player/Missile implementation without the Fifth Player. The Fifth Player, "P5", is shown where its priority occurs when it is enabled.

The chart is accurate for ANTIC Playfield Character and Map modes using the default (CTIA) color interpretation mode. GTIA color interpretation modes, and the ANTIC modes based on high-resolution, 1⁄2 color clock pixels behave differently (noted later).

If multiple bits are set, then where there is a conflict CTIA/GTIA outputs a black pixel—Note that black means actual black, not simply the background color, COLBK.

Although the Fifth Player is displayed with the value of COLPF3, its priority is above all Playfield colors. This produces an exception for Priority value $8 (Bits 1000). In this mode Playfield 0 and 1 are higher priority than the Players, and the Players are higher priority than Playfield 2 and 3. Where Playfield 0 or 1 pixels intersect any Player pixel the result displayed is the Playfield pixel. However, if the Fifth player also intersects the same location, its value is shown over the Playfield causing it to appear as if Playfield 3 has the highest priority. If the Playfield 0 or 1 pixel is removed from this intersection then the Fifth Player's pixel has no Playfield pixel to override and so also falls behind the Player pixels.

When the Priority bits are all 0 a different effect occurs—Player and Playfield pixels are logically OR'd together in the a manner similar to the Multi-Color Player feature. In this situation Players 0 and 1 pixels can mix with Playfield 0 and 1 pixels, and Players 2 and 3 pixels can mix with Playfield 2 and 3 pixels. Additionally, when the Multi-Color Player option is used the resulting merged Players' color can also mix with the Playfield producing more colors. When all color merging possibilities are considered, the CTIA/GTIA hardware can output 23 colors per scan line. Starting with the background color as the first color, the remaining 22 colors and color merges are possible:

When Priority bits are all 0 the Missiles colors function the same way as the corresponding Players as described above. When Fifth Player is enabled, the Missile pixels cause the same color merging as shown for COLPF3 in the table above (colors 19 through 22).

The priority result differ for the Character and Map modes using high-resolution, 1⁄2 color clock pixels—ANTIC modes 2, 3, and F. These priority handling differences can be exploited to produce color text or graphics in these modes that are traditionally thought of as "monochrome".

In these ANTIC modes COLPF2 is output as the "background" of the Playfield and COLBK is output as the border around the Playfield. The graphics or glyph pixels are output using only the luminance component of COLPF1 mixed with the color component of the background (usually COLPF2).

The priority relationship between Players/Missiles, and COLPF2 work according to the priority chart below. Player/Missile pixels with higher priorities will replace COLPF2 as the "background" color. COLPF1 always has the highest priority and cannot be obscured by Players or Missiles. The glyph/graphics pixels use the color component of highest priority color (Playfield, Player, or Missile), and the luminance component of COLPF1. Note that this behavior is also consistent where Player/Missile priority conflicts result in true black for the "background". In effect, the color value CTIA/GTIA finally uses for the "background" color "tints" the COLPF1 foreground glyph/graphics pixels.

Vertical Delay P/M Graphics

This register is used to provide single scan line movement when Double Line Player/Missile resolution is enabled in ANTIC's DMACTL register. This works by masking ANTIC DMA updates to the GRAF* registers on even scan lines, causing the graphics pattern to shift down one scan line.

Since Single Line resolution requires ANTIC DMA updates on each scan line and VDELAY masks the updates on even scan lines, then this bit reduces Single line Player/Missile resolution to Double line.

Graphics Control

GRACTL controls CTIA/GTIA's receipt of Player/Missile DMA data from ANTIC and toggles the mode of Joystick trigger input.

Receipt of Player/Missile DMA data requires CTIA/GTIA be configured to receive the data. This is done with a pair of bits in GRACTL that match a pair of bits in ANTIC's DMACTL register that direct ANTIC to send Player data and Missile data. GRACTL's Bit 0 corresponds to DMACTL's Bit 2, enabling transfer of Missile data. GRACTL's Bit 1 corresponds to DMACTL's Bit 3, enabling transfer of Player data. These bits must be set for GTIA to receive Player/Missile data from ANTIC via DMA. When Player/Missile graphics are being operated directly by the CPU then these bits must be off.

The joystick trigger registers report the pressed/not pressed state in real-time. If a program's input polling may not be frequent enough to catch momentary joystick button presses, then the triggers can be set to lock in the closed/pressed state and remain in that state even after the button is released. Setting GRACTL Bit 2 enables the latching of all triggers. Clearing the bit returns the triggers to the unlatched, real-time behavior.

Clear Collisions

Any write to this register clears all the Player/Missile collision detection bits.

SHADOW: STRIG0 $0284

Joystick 0 trigger

SHADOW: STRIG1 $0285

Joystick 1 trigger.

SHADOW: STRIG2 $0286

Joystick 2 trigger.

SHADOW: STRIG3 $0287

Joystick 3 trigger

Bits 7 through 1 are always 0. Bit 0 reports the state of the joystick trigger. Value 1 indicates the trigger is not pressed. Value 0 indicates the trigger is pressed.

The trigger registers report button presses in real-time. The button pressed state will instantly clear when the button is released.

The triggers may be configured to latch, that is, lock, in the pressed state and remain that way until specifically cleared. GRACTL bit 2 enables the latch behavior for all triggers. Clearing GRACTL bit 2 returns all triggers to real-time behavior.

PAL flags.

This register reports the display standard for the system. When Bits 3 to 0 are set to 1 (value $f_hex/15_dec) the system is operating in NTSC. When the bits are zero the system is operating in PAL mode.

Console Speaker

Bit3 controls the internal speaker of the Atari 800/400. In later models the console speaker is removed and the sound is mixed with the regular POKEY audio signals for output to the monitor port and RF adapter. The Atari OS uses the console speaker to output the keyboard click and the bell/buzzer sound.

The Operating System sets the speaker bit during the vertical blank routine. Repeatedly writing 0 to the bit will produce a 60 Hz buzzing sound as the vertical blank resets the value. Useful tones can be generated using 6502 code effectively adding a fifth audio channel, albeit a channel requiring CPU time to maintain the audio tones.

Console Keys

A bit is assigned to report the state of each of the special console keys, Start, Select, and Option. Bit value 0 indicates a key is pressed and 1 indicates the key is not pressed. Key/Bit values:

• Start Key = Bit value $1
• Select Key = Bit value $2
• Option Key = Bit value $4

A hardware "sprite" system is handled by CTIA/GTIA. The official ATARI name for the sprite system is "Player/Missile Graphics", since it was designed to reduce the need to manipulate display memory for fast-moving objects, such as the "player" and his weapons, "missiles", in a shoot 'em up game.

A Player is essentially a glyph 8 pixels wide and 256 TV lines tall, and has two colors: the background (transparent) (0 in the glyph) and the foreground (1). A Missile object is similar, but only 2 pixels wide. CTIA/GTIA combines the Player/Missile objects' pixels with the Playfield pixels according to their priority. Transparent (0) player pixels have no effect on the Playfield and display either a Playfield or background pixel without change. All Player/Missile objects' normal pixel width is one color clock. A register value can set the Player or Missile pixels' width to 1, 2, or 4 color clocks wide.

The Player/Missile implementation by CTIA/GTIA is similar to the TIA's. A Player is an 8-bit value or pattern at a specified horizontal position which automatically repeats for each scan line or until the pattern is changed in the register. Missiles are 2-bits wide and share one pattern register, so that four, 2-bit wide values occupy the 8-bit wide pattern register, but each missile has an independent horizontal position and size. Player/Missile objects extend the height of the display including the screen border. That is, the default implementation of Player/Missile graphics by CTIA/GTIA is a stripe down the screen. While seemingly limited this method facilitates Player/Missile graphics use as alternate colored vertical borders or separators on a display, and when priority values are set to put Player/Missile pixels behind playfield pixels they can be used to add additional colors to a display. All Players and Missiles set at maximum width and placed side by side can cover the entire normal width Playfield.

CTIA/GTIA supports several options controlling Player/Missile color. The PRIOR/GPRIOR register value can switch the four Missiles between two color display options—each Missile (0 to 3) expresses the color of the associated Player object (0 to 3) or all Missiles show the color of register COLPF3/COLOR3. When Missiles are similarly colored they can be treated as a fifth player, but correct placement on screen still requires storing values in all four Missile Horizontal Position registers. PRIOR/GPRIOR also controls a feature that causes the overlapping pixels of two Players to generate a third color allowing multi-colored Player objects at the expense of reducing the number of available objects. Finally, PRIOR/GPRIOR can be used to change the foreground/background layering (called, "priority") of Player/Missile pixels vs Playfield pixels, and can create priority conflicts that predictably affect the colors displayed.

The conventional idea of a sprite with an image/pattern that varies vertically is also built into the Player/Missile graphics system. The ANTIC chip includes a feature to perform DMA to automatically feed new pixel patterns to CTIA/GTIA as the display is generated. This can be done for each scan line or every other scan line resulting in Player/Missile pixels one or two scan lines tall. In this way the Player/Missile object could be considered an extremely tall character in a font, 8 bits/pixels wide, by the height of the display.

Moving the Player/Missile objects horizontally is as simple as changing a register in the CTIA/GTIA (in Atari BASIC, a single POKE statement moves a player or missile horizontally). Moving an object vertically is achieved by either block moving the definition of the glyph to a new location in the Player or Missile bitmap, or by rotating the entire Player/Missile bitmap (128 or 256 bytes). The worst case rotation of the entire bitmap is still quite fast in 6502 machine language, even though the 6502 lacks a block-move instruction found in the 8080. Since the sprite is exactly 128 or 256 bytes long, the indexing can be easily accommodated in a byte-wide register on the 6502. Atari BASIC lacks a high speed memory movement command and moving memory using BASIC PEEK()s and POKE(s) is painfully slow. Atari BASIC programs using Player/Missile graphics have other options for performing high speed memory moves. One method is calling a short machine language routine via the USR() function to perform the memory moves. Another option is utilizing a large string as the Player/Missile memory map and performing string copy commands which result in memory movement at machine language speed.

Careful use of Player/Missile graphics with the other graphics features of the Atari hardware can make graphics programming, particularly games, significantly simpler.

The GTIA chip is backward compatible with the CTIA, and adds 3 color interpretations for the 14 "normal" ANTIC Playfield graphics modes. The normal color interpretation of the CTIA chip is limited, per scanline, to a maximum of 4 colors in Map modes or 5 colors in Text modes (plus 4 colors for Player/Missile graphics) unless special programming techniques are used. The three, new color interpretations in GTIA provide a theoretical total of 56 graphics modes (14 ANTIC modes multiplied by four possible color interpretations). However, only the graphics modes based on high-resolution, 1⁄2 color clock pixels (that is, Antic text modes 2, 3, and graphics mode F) are capable of fully expressing the color palettes of these 3 new color interpretations. The three additional color interpretations use the information in two color clocks (four bits) to generate a pixel in one of 16 color values. This changes a mode F display from 2 colors per pixel, 320 pixels horizontally, one scan line per mode line, to 16 colors and 80 pixels horizontally. The additional color interpretations allow the following:

• GTIA color interpretation mode $4 — 16 shades of a single hue (set by the background color, COLBK) from the 16 possible hues in the Atari palette. This is also accessible in Atari BASIC as Graphics 9.
• GTIA color interpretation mode $8 — This mode allows 9 colors of indirection per horizontal line in any hue and luminance from the entire Atari palette of 128 colors. This is accomplished using all the Player/Missile and Playfield color registers for the Playfield pixels. In this mode the background color is provided by color register COLPM0 while COLBAK is used for Playfield pixel value $8. This mode is accessible in Atari BASIC as Graphics 10,
• GTIA color interpretation mode $C — 15 hues in a single shade/luminance value, plus the background. The value of the background, COLBK sets the luminance level of all other pixels (pixel value $1 through $F). The least significant bit of the luminance value is not observed, so only the standard/CTIA 8 luminance values are available ($0, $2, $4, $6, $8, $A, $C, $E). Additionally, the background itself uses only the color component set in the COLBK register. The luminance value of the background is forced to 0. This mode is accessible in Atari BASIC as Graphics 11.

Of these modes, Atari BASIC Graphics 9 is particularly notable. It enables the Atari to display grayscale digitized photographs, which despite their low resolution were very impressive at the time. Additionally, by allowing 16 shades of a single hue rather than the 8 shades available in other graphics modes, it increases the amount of different colors the Atari could display from 128 to 256. Unfortunately, this feature is limited for use in this mode only, which due to its low resolution was not widely used.

The Antic 2 and 3 text modes are capable of displaying the same color ranges as mode F graphics when using the GTIA's alternate color interpretations. However, since the pixel reduction also applies and turns 8 pixel wide, 2 color text into 2 pixel wide, 16 color blocks these modes are unsuitable for actual text, and so these graphics modes are not popular outside of demos. Effective use of the GTIA color interpretation feature with text modes requires a carefully constructed character set treating characters as pixels. This method allows display of an apparent GTIA "high resolution" graphics mode that would ordinarily occupy 8K of RAM to instead use only about 2K (1K for the character set, and 1K for the screen RAM and display list.)

The GTIA also fixed an error in CTIA that caused graphics to be misaligned by "half a color clock". The side effect of the fix was that programs that relied on color artifacts in high-resolution monochrome modes would show a different pair of colors.^[5][15]

Atari owners can determine if their machine is equipped with the CTIA or GTIA by executing the BASIC command POKE 623,64. If the screen blackens after execution, the machine is equipped with the new GTIA chip. If it stays blue, the machine has a CTIA chip instead.

The last Atari XE computers made for the Eastern European market were built in China. Many if not all have a buggy PAL GTIA chip. The luma values in Graphics 9 and higher are at fault, appearing as stripes. Replacing the chip fixes the problem. Also, there have been attempts to fix faulty GTIA chips with some external circuitry.

• List of home computers by video hardware