What are GTIA-Modes? (my own description, just take a look onto this picture)

Well, Atari built 2 graphic-custom-chips into this great 8-bit workstation ;), one is called ANTIC, the 2nd is called GTIA ("Graphic Television Interface Adaptor"). The GTIA is the chip between the ANTIC and your monitor/tv-set. The main task of the GTIA is to convert the data which the Antic produces into a complete picture for the monitor.
Another job is to produce the player/missle-grafic.
But I dont want to bore you with things that you already know. What do I mean if I am talking about "GTIA-modes"?. If you have read the Antic-capture carefully then you have recognized that there are modes missing which you can access via BASIC... the Basic-Modes 9,10,11.
Actually this modes are Gr.8-Modes! But you can tell the GTIA to take the bits of this hires-mode to interprate the bits in another way. The main structure of such modes is that 4 bits (aka nibbles) are now selecting their display-option. As we have 8 bits in 1 byte and now 4 bits are grouped together we can display 2 pixels with 1 byte. For a "normal" 320 pixel wide scanline in gr.8 (40 bytes a 8 bits = 320) we can display 80 pixels in the gtia-modes!
But why are all new demos using this modes? why are they so special?
You can use the GTIA to display more colors or shades then in the other modes possible! You just have to select the modes by moving following values into the GTIA-Ctrl-Register $26f,$d01b:Bit7 Bit6 0 0 normal mode...as usual 0 1 so called "mode9". Same as basic-gr.9. 1 color in 16 shades 1 0 so called "mode10". Basic-gr.10. 9 colors in different shades 1 1 so called "mode11". Basic-gr.11. 16 colors in 1 shade
As I have told you 4 bits are grouped together. With 4 Bits it is possible to select 16 different values (2^4 = 16). So this 16 values are interpretated by the GTIA in that way how you have selected in the GTIAMODE-register.
Mode9: you define a basic-color via the background-color-register $d01a,712
by putting $00,$10,$xx,$f0 there. But be carefull! Don`t set bits 0-3
So $02,$18,... is wrong and will reduce the maximum amount of shades!
Mode10:The Atari has 9 different color-registers, 704-712 (inclduing the
PM-color-registers 704-707+711. So we can theoreticly select 16 color-
registers but as we have just 9 the others are not possible! Keep that
in mind! In this mode the nibbles are not allowed to be greater than
9! ($00-$08). The GTIA takes the nibble value, adds 704 and gets the
color-value stored there and puts the pixel with that color on screen!
In this mode you can define 9 different colors! (you are not limited
in your selectin, all colors are possible).
Mode11:Similar to Mode9 but instead of using the background-color for defining
the basic-color, GTIA uses this information for the basic-brightness of
all 16 basic-XL-Colors! (the so called rainbow-colors).
There is one BIG difference between mode10 and mode9+mode11... (This is esp. for emulator-coders!!!) In Mode10 every pixel is shifted 1/2 mode10 pixel to the left/right compared to mode9,11 !!! This is now a well known GTIA-"BUG" and used in the new fantastic grafic-mode called HIP.
So these modes are well known. But they have one disadvantage... The resolution of the GTIA-modes is 80x192 (in general) so we have a pixel ratio of 4:1. This means that the pixels aren`t quadratic. This is bad for most demo-fx, so what are clever demo-coder like us do? Well, if you have read the ANTIC part carefully then you may recognize that we can build with usage of the ANTIC-display-list-commands our own custom modes where we can create a 1:1 ratio... so best resolution could be 96x60 pixels. We "double" each scanline twice via the lms-command and get the so called "mode9+":
dlist dfb $4f ($40 = lms-command in mode $0f = gr.8)
dfw scanline0
dfb $4f
dfw scanline0
dfb $4f
dfw scanline0
dfb $4f
dfw scanline0
dfb $4f
dfw scanline1
dfb $4f
dfw scanline1
...
But this is stupid to do this by "hand" in your source-code. Remember
you have to enter 192x3 commands! Boring stuff. So let me show you my
"Mode9-Generator":
dlinit lda #dlist ; where to generate the custom-display-list?
sta adr ; zero-page-pointer f.e. $b0
lda #>dlist ; hi-byte
sta adr+1
lda #screen ; our screen-ram
sta scradr
lda #>screen
sta scradr+1
ldx #58 ; 80x58 is our new resolution...
dl0 lda #$4f ; set commands into dlist
ldy #0 ; 4 times... look above
sta (adr),y
ldy #3
sta (adr),y
ldy #6
sta (adr),y
ldy #9
sta (adr),y
lda scradr ; set now low-byte
ldy #1
sta (adr),y
ldy #4
sta (adr),y
ldy #7
sta (adr),y
ldy #10
sta (adr),y
lda scradr+1 ; and now hi-byte
ldy #2
sta (adr),y
ldy #5
sta (adr),y
ldy #8
sta (adr),y
ldy #11
sta (adr),y
; we have set now the 4 scanline-commands with the same scanline!
; but now we have to move the adr-counters forward
clc
lda adr
adc #12 ; 4*3 bytes in the dlist! look into your debugger!
sta adr
lda adr+1
adc #0
sta adr+1
clc
lda scradr ; and the next scanline!
adc #40 ; 40 bytes per line, depends on YOU...
sta scradr
lda scradr+1
adc #0
sta scradr+1
dex ; 58x
bpl dl0
;STOP! we are not finished! we must now set the $41 command to stable the
;monitor-picture...
ldy #0
lda #$41
sta (adr),y
iny ; saves 1 byte... same as ldy #1 ;)
lda #dlist
sta (adr),y
iny
lda #>dlist
sta (adr),y
rts
So you have to initialize your new display-list f.e. with this code:
init jsr dlinit ; initialize mode9
lda #0 ; stop interrupts
sta nmien ; $d40e
lda #dlist
sta dlistv ; $230,$231
lda #>dlist
sta dlistv+1
lda #$40 ; vbi enabled
sta nmien
lda #$40 ; hey... without this we have just a mode8+ (gr.8) screen ;)
sta gtiamode ; $26f = pm-priors+gtia-modes
...
But what about using macros to make your coding-life easier? The following code is for the MACROASS XE V4.3 by T. Karwoth (my fave ass) but this should be no problem via adapting into other assemblers syntax of macros...
add MAC 2 ; the 16-bit macro with 2 variables
clc
lda ?1
adc #?2
sta ?1
lda ?1+1
adc #0
sta ?1+1
END
move MAC 2 ; 16-bit poke
lda #?2
sta ?1
lda #>?2
sta ?1+1
END
set MAC 1 ; sets the LMS-command in the display-list
ldy #?1
sta (adr),y
END
; so the dlinit-code looks like this:
dlinit .move screen,scradr
.move dlist,adr
ldx #58
dl0 lda #$4f
.set 0
.set 3
.set 6
.set 9
lda scradr
.set 1
.set 4
.set 7
.set 10
lda scradr+1
.set 2
.set 5
.set 8
.set 12
.add scradr,40
.add adr,12
dex
bpl dl0
...
Looks simpler and easier to read, don`t you think so?
Thats all! But why are nearly all new demos use this kind of modes? Well, to be honest they use another variation of mode9+ because they leave out every 2nd scanline by putting there a blank-scanline (command $00). This saves cpu-cycles because the lms-commands takes more cycles than a "normal" ANTIC command. But I prefer a "true" mode9+. See our "r34lly unr34l"-intro and compare the grafix with f.e. Shadows "Asskicker"-demo.But the most advantages are:
; setting pixel with shade $09 on position 2,3 lda screen+3*40+(2 div 2) and #$f0 ; keep pixel on pos. 1,3 ora #$09 sta screen+3*40+(2 div 2)
Demo-Coders may see the advantage compared to gr.15 .) If you are clever enough by using simpler routines (but more clever) your display-code for mode9+ clould look like this:
display_fx ldx $a0
lda texturelo,x
ldx $a1
ora texturehi,x
sta screen
ldx $a2
lda texturlo,x
ldx $a3
ora texturhi,x
sta screen+1
...
Where texturlo is the grafic in %0000xxxx form and texturhi the graphic shifted 4 times to the left (*16) %xxxx0000. So no calculating of the correct pixel-values is necessary...
Last changes: 19 Jun 1997
Feel free to contact me for any legal reason!
HeAvEn, Member of TaquarT