CTIA and GTIA

Atari had built their first display driver chip, the Television Interface Adaptor but 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 256 Color Palette used in the GTIA chip, (NTSC only) with 16 hues, and 16 luminance values.

This is what the Atari TIA and CTIA used as a palette, (NTSC only) with 16 hue, and only 8 luminance values, making up 128 unique colors

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.

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.

GTIA Playfield Color Interpretations
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:

16 Shades
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.

9 Color
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.

16 Colors
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.

Multi-Color Player
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

Fifth Player
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.)

Priority
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).

Priority And High-Resolution Modes
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