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

Ostatnio edytowany przez seban (2011-08-18 16:43:36)

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ć?

Ostatnio edytowany przez gorgh (2011-08-18 16:49:27)

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?

Ostatnio edytowany przez gorgh (2011-08-18 16:52:48)

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
        
        
    

Ostatnio edytowany przez seban (2011-08-18 17:09:46)

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.

Ostatnio edytowany przez mono (2011-08-18 17:08:03)

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

Ostatnio edytowany przez gorgh (2011-08-18 17:19:14)

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ć

Ostatnio edytowany przez gorgh (2011-08-18 17:42:46)

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ś

Ostatnio edytowany przez gorgh (2011-08-18 19:37:04)

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ź ?:)