History
2600 and TIA
Atari had built their first display driver chip, theCTIA
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. 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. In either role, a more complex playfield would be needed, especially support forCTIA vs. GTIA
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. From this point, all new Atari units were equipped with the new chip, now called GTIA, that supported the new color interpretation modes. The original Atari 800/400 operating system supported the GTIA alternate color interpretation modes from the start, 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. GTIA was also mounted in all later Atari XL and XE computers and Atari 5200 consoles.Features
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 fromVersions
''by part number'' *C012295 — NTSC CTIAMichael CurrentPinout
Registers
The Atari 8-bit computers map CTIA/GTIA to the $D0xxhex page and the Atari 5200 console maps it to the $C0xxhex 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:Player/Missile Horizontal Coordinates
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 $22hex/34dec to $DDhex/221dec. To remove a Player/Missile object from the visible display area horizontal positions (left) 0 and (right) $DEhex/222dec (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.HPOSP0 $D000 Write
Horizontal Position of Player 0HPOSP1 $D001 Write
Horizontal Position of Player 1HPOSP2 $D002 Write
Horizontal Position of Player 2HPOSP3 $D003 Write
Horizontal Position of Player 3HPOSM0 $D004 Write
Horizontal Position of Missile 0HPOSM1 $D005 Write
Horizontal Position of Missile 1HPOSM2 $D006 Write
Horizontal Position of Missile 2HPOSM3 $D007 Write
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:Player/Missile Size Control
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:SIZEP0 $D008 Write
Size of Player 0SIZEP1 $D009 Write
Size of Player 1SIZEP2 $D00A Write
Size of Player 2SIZEP3 $D00B Write
Size of Player 3 Player size controls: Values:SIZEM $D00C Write
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:Player/Missile Graphics Patterns
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.GRAFP0 $D00D Write
Graphics pattern for Player 0GRAFP1 $D00E Write
Graphics pattern for Player 1GRAFP2 $D00F Write
Graphics pattern for Player 2GRAFP3 $D010 Write
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.GRAFM $D011 Write
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:Player/Missile Collisions
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.Player/Missile to Playfield Collisions
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 (=M0PF $D000 Read
= Missile 0 to Playfield collisions=M1PF $D001 Read
= Missile 1 to Playfield collisions=M2PF $D002 Read
= Missile 2 to Playfield collisions=M3PF $D003 Read
= Missile 3 to Playfield collisions=P0PF $D004 Read
= Player 0 to Playfield collisions=P1PF $D005 Read
= Player 1 to Playfield collisions=P2PF $D006 Read
= Player 2 to Playfield collisions=P3PF $D007 Read
= Player 3 to Playfield collisionsMissile to Player Collisions
Missiles collide with Players and Playfields. There is no Missile to Missile collision.=M0PL $D008 Read
= Missile 0 to Player collisions=M1PL $D009 Read
= Missile 1 to Player collisions=M2PL $D00A Read
= Missile 2 to Player collisions=M3PL $D00B Read
= Missile 3 to Player collisionsPlayer 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.=P0PL $D00C Read
= Player 0 to Player collisions=P1PL $D00D Read
= Player 1 to Player collisions=P2PL $D00E Read
= Player 2 to Player collisions=P3PL $D00F Read
= Player 3 to Player collisionsPlayer/Missile and Playfield Color and Luminance
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.COLPM0 $D012 Write
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.COLPM1 $D013 Write
SHADOW: PCOLOR1 $02C1 Color/luminance of Player and Missile 1.COLPM2 $D014 Write
SHADOW: PCOLOR2 $02C2 Color/luminance of Player and Missile 2.COLPM3 $D015 Write
SHADOW: PCOLOR3 $02C3 Color/luminance of Player and Missile 3.COLPF0 $D016 Write
SHADOW: COLOR0 $02C4 Color/luminance of Playfield 0.COLPF1 $D017 Write
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.COLPF2 $D018 Write
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.COLPF3 $D019 Write
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.COLBK $D01A Write
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. SeeMiscellaneous Player/Missile and GTIA Controls
PRIOR $D01B Write
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= 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 1hex/1dec through Fhex/15dec.) The least significant bit of the luminance value is not observed, so only the standard/CTIA 8 luminance values are available (, , , , , , , ). 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 20hex/32dec 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 98hex/152dec (blue) overlaps a Player pixel with color value 46hex/70dec (red) resulting in a pixel color of DEhex/228dec (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 $10hex/16dec 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, 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, 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.VDELAY $D01C Write
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.GRACTL $D01D Write
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.HITCLR $D01E Write
Clear Collisions Any write to this register clears all the Player/Missile collision detection bits.Other CTIA/GTIA Functions
Joystick Triggers
=TRIG0 $D010 Read
= SHADOW: STRIG0 $0284 Joystick 0 trigger=TRIG1 $D011 Read
= SHADOW: STRIG1 $0285 Joystick 1 trigger.=TRIG2 $D012 Read
= SHADOW: STRIG2 $0286 Joystick 2 trigger.=TRIG3 $D013 Read
= 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 $D014 Read
PAL flags. This register reports the display standard for the system. When Bits 3 to 0 are set to 1 (value $fhex/15dec) the system is operating in NTSC. When the bits are zero the system is operating in PAL mode.CONSPK $D01F Write
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.CONSOL $D01F Read
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 $4Player/Missile Graphics (sprites) operation
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 a0
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 GTIA enhancements
The GTIA chip isPOKE 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.
Bugs
The last Atari XE computers made for the Eastern European market were built in China. Many if not all have a buggySee also
*References
External links