Skip to content
RetrogamingDeep Dive Published Updated 7 min readViews unavailable

Atari 8-Bit GTIA Modes 9-11: PRIOR Bits and Color Interpretation

Trace Atari GTIA modes 9-11 from ANTIC mode-F pixels to PRIOR mode bits, color-register selection, BASIC behavior, and CTIA compatibility limits.

Atari BASIC names GRAPHICS 9, 10, and 11 as modes, but they are not three new ANTIC display-list instructions. ANTIC supplies the high-resolution mode-F pixel data; GTIA changes how each four-bit pixel value is interpreted. The selector shares a register with player/missile priority controls, so a program can have the right screen bytes and still show the wrong palette if it treats mode selection as a separate framebuffer format.

This guide covers Atari 400/800/XL/XE BASIC behavior and the stock GTIA interface. It does not specify CTIA color output, third-party video-chip replacements, analog palette calibration, or cycle-exact mid-scanline effects.

One pixel stream, three color interpretations

ANTIC mode F produces 80 pixels across by 192 rows for the GTIA modes. Each screen byte contributes two four-bit pixel values, so a row uses 40 bytes of image data. The raster dimensions and pixel storage do not change when the GTIA mode changes; the color meaning of each nibble does.

GTIA mode selection occupies the top two bits of the PRIOR register at $D01B (decimal 53275). The OS keeps a RAM shadow called GPRIOR at $026F (decimal 623), but it is not a second GTIA hardware register. Atari BASIC’s GRAPHICS command performs the normal setup. A custom display-list program must set the hardware mode bits as part of its own video setup.

PRIOR[7:6] BASIC mode Pixel-data interpretation
00 GRAPHICS 8 Ordinary high-resolution color interpretation
01 GRAPHICS 9 Pixel nibble selects luminance; background register supplies the hue
10 GRAPHICS 10 Pixel nibble selects one of nine configured color registers
11 GRAPHICS 11 Pixel nibble selects hue; background register supplies the common luminance

The mode values are therefore $40, $80, and $C0 in the top two bits for modes 9, 10, and 11 respectively. The lower six bits of PRIOR still encode player/playfield priorities and related player/missile options. If a custom kernel uses those features, keep their settings in your own software state and combine them with the mode bits when writing PRIOR; do not replace the complete byte with $40, $80, or $C0 without considering the rest of the register.

Use the pixel value according to the selected mode

In GRAPHICS 9, the four-bit pixel value is a luminance code from 0 through 15. COLOR selects that code when BASIC plots or draws; SETCOLOR 4 sets the background hue. A small test can make the distinction visible as vertical swatches:

10 GRAPHICS 9
20 SETCOLOR 4,8,0
30 FOR L=0 TO 15
40 COLOR L
50 PLOT L*5,20
60 DRAWTO L*5,30
70 NEXT L
80 GOTO 80

The COLOR values are not sixteen palette-register numbers in this mode. They select sixteen luminance codes applied to the one background hue. This makes mode 9 suitable for grayscale-like shading of a single color, but it does not give each pixel an arbitrary hue.

GRAPHICS 10 reverses that contract: each pixel value from 0 through 8 selects one of nine color registers. Its mapping is mode-specific: color indices 0 through 3 use player-register shadows 704 through 707; indices 4 through 7 use playfield-register shadows 708 through 711; index 8 uses the background register at shadow location 712. Do not read those slots as the usual color-0-through-color-4 mapping from another graphics mode. These are shared color-register shadows, not a palette bank independent of player/missile colors. Configure them before drawing. This example assigns hues 0 through 8 to the nine color indices at one luminance:

10 GRAPHICS 10
20 FOR R=704 TO 712
30 POKE R,(R-704)*16+6
40 NEXT R
60 FOR C=0 TO 8
70 COLOR C
80 PLOT C*8,20
90 DRAWTO C*8,32
100 NEXT C
110 GOTO 110

Those POKE addresses are OS color-shadow locations, not the GTIA chip’s $D000-range hardware registers. Each byte encodes hue in its upper nibble and luminance in the lower bits; the example uses luminance 6, an even value accepted by the ordinary color-register encoding. Indices 0 through 7 exercise the player and playfield registers; index 8 selects the background register. Mode 10 offers nine selectable register combinations, not nine fixed factory colors. Reconfigure the registers to test another palette, and keep COLOR indices in the documented 0-8 range.

In GRAPHICS 11, each pixel value from 0 through 15 chooses a hue while all playfield pixels use the luminance selected by the background register. For a BASIC test, use:

10 GRAPHICS 11
20 SETCOLOR 4,0,8
30 FOR H=0 TO 15
40 COLOR H
50 PLOT H*5,20
60 DRAWTO H*5,30
70 NEXT H
80 GOTO 80

The same pixel indices now traverse hues instead of luminances. The mode-9 and mode-11 examples are intentionally different ways of reading identical-width pixel values.

Keep the OS shadow and hardware write separate

For a BASIC program, prefer GRAPHICS 9, GRAPHICS 10, or GRAPHICS 11 to hand-editing GPRIOR: the screen handler constructs the display list and selects the corresponding PRIOR setting. The hardware register is the value that controls GTIA. The shadow at decimal 623 is the operating system’s copy used by system software. A program that changes PRIOR during visible output should maintain the full byte in its own state and write the hardware register at the intended raster event; do not assume changing the OS shadow performs a midline hardware update.

This separation is useful when debugging. First inspect which mode the program selected, then inspect the four-bit pixel data and the relevant palette inputs. For mode 9, verify the background hue and nibble values. For mode 10, verify each of the nine configured registers and that the pixel nibble is no greater than 8. For mode 11, verify both the selected hue nibble and the common background luminance. Only after those match should an emulator developer inspect host RGB conversion, filtering, or color-management output.

The three modes are GTIA features, not a guarantee that every early Atari 400/800 has them. Atari’s BASIC reference limits GRAPHICS 9-11 to systems with GTIA, and the field-service manual identifies GTIA as the extended-capability version of CTIA. A machine can accept the BASIC command or run a program without producing the intended GTIA interpretation if its video chip is CTIA. Confirm the target hardware before treating a CTIA display as an emulator palette bug.

Build a mode-decoding regression

An emulator or graphics library should test the value before converting it to host color. For a deterministic fixture, store one row containing pixel nibbles 0 through 15, render it once under each PRIOR[7:6] setting, and assert the mode-specific mapping separately from the final RGB table. Mode 10 needs a second fixture that gives each of its nine color registers a distinct hue/luminance pair and uses pixel values 0 through 8; a value above 8 should not be treated as another valid slot.

Compare the decoded pixel codes against a documented GTIA model, not just a screenshot. The Atari800 emulator’s pinned GTIA implementation builds mode-9 and mode-11 lookups from the background color plus, respectively, the pixel luminance nibble or hue nibble. Its ANTIC implementation also selects drawing paths from the high bits of PRIOR. That source is useful as an implementation cross-check, while Atari’s manuals remain the specification used here. A host palette can make a correct index look different from an analog display, so keep pixel-decoder tests and palette-rendering tests separate.

The examples above are source-reviewed BASIC procedures; no physical Atari or emulator run was performed for this draft. They validate mode/index relationships when run on a GTIA-equipped target, not calibrated NTSC/PAL color values. Record the machine and video standard with any capture, and do not use a monitor photograph as the only regression oracle.

Related:

Sources:

Comments