jeżeli dobrze pamiętam po każdym wystąpieniu przerwania IRQ od POKEY-a trzeba skasować bit odpowiadający za wystąpienie przerwania w IRQEN ($d20e) a następnie ustawić bit ponownie. Chodzi o potwierdzenie odebrania przerwania oraz dopuszczenie następnego przerwania.

nie bardzo rozumiem gdzie masz to SEI i CLI.

STIMER ($D209) nie trzeba zapisywać w procedurze przerwania. Można to zrobić tylko raz po ustawieniu wektorów i IRQEN ($d20e).

pozdrawiam
Seban

dzięki za odpowiedzi, oczywiście jak zwykle zapomniałem dodać, że w proc. przerwania najpierw kasuje a potem ustawiam na #1 $d20e, samo przerwanie wywołuje zaś nie cli sei a sei cli , zaraz to poprawie
@Seban:
cli/sei używam w pętli rysującej 1 z 8 podstawowych linii, w przerwaniach dodaje dodatkowe przesunięcia tak, że z 8 linii powstaje mi 58 na każdą ćwiartkę okręgu.

Panowie, jakieś jeszcze inne sugestie, co tu może źle działać?

mono, czy w takim razie jeśli wygenerowany zostaje sygnał przerwania po odliczeniu $d200 to procesor "czeka" aż zostanie umożliwione przerwanie irq czy w przypadku gdy nie jest ono możliwe po prostu ignoruje go? czy sygnał w procesorze jest sutawiony dopóki przerwanie się nie odbędzie?

Hej!

to może ja się wtrącę... przykładowy kod działający na real Atari i pod Altirrą :) (brzydki i nieładnie napisany ,ale działa ;] chodzi tylko o przykład jak może wyglądać działająca procedura obsługi POKEY-owego timera)

        opt    h+
        org    $a000
    
st      sei                 ; disable IRQ
        inc    $d40e        ; disable NMI
        lda    $d40b        ; wait for vertical sync
        bne    *-3
        sta    $d400        ; turn off screen!

        lda    #$fe        ; turn off OS-ROM!
        sta    $d301

        ldx    <irq        ; set new IRQ vector
        ldy    >irq
        stx    $fffe
        sty    $ffff
    
        lda    #$03        ; init POKEY
        sta    $d20f
    
        lda    #$00        ; set timer freq
        sta    $d208
    
        lda    #$00        ; set channel #0 volume
        sta    $d201
    
        lda    #$7e        ; set time #0 frequency
        sta    $d200
        
        lda    #$01        ; enabnle TIMER0 IRQ
        sta    $d20e
        sta    $d209       ; reset timers!
    
        cli            ; enable IRQ
        jmp    *        ; loop! :)
    
irq        sta    reg_A+1        ; save A reg.

val        lda    #$08        ; change border color!
        sta    $d01a
        eor    #$38
        sta    val+1
    
        lda    #$00        ; clear IRQ status!
        sta    $d20e        
        lda    #$01        ; enable timer #0 IRQ
        sta    $d20e

reg_A        lda    #$00        ; restore A reg.
        rti            ; return from iterrupt!
    
        run    st        ; RUN vector
        
        
    

Procesor zajmuje się wykonywaniem Twojego programu. W momencie kiedy pojawi się sygnał przerwania ustawiana jest odpowiednia flaga żądania obsługi w IRQST. Jeśli znacznik I procesora jest zgaszony (a gasi go rozkaz CLI), wtedy wykonywanie programu jest zawieszane, a CPU zajmuje się wykonaniem procedury obsługi przerwania. Po wykonaniu obsługi wraca z powrotem do wykonywania programu od miejsca w którym mu przerwano.
Jeśli znacznik I jest ustawiony, to CPU nie wykonuje przerwania. Do chwili kiedy nie skasujesz flagi I po prostu przerwania nie będą obsługiwane, ale odpowiednie znaczniki ciągle będą się palić w IRQST. Jak odblokujesz przerwania (CLI), wtedy procesor będzie ciągle przerywał Twój program i będzie obsługiwał przerwania do chwili kiedy w IRQST nie zniknie ostatnie żądanie. Żądanie obsługi przerwania znika kiedy następuje potwierdzenie jego obsługi - odbywa się to przez Twoją procedurę obsługi przerwania w sposób, jaki opisano wyżej - przez zablokowanie danego przerwania w IRQEN i ponowne jego włączenie w tym samym rejestrze.

Edit: Jeśli źródło przerwań zgłasza je często (TIMER1 może to robić BARDZO często - szczególnie z ustawionym zegarem 1.77MHz), może się zdarzyć, że podczas obsługi przerwania nadejdzie nowe żądanie. Wtedy po zakończeniu obsługi bieżącego przerwania CPU od razu wejdzie z powrotem do procedury obsługi przerwania.

czyli jednym słowem procesor nie wygeneruje przerwania w krótkiej chwili pomiędzi cli/ sei jeżeli w tym momencie nie dostanie sygnału przerwania z pokeya, który to sygnał się nie utrzymuje "na linii" a chwilowo jest wysyłany
kurde, z tego co widze to raczej ta procka nie zadziała

czyli teoretycznie jeżeli wysłany jest sygnał przerwania to CLI  POWINNO "spowodować skok" do procedury przerwania, tak? nic już nie rozumiem :/

UFFF,czyli jednak robię to dobrze dzięki ludziska, jutro sprawdzę na Atarynce jak to wygląda i poszukam ew. błędu

tak, jest to celowe, akumulator jeżeli procka jest wywoływana po CLI nie gra roli, a rejestry X i Y są potrzebne do procki rysującej, zarzucam przykładowy kod:

rbyte3      ; \ minus 40-32 w stronę pionu
  cli
  sei
  lda #0
  clc
  adc tab2,x
  sta $f2
  lda ($f2),y
  ora tab3,x
  sta ($f2),y
  dex
rb32
  lda #$20
  adc tab2,x
  sta $f2
  lda ($f2),y
  ora tab3,x
  sta ($f2),y

rb33
  lda #$40
  adc tab2,x
  sta $f2
  lda ($f2),y
  ora tab3,x
  sta ($f2),y
  dex
rb34
  lda #$60
  adc tab2,x
  sta $f2
  lda ($f2),y
  ora tab3,x
  sta ($f2),y 
rb35
  cli
  sei
  lda #$80
  adc tab2,x
  sta $f2
  lda ($f2),y
  ora tab3,x
  sta ($f2),y
rb36
  lda #$a0
  adc tab2,x
  sta $f2
  lda ($f2),y
  ora tab3,x
  sta ($f2),y 
  dex
rb37
  lda #$c0
  adc tab2,x
  sta $f2
  lda ($f2),y
  ora tab3,x
  sta ($f2),y
rb38
  lda #$e0
  adc tab2,x
  sta $f2
  lda ($f2),y
  ora tab3,x
  sta ($f2),y 
rbyte3loop
 inc $f3
 dec $f5
 bne rbyte3
 sei
 rts

i procka IRQ:

irq2r lda #0  ; byte1,byte2 dla byte3,byte4-7 reversed
 sta $d20e
 dex
 lda #1
 sta $d20e
 sta $d209
 rti

edit: być może błąd jest spowodowany wywołaniem przerwania poza procką rysującą, wtedy rejestry mogą się mieszać

tak, drawto. akurat tu tego nie widać ale mierząc cyklami to ta procka będzie szybsza od drawto z paczki MADS o jakieś 25 %, w niektórych przypadkach nawet 40-50 %. niestety gorzej będzie z tego co się zorientowałem z precyzją , ale coś za coś

tutaj pomysł jest taki, że w pętli stawia się punkty bez liczenia tego czy przesunąć pixel w bok czy nie za każdym razem jak to jest w algorytmie bresenhama, za coś takiego odpowiada odpowiednio często wywoływane przerwanie, to z grubsza pomysł na tą prockę

możesz rozwinąć wypowiedź ?:)