GTIA Modes...

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

really unreal-intro

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:

  • 16 shades for nice demo fx. 12 more than in gr.15 ;)
  • 1:1 ratio, so you don`t have to deal with correction of 4:1 ratios...
  • 80x60 = 2400 bytes in screen-ram, you can manipulate this often in 1 VBI! Compare this with f.e. 80x192 of normal gr.9 (7680 bytes!!!)
  • easy adressing of the pixels... We have "90%" VGA-mode ;) In 1 screen-byte we have 2 pixels! So f.e. in gr.15 we have to deal with 4 pixels per byte! this makes setting pixels very easy. Take a look:
       ; 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...

    back to main-index



    Last changes: 19 Jun 1997

    Amiga_logo

    Feel free to contact me for any legal reason!


    email_icon HeAvEn, Member of TaquarT