CTIA and GTIA

NTSC GTIA chip manufactured by Okidata

Color Television Interface Adaptor[1] (CTIA) and its successor Graphic Television Interface Adaptor[1] (GTIA) are custom chips used in the Atari 8-bit family of computers and in the Atari 5200 console. In these systems, a CTIA or GTIA chip works together with ANTIC to produce video display. ANTIC generates the playfield graphics (text and bitmap) while CTIA/GTIA provides the color for the playfield and adds overlay objects known as player/missile graphics (sprites). Under the direction of Jay Miner, the CTIA/GTIA chips were designed by George McLeod with technical assistance of Steve Smith.[2][3][4]

Color Television Interface Adaptor and Graphic Television Interface Adaptor are names of the chips as stated in the Atari field service manual.[1] Various publications named the chips differently, sometimes using the alternative spelling Adapter[5][6] or Graphics,[3] or claiming that the "C" in "CTIA" stands for Colleen/Candy[5] and "G" in "GTIA" is for George.[3][5][6][7]

History

2600 and TIA

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 that 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 technique drew the screen line-by-line from program code on the ROM cartridge, a technique known as "racing the beam".

CTIA

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.

CTIA 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.[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.

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:

Versions

by part number

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.

Pinout

Atari GTIA (C014805) pin-out
Pin Name Pin Number(s) Description
A0 - A4 2, 1, 40, 39, 38 Address Input
AN0 - AN2 18, 19, 20 ANTIC Interface Input
COL 21 Color Frequency Output
CS 32 Chip Select Input
CSYNC 25 Composite Sync Output
D0 - D7 7, 6, 5, 4, 37, 36, 35, 34 Data Bus I/O
DEL 17 Color Delay Line Input
FØ0 29 Fast Phase Clock Output
HALT 26 Halt Output
L0 - L3 31, 22, 23, 24 Luminance Output
N/C 16 Not Connected (PAL on later versions)
OSC 28 Oscillator Input
R/W 33 Read/Write Input
S0 - S3 12, 13, 14, 15 Switch Data I/O
T0 - T3 8, 9, 10, 11 Trigger Inputs with internal pull-up
Vdd 27 Power +5 Volts
Vss 3 Ground
Ø2 30 Computer Phase 2 Input

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.

Name Description Read/Write Hex Addr Dec Addr Shadow Name Shadow Hex Addr Shadow Dec Addr
HPOSP0 Horizontal Position of Player 0 Write $D000 53248
M0PF Missile 0 to Playfield collisions Read $D000 53248
HPOSP1 Horizontal Position of Player 1 Write $D001 53249
M1PF Missile 1 to Playfield collisions Read $D001 53249
HPOSP2 Horizontal Position of Player 2 Write $D002 53250
M2PF Missile 2 to Playfield collisions Read $D002 53250
HPOSP3 Horizontal Position of Player 3 Write $D003 53251
M3PF Missile 3 to Playfield collisions Read $D003 53251
HPOSM0 Horizontal Position of Missile 0 Write $D004 53252
P0PF Player 0 to Playfield collisions Read $D004 53252
HPOSM1 Horizontal Position of Missile 1 Write $D005 53253
P1PF Player 1 to Playfield collisions Read $D005 53253
HPOSM2 Horizontal Position of Missile 2 Write $D006 53254
P2PF Player 2 to Playfield collisions Read $D006 53254
HPOSM3 Horizontal Position of Missile 3 Write $D007 53255
P3PF Player 3 to Playfield collisions Read $D007 53255
SIZEP0 Size of Player 0 Write $D008 53256
M0PL Missile 0 to Player collisions Read $D008 53256
SIZEP1 Size of Player 1 Write $D009 53257
M1PL Missile 1 to Player collisions Read $D009 53257
SIZEP2 Size of Player 2 Write $D00A 53258
M2PL Missile 2 to Player collisions Read $D00A 53258
SIZEP3 Size of Player 3 Write $D00B 53259
M3PL Missile 3 to Player collisions Read $D00B 53259
SIZEM Size of all Missiles Write $D00C 53260
P0PL Player 0 to Player collisions Read $D00C 53260
GRAFP0 Graphics pattern for Player 0 Write $D00D 53261
P1PL Player 1 to Player collisions Read $D00D 53261
GRAFP1 Graphics pattern for Player 1 Write $D00E 53262
P2PL Player 2 to Player collisions Read $D00E 53262
GRAFP2 Graphics pattern for Player 2 Write $D00F 53263
P3PL Player 3 to Player collisions Read $D00F 53263
GRAFP3 Graphics pattern for Player 3 Write $D010 53264
TRIG0 Joystick 0 trigger. Read $D010 53264 STRIG0 $0284 644
GRAFM Graphics pattern for all Missiles Write $D011 53265
TRIG1 Joystick 1 trigger. Read $D011 53265 STRIG1 $0285 645
COLPM0 Color/luminance of Player and Missile 0. Write $D012 53266 PCOLOR0 $02C0 704
TRIG2 Joystick 2 trigger. Read $D012 53266 STRIG2 $0286 646
COLPM1 Color/luminance of Player and Missile 1. Write $D013 53267 PCOLOR1 $02C1 705
TRIG3 Joystick 3 trigger. Read $D013 53267 STRIG3 $0287 647
COLPM2 Color/luminance of Player and Missile 2. Write $D014 53268 PCOLOR2 $02C2 706
PAL PAL flags. Read $D014 53268
COLPM3 Color/luminance of Player and Missile 3. Write $D015 53269 PCOLOR3 $02C3 707
COLPF0 Color/luminance of Playfield 0. Write $D016 53270 COLOR0 $02C4 708
COLPF1 Color/luminance of Playfield 1. Write $D017 53271 COLOR1 $02C5 709
COLPF2 Color/luminance of Playfield 2. Write $D018 53272 COLOR2 $02C6 710
COLPF3 Color/luminance of Playfield 3. Write $D019 53273 COLOR3 $02C7 711
COLBK Color/luminance of Playfield background. Write $D01A 53274 COLOR4 $02C8 712
PRIOR Priority selection, fifth player, and GTIA modes Write $D01B 53275 GPRIOR $026F 623
VDELAY Vertical Delay P/M Graphics Write $D01C 53276
GRACTL Graphics Control. Write $D01D 53277
HITCLR Clear Collisions Write $D01E 53278
CONSPK Console Speaker Write $D01F 53279
CONSOL Console Keys Read $D01F 53279

In the individual register listings below the following legend applies:

Bit Value Description
0 Bit must be 0
1 Bit must be 1
? Bit may be either 0 or 1, and is used for a purpose.
- Bit is unused, or should not be expected to be a certain value
label Refer to a later explanation for the purpose of the bit.

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 0

HPOSP1 $D001 Write

Horizontal Position of Player 1

HPOSP2 $D002 Write

Horizontal Position of Player 2

HPOSP3 $D003 Write

Horizontal Position of Player 3

HPOSM0 $D004 Write

Horizontal Position of Missile 0

HPOSM1 $D005 Write

Horizontal Position of Missile 1

HPOSM2 $D006 Write

Horizontal Position of Missile 2

HPOSM3 $D007 Write

Horizontal Position of Missile 3

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
? ? ? ? ? ? ? ?

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:

Playfield Width in displayed Color Clocks Left Edge First Color Clock Right Edge Last Color Clock
Narrow $80hex/128dec $40hex/64dec $BFhex/191dec
Normal $A0hex/160dec $30hex/48dec $CFhex/207dec
Wide $B0hex/176dec $28hex/40dec $D7hex/215dec

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.

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 0

SIZEP1 $D009 Write

Size of Player 1

SIZEP2 $D00A Write

Size of Player 2

SIZEP3 $D00B Write

Size of Player 3

Player size controls:

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
- - - - - - Size 1 Size 0

Values:

Size Player Width Bits Value Size 1 Size 0
Normal 8 color clocks $00 0 0
Double 16 color clocks $01 0 1
Normal 8 color clocks $02 1 0
Quad 32 color clocks $03 1 1

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.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
M3 Size 1 M3 Size 0 M2 Size 1 M2 Size 0 M1 Size 1 M1 Size 0 M0 Size 1 M0 Size 0

Values:

Missile Size Missile Width Bits Value Size 1 Size 0
Missile 0 Normal 2 color clocks $00 0 0
Double 4 color clocks $01 0 1
Normal 2 color clocks $02 1 0
Quad 8 color clocks $03 1 1
Missile 1 Normal 2 color clocks $00 0 0
Double 4 color clocks $04 0 1
Normal 2 color clocks $08 1 0
Quad 8 color clocks $0C 1 1
Missile 2 Normal 2 color clocks $00 0 0
Double 4 color clocks $10 0 1
Normal 2 color clocks $20 1 0
Quad 8 color clocks $30 1 1
Missile 3 Normal 2 color clocks $00 0 0
Double 4 color clocks $40 0 1
Normal 2 color clocks $80 1 0
Quad 8 color clocks $C0 1 1

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 0

GRAFP1 $D00E Write

Graphics pattern for Player 1

GRAFP2 $D00F Write

Graphics pattern for Player 2

GRAFP3 $D010 Write

Graphics pattern for Player 3

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Pixel HPOS+0 Pixel HPOS+1 Pixel HPOS+2 Pixel HPOS+3 Pixel HPOS+4 Pixel HPOS+5 Pixel HPOS+6 Pixel HPOS+7

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

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
M3 Pixel HPOS+0 M3 Pixel HPOS+1 M2 Pixel HPOS+0 M2 Pixel HPOS+1 M1 Pixel HPOS+0 M1 Pixel HPOS+1 M0 Pixel HPOS+0 M0 Pixel HPOS+1

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:

Missile Bits Value Pixel 1 Pixel 0
Missile 0 $00 0 0
$01 0 1
$02 1 0
$03 1 1
Missile 1 $00 0 0
$04 0 1
$08 1 0
$0C 1 1
Missile 2 $00 0 0
$10 0 1
$20 1 0
$30 1 1
Missile 3 $00 0 0
$40 0 1
$80 1 0
$C0 1 1

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 (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

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 collisions

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
- - - - COLPF3 COLPF2 COLPF1 COLPF0

Missile 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 collisions

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
- - - - COLPM3 COLPM2 COLPM1 COLPM0

Player 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

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
- - - - COLPM3 COLPM2 COLPM1 0
P1PL $D00D Read

Player 1 to Player collisions

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
- - - - COLPM3 COLPM2 0 COLPM0
P2PL $D00E Read

Player 2 to Player collisions

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
- - - - COLPM3 0 COLPM1 COLPM0
P3PL $D00F Read

Player 3 to Player collisions

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
- - - - 0 COLPM2 COLPM1 COLPM0

Player/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:

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:

Color Registers' Bits:

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Color 3 Color 2 Color 1 Color 0 Luminance 3 Luminance 2 Luminance 1 (Luminance 0)

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:

Color Registers' Use per ANTIC Character Modes:

Register ANTIC 2 ANTIC 3 ANTIC 4 ANTIC 5 ANTIC 6 ANTIC 7
COLPM0/PCOLOR0
COLPM1/PCOLOR1
COLPM2/PCOLOR2
COLPM3/PCOLOR3
COLPF0/COLOR0 glyph pixel glyph pixel glyph glyph
COLPF1/COLOR1 glyph pixel (luma) glyph pixel (luma) glyph pixel glyph pixel glyph glyph
COLPF2/COLOR2 background background glyph pixel glyph pixel glyph glyph
COLPF3/COLOR3 glyph pixel glyph pixel glyph glyph
COLBAK/COLOR4 border border background background background background

Color Registers' Use per ANTIC Map Modes:

Register ANTIC 0 (blank lines) ANTIC 8 ANTIC 9 ANTIC A ANTIC B ANTIC C ANTIC D ANTIC E ANTIC F
COLPM0/PCOLOR0
COLPM1/PCOLOR1
COLPM2/PCOLOR2
COLPM3/PCOLOR3
COLPF0/COLOR0 pixel pixel pixel pixel pixel pixel pixel
COLPF1/COLOR1 pixel pixel pixel pixel pixel (luma)
COLPF2/COLOR2 pixel pixel pixel pixel background
COLPF3/COLOR3
COLBAK/COLOR4 background background background background background background background background border

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

Register GTIA $4 (BASIC 9) GTIA $8 (BASIC 10) GTIA $C (BASIC 11)
COLPM0/PCOLOR0 background
COLPM1/PCOLOR1 pixel
COLPM2/PCOLOR2 pixel
COLPM3/PCOLOR3 pixel
COLPF0/COLOR0 pixel
COLPF1/COLOR1 pixel
COLPF2/COLOR2 pixel
COLPF3/COLOR3 pixel
COLBAK/COLOR4 background base color pixel background base luma

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.

Miscellaneous 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.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
GTIA Mode 1 GTIA Mode 0 Multi-Color Player Fifth Player Priority 3 Priority 2 Priority 1 Priority 0

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:

GTIA Mode Bits [7:6] Feature Description
0 0 = $00 Default Same as CTIA. Normal color register usage.
0 1 = $40 GTIA/16 Shades 16 shades of background color ( COLBK )
1 0 = $80 GTIA/9 color All nine Playfield and Player/Missile color registers are available on the Playfield. The background is COLPM0
1 1 = $C0 GTIA/16 Color 15 colors at one luminance level set by the background register (COLBK), plus the background.

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 ($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 $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:

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:

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

Priority Bits [3:0] 0 0 0 1 = $1 0 0 1 0 = $2 0 1 0 0 = $4 1 0 0 0 = $8 0 0 0 0 = $0
Top PM0 PM0 P5/PF0 P5/PF0 PM0
PM1 PM1 PF1 PF1 PM1
PM2 P5/PF0 PF2 PM0 P5/PF0
PM3 PF1 PF3 PM1 PF1
P5/PF0 PF2 PM0 PM2 PM2
PF1 PF3 PM1 PM3 PM3
PF2 PM2 PM2 PF2 PF2
PF3 PM3 PM3 PF3 PF3
Bottom COLBK COLBK COLBK COLBK COLBK

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:

Color COLPM0 COLPM1 COLPF0 COLPF1 Color COLPM2 COLPM3 COLPF2 COLPF3
1 X 12 X
2 X 13 X
3 X X 14 X X
4 X 15 X
5 X X 16 X X
6 X X 17 X X
7 X X X 18 X X X
8 X 19 X
9 X X 20 X X
10 X X 21 X X
11 X X X 22 X X X

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.

Priority Bits [3:0] COLPF2 vs COLPM0 and COLPM1 COLPF2 vs COLPM2 and COLPM3
0 0 0 0 = $00 Player/Missile Player/Missile OR'd with COLPF2
0 0 0 1 = $01 Player/Missile Player/Missile
0 0 1 0 = $02 Player/Missile COLPF2
0 0 1 1 = $03 Player/Missile True Black
0 1 0 0 = $04 COLPF2 COLPF2
0 1 0 1 = $05 COLPF2 True Black
0 1 1 0 = $06 COLPF2 COLPF2
0 1 1 1 = $07 COLPF2 True Black
1 0 0 0 = $08 Player/Missile Player/Missile
1 0 0 1 = $09 Player/Missile Player/Missile
1 0 1 0 = $0A Player/Missile True Black
1 0 1 1 = $0B Player/Missile True Black
1 1 0 0 = $0C COLPF2 True Black
1 1 0 1 = $0D COLPF2 True Black
1 1 1 0 = $0E COLPF2 True Black
1 1 1 1 = $0F COLPF2 True Black

VDELAY $D01C Write

Vertical Delay P/M Graphics

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Player 3 Player 2 Player 1 Player 0 Missile 3 Missile 2 Missile 1 Missile 0

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

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
? ? ? ? ? Trigger Latch Enable Players Enable Missiles

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

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
? ? ? ? ? ? ? ?

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

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Trigger
0 0 0 0 0 0 0 ?

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.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
- - - - Video 3 Video 2 Video 1 Video 0

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

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
0 0 0 0 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

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
- - - - - Option Select Start

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:

Player/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 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.

GTIA Enhancements

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:

Of these modes, Atari BASIC Graphics 9 is particularly notable. It enables the Atari to display gray-scale 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.

Bugs

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.

Limitations

The following is a summary of hardware/feature limitations some of which can be circumvented by software (display list interrupts or display kernels.):

The display generator outputs pixels within the horizontal range $22hex/34dec to $DDhex/221dec. (188 color clocks wide). Player/Missile pixels outside this range are not generated and so do not register collisions.

Four Player objects 8 bits wide, and four Missile objects 2 bits wide per scan line.

One Player/Missile bit may be 1, 2, or 4 color clocks wide.

While the additional GTIA color interpretation modes can be enabled for any kind of ANTIC Playfield graphics, the full range of color capability is available only in the ANTIC modes based on high-resolution, 1/2 color clock pixels (that is, ANTIC text modes 2, 3, and graphics mode F).

The color palette is 128 colors (8 shades of 16 colors) for normal color interpretation mode, and GTIA modes $8 and $C (BASIC GRAPHICS mode 10 and 11).

The color palette is 256 colors (16 shades of 16 colors) for GTIA color interpretation mode $4 (BASIC GRAPHICS mode 9).

9 color registers are available—four for Players/Missiles, four for Playfield pixels, and one register (COLPF3) shared by the Playfield and Fifth Player option.

The color produced from merging multiple Players and merging Player/Missile and Playfield graphics is the result of binary OR'ing the two source colors which limits the resulting, merged color value.

All Playfield and Player/Missile color registers plus the Multi-Color Player option combined with the Priority option merging Player/Missile and Playfield colors generate 23 colors per scan line.

While GTIA pixels have 16 values ($0 to $F) color interpretation mode $8 (BASIC GRAPHICS mode 10) can use only 9 pixel values—one per color register.

See also

References

  1. 1 2 3 Atari Home Computer Field Service Manual - 400/800 (PDF). Atari, Inc. pp. 1–10. Retrieved 2010-09-10.
  2. ↑ Neubauer, Doug (2009-06-20). "The Atari Years, by Doug Neubauer. Star Raiders, Solaris and Pokey". DougNeubauer.com.
  3. 1 2 3 Sherer, Robin Alan (June 1988). "GTIA Joystick Painter - Powerful Atari Animation Tool". ANTIC 7 (2): 37. ISSN 0113-1141. Retrieved 2011-01-26.
  4. ↑ US patent 4296476, Mayer, Steven T.; Miner, Jay G.; Neubauer, Douglas G.; Decuir, Joseph C., "Data processing system with programmable graphics generator", issued 1 981-10-20, assigned to Atari, Inc.
  5. 1 2 3 4 5 Patchett, Craig; Sherer, Robin (1984). "Special Chips and ROM". The Master Memory Map for the Atari. Reston, Va.: Reston Publishing Company. ISBN 0-8359-4242-2. Retrieved 2011-01-26.
  6. 1 2 3 4 5 Mace, Scott (1982-03-15). "Atari quietly switches to a 16-color graphics chip". InfoWorld (Palo Alto, CA: Popular Computing) 4 (10): 3–4. ISSN 0199-6649. Retrieved 2011-02-01.
  7. 1 2 Chamberlain, Craig (July 1982). "Atari Video Graphics And The New GTIA". Compute! (26): 124. ISSN 0194-357X. Retrieved 2011-01-24.
  8. 1 2 3 Joe Decuir, "3 Generations of Game Machine Architecture", CGEXPO99
  9. 1 2 Small, David; Small, Sandy; Blank, George (May 1983). "Design Philosophy and GTIA Demos". The Creative Atari. Creative Computing Press. ISBN 978-0-916688-34-9. Retrieved 2011-01-26.
  10. ↑ Switzer, Steve (October 1983). "Atari Clinic". ANTIC 2 (7): 103. ISSN 0113-1141. Retrieved 2011-02-01.
  11. ↑ Michael Current, "What are the SALLY, ANTIC, CTIA/GTIA, POKEY, and FREDDIE chips?", Atari 8-Bit Computers: Frequently Asked Questions
  12. 1 2 3 4 5 Boris, Dan. "Atari Chips". Dan B's Home Page. Retrieved 2011-02-01.
  13. ↑ Vendel, Curt. "Atari 800XLCR". AtariMuseum.com. Retrieved 2011-02-01.
  14. ↑ Vendel, Curt. "KERI Performance Tester". AtariMuseum.com. Retrieved 2011-02-01.
  15. ↑ Small, David; Small, Sandy; Blank, George, ed. (1983). "The Wizard, the Princess, and the Atari". The Creative Atari. Creative Computing Press. ISBN 0916688348.

External links

This article is issued from Wikipedia - version of the Wednesday, April 27, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.