18.11.2023 18:12
[#1]
Przerwania - poziom 3
Cześć, to mój pierwszy wpis na forum :)
Mam pytanie dot. przerwań na poziomie 3.
Chodzi mi o to czy gdy wywoływana jest procedura obsługi przerwania to czy można się podziewać, że jej wywołanie będzie dotyczyło zarówno Vertb, blittera, a może i coppera jednocześnie ?
Czyli, że jak będę testował w procedurze obsługi bity 4, 5, 6 z INTREQR to 2 lub 3 z nich będą zapalone. Czy coś takiego w praktyce jest możliwe ?
Czy też jest tak, że procedura obsługi jest wywoływana osobno dla poszczególnych "źródeł" ?
Pozdro.
Mam pytanie dot. przerwań na poziomie 3.
Chodzi mi o to czy gdy wywoływana jest procedura obsługi przerwania to czy można się podziewać, że jej wywołanie będzie dotyczyło zarówno Vertb, blittera, a może i coppera jednocześnie ?
Czyli, że jak będę testował w procedurze obsługi bity 4, 5, 6 z INTREQR to 2 lub 3 z nich będą zapalone. Czy coś takiego w praktyce jest możliwe ?
Czy też jest tak, że procedura obsługi jest wywoływana osobno dla poszczególnych "źródeł" ?
Pozdro.
18.11.2023 20:22
[#2]
Re: Przerwania - poziom 3
@zbrożo, post #1
Osobno dla poszczególnych źródeł. VBL to VBL, blitter to blitter.
Po co masz testować INTREQR? Dodajesz swoją procedurę obsługi przerwania, zastępując już istniejącą w sposób systemowy lub nie, w zależności od tego jaki to ma być program i co chcesz osiągnąć.
Pozdrawiam.
Ostatnia aktualizacja: 18.11.2023 20:35:38 przez zilog
Po co masz testować INTREQR? Dodajesz swoją procedurę obsługi przerwania, zastępując już istniejącą w sposób systemowy lub nie, w zależności od tego jaki to ma być program i co chcesz osiągnąć.
Pozdrawiam.
Ostatnia aktualizacja: 18.11.2023 20:35:38 przez zilog
18.11.2023 22:23
[#3]
Re: Przerwania - poziom 3
@zilog, post #2
Niesystemowo masz handler dla danych poziomów i tam faktycznie jeśli chcesz wiedzieć co wywołało przerwanie to musisz testować intreqr. Ba, jeśli np będziesz tylko czyścił bit od coppera a ten od blittera będzie dalej ustawiony, to po wyjściu z handlera procek wejdzie do niego ponownie. O ile pozostałe bity w intena są włączone.
Wracając do meritum - co prawda może się wydawać że takie rzeczy nie wystąpią równocześnie, ale te bity też mogą zapalać się w czasie handlowania przerwania powodowanego przez inne bity.
Sprawdzaj każdy bit po kolei, zapisuj które były handlowane i czyść na koniec handlera.
Ostatnia aktualizacja: 18.11.2023 22:29:08 przez teh_KaiN
Wracając do meritum - co prawda może się wydawać że takie rzeczy nie wystąpią równocześnie, ale te bity też mogą zapalać się w czasie handlowania przerwania powodowanego przez inne bity.
Sprawdzaj każdy bit po kolei, zapisuj które były handlowane i czyść na koniec handlera.
Ostatnia aktualizacja: 18.11.2023 22:29:08 przez teh_KaiN
18.11.2023 22:50
[#4]
Re: Przerwania - poziom 3
@zbrożo, post #1
W zasadzie to nie sprecyzowałeś czy robisz to w sposób zgodny z OS czy nawalanie po rejestrach. W pierwszym przypadku dodajesz za pomocą funkcji exec AddIntServer i masz wywalone, bo tam zdaje się są priorytety (Exec Software Priority). Tu musiałby się wypowiedzieć ktoś kto ma doświadczenie. Ja dodawałem tylko VERTB w sposób zgodny z OS. Drugi przypadek jest bardziej skomplikowany.
To zależy co ustawiłeś w INTENA. Jeśli jest to tylko jedno z tychże trzech to jest to przypadek który opisał Zilog i cześć.
Sprawa się komplikuje gdy pozwalasz na więcej niż jedno źródło dla danego poziomu przerwania. Nie wiem czy jest możliwe by jednocześnie zostały ustwione bity na przykład blitera i coppera w INTREQR. Nawet jeśli jest to możliwe to wtedy można by to ograć tak jak napisałeś, testujesz najpierw czy to przerwanie coppera, wykonujesz odpowiedni kod, potem sprawdzasz czy to przerwanie blittera, wykonujesz kod i na koniec zgłaszasz że przerwanie zostało obsłużone.
A co będzie gdy w trakcie wykonywania przerwania coppera zostanie zgłoszone przerwanie blittera. Jako że nie jest to poziom wyższy niż ten który jest wykonywany to jest w stanie 'pending' i jeśli po wykonaniu kodu przerwania coppera zgłosisz że przerwanie zostało obsłużone to zostanie pominięte przerwanie blittera.
A może też być tak że masz przerwania blittera i następuje przerwanie coppera. Te dwa przypadki napisałem tylko po to żeby nie przyszła do głowy taka myśl, że możemy to obsłużyć na zasadzie jak w przypadku gdy oba przerwania wystąpiły w tym samym czasie, bo w jakimś przypadku któreś przerwanie zostanie pominiętę. Wydaje się to niemożliwe, ale w grze na przykład możemy mieć wiele niedużych obiektów narzucanych na ekran za pomocą przerwania blittera i wtedy jest przypadek że przerwanie blittera może wystąpić w przerwaniu coppera. Albo możemy mieć pod koniec planszy walkę z dużym przeciwnikiem (też narzucanym przez przerwanie blittera) i wtedy mamy sytuację odwrotną.
Niewłaściwa obsługa tego może powodować ciekawe błędy w grze.
Najlepiej opisał to Kalms na EAB link
czy gdy wywoływana jest procedura obsługi przerwania to czy można się podziewać, że jej wywołanie będzie dotyczyło zarówno Vertb, blittera, a może i coppera jednocześnie ?
To zależy co ustawiłeś w INTENA. Jeśli jest to tylko jedno z tychże trzech to jest to przypadek który opisał Zilog i cześć.
Sprawa się komplikuje gdy pozwalasz na więcej niż jedno źródło dla danego poziomu przerwania. Nie wiem czy jest możliwe by jednocześnie zostały ustwione bity na przykład blitera i coppera w INTREQR. Nawet jeśli jest to możliwe to wtedy można by to ograć tak jak napisałeś, testujesz najpierw czy to przerwanie coppera, wykonujesz odpowiedni kod, potem sprawdzasz czy to przerwanie blittera, wykonujesz kod i na koniec zgłaszasz że przerwanie zostało obsłużone.
A co będzie gdy w trakcie wykonywania przerwania coppera zostanie zgłoszone przerwanie blittera. Jako że nie jest to poziom wyższy niż ten który jest wykonywany to jest w stanie 'pending' i jeśli po wykonaniu kodu przerwania coppera zgłosisz że przerwanie zostało obsłużone to zostanie pominięte przerwanie blittera.
A może też być tak że masz przerwania blittera i następuje przerwanie coppera. Te dwa przypadki napisałem tylko po to żeby nie przyszła do głowy taka myśl, że możemy to obsłużyć na zasadzie jak w przypadku gdy oba przerwania wystąpiły w tym samym czasie, bo w jakimś przypadku któreś przerwanie zostanie pominiętę. Wydaje się to niemożliwe, ale w grze na przykład możemy mieć wiele niedużych obiektów narzucanych na ekran za pomocą przerwania blittera i wtedy jest przypadek że przerwanie blittera może wystąpić w przerwaniu coppera. Albo możemy mieć pod koniec planszy walkę z dużym przeciwnikiem (też narzucanym przez przerwanie blittera) i wtedy mamy sytuację odwrotną.
Niewłaściwa obsługa tego może powodować ciekawe błędy w grze.
Najlepiej opisał to Kalms na EAB link
19.11.2023 08:48
[#5]
Re: Przerwania - poziom 3
@asman, post #4
Chyba za bardzo wczoraj odleciałem z tym pomijaniem przerwań, tak to jest jak się piszę z pamięci zamiast zwyczajnie po ludzku sprawdzić. Bo to chyba będzie tak jak napisał teh_KaiN. Przepraszam za zamieszanie.
Chyba że mamy długo trwające przerwanie i nastąpi takie samo przerwanie w czasie trwania tegoż przerwania, na przykład VERTB. To wtedy faktycznie może się tak zdarzyć.
Jakbym pisał jakieś kalumnie to mnie zwyczajnie poprawcie. Dzięki.
PS: Chyba muszę przysiąść i coś pokodować bo widzę że z głowy to śmiechowe rzeczy wypisuje.
Chyba że mamy długo trwające przerwanie i nastąpi takie samo przerwanie w czasie trwania tegoż przerwania, na przykład VERTB. To wtedy faktycznie może się tak zdarzyć.
Jakbym pisał jakieś kalumnie to mnie zwyczajnie poprawcie. Dzięki.
PS: Chyba muszę przysiąść i coś pokodować bo widzę że z głowy to śmiechowe rzeczy wypisuje.
20.11.2023 09:48
[#6]
Re: Przerwania - poziom 3
@asman, post #4
@zilog, @teh_KaiN, @asman
Nie używam AddIntServer, robię obsługę bez systemu. Do INTENA wpisuję $C070 czyli pozwalam na wszystkie 3 źródła z poziomu 3.
Dzięki za wszystkie wyjaśnienia i link z opisem na English Amiga Boardzie.
@asman Ja to rozumiem, że jak wskoczy do mojej procedury z bitem od Blittera i ja to potwierdzę (move.w #$40,INTREQ) i jesli w tym czasie pojawilo sie zgloszenie od Vertb to natychmiast po wyjsciu z procedury przerwania (gdzie obsłużyłem blitter) nastąpi do niej ponowne wskoczenie z zapalonym bitem od Vertb. I w zasadzie procedura od Kalms, która jest w linku który podałeś, by to potwierdzała.
Natomiast pierwszy raz się spotykam z "move.w #$2000,sr".
Ja obsługuję przerwanie tak jak pisze teh_Kain i jak jest w zasadzie u Kalmsa, sprawdzam po kolei bity, potwierdzam wykonanie w INTREQ odpowiednim bitem i wykonuję jakiś tam mój kod.
Tyle że:
1. zastanawiałem się czy od razu po obsłużeniu np. Vertb wychodzic czy sprawdzac kolejne możliwosci (blitter, copper), Kalms pokazuje że nie, że jak obsłużylismy jedno źródło to wychodzimy. Dodam tu, że jeszcze nie wszystko ze szczegółów jego opisu rozumiem.
2. Zastanawiałem się też czy ma znaczenie w którym momencie w procedurze obsługi potwierdzać wykonanie poprzez zapis do INTREQ i wydaje mi się, że jeśli chodzi o VERTB i Coppera to chyba nie ma znaczenia to znaczy czy wywołam:
#$20,INTREQ
bsr mój_kod_który_coś_tam_robi
rte
czy też
bsr mój_kod_który_coś_tam_robi
#$20,INTREQ
rte
Ja rozumiem, że działa to tak, że procesor jest zajęty wykonywaniem tego kodu obsługi przerwania i nie wskoczy w tym czasie do tej procki póki nie wyjdzie z obecnej obsługi :D
Ale w przypadku Blittera ma to znaczenie, gdy bit BLTPRI jest 1 (pełny priorytet blitera) to muszę wykonać potwierdzić wykonanie przerwania (#$40,INTREQ) przed startem Blittera - inaczej program nie działa. Wydaje mi się to logiczne, ale może możecie coś dodać tutaj ?
Ostatnia aktualizacja: 20.11.2023 09:49:44 przez zbrożo
Ostatnia aktualizacja: 20.11.2023 09:50:55 przez zbrożo
Nie używam AddIntServer, robię obsługę bez systemu. Do INTENA wpisuję $C070 czyli pozwalam na wszystkie 3 źródła z poziomu 3.
Dzięki za wszystkie wyjaśnienia i link z opisem na English Amiga Boardzie.
@asman Ja to rozumiem, że jak wskoczy do mojej procedury z bitem od Blittera i ja to potwierdzę (move.w #$40,INTREQ) i jesli w tym czasie pojawilo sie zgloszenie od Vertb to natychmiast po wyjsciu z procedury przerwania (gdzie obsłużyłem blitter) nastąpi do niej ponowne wskoczenie z zapalonym bitem od Vertb. I w zasadzie procedura od Kalms, która jest w linku który podałeś, by to potwierdzała.
Natomiast pierwszy raz się spotykam z "move.w #$2000,sr".
Ja obsługuję przerwanie tak jak pisze teh_Kain i jak jest w zasadzie u Kalmsa, sprawdzam po kolei bity, potwierdzam wykonanie w INTREQ odpowiednim bitem i wykonuję jakiś tam mój kod.
Tyle że:
1. zastanawiałem się czy od razu po obsłużeniu np. Vertb wychodzic czy sprawdzac kolejne możliwosci (blitter, copper), Kalms pokazuje że nie, że jak obsłużylismy jedno źródło to wychodzimy. Dodam tu, że jeszcze nie wszystko ze szczegółów jego opisu rozumiem.
2. Zastanawiałem się też czy ma znaczenie w którym momencie w procedurze obsługi potwierdzać wykonanie poprzez zapis do INTREQ i wydaje mi się, że jeśli chodzi o VERTB i Coppera to chyba nie ma znaczenia to znaczy czy wywołam:
#$20,INTREQ
bsr mój_kod_który_coś_tam_robi
rte
czy też
bsr mój_kod_który_coś_tam_robi
#$20,INTREQ
rte
Ja rozumiem, że działa to tak, że procesor jest zajęty wykonywaniem tego kodu obsługi przerwania i nie wskoczy w tym czasie do tej procki póki nie wyjdzie z obecnej obsługi :D
Ale w przypadku Blittera ma to znaczenie, gdy bit BLTPRI jest 1 (pełny priorytet blitera) to muszę wykonać potwierdzić wykonanie przerwania (#$40,INTREQ) przed startem Blittera - inaczej program nie działa. Wydaje mi się to logiczne, ale może możecie coś dodać tutaj ?
Ostatnia aktualizacja: 20.11.2023 09:49:44 przez zbrożo
Ostatnia aktualizacja: 20.11.2023 09:50:55 przez zbrożo
20.11.2023 10:23
[#7]
Re: Przerwania - poziom 3
@zbrożo, post #6
A propos 1.Według mnie to zależy w jaką maszynę celujesz, na zwykłym 68000 przerwania trochę kosztują, wejście 50 cykli i weź sam rte który zabiera 20 cykli i masz już 70 na dzień dobry. Pewnie na lepszych prockach jest bardziej znośnie. Na pewno taniej będzie sprawdzać po kolei niż za każdym razem włazić do handlera. Tylko pozostaje kwestia wystąpienia tego samego przerwania w przerwaniu - to trzeba sprawdzić czy taka sytuacja może się wydarzyć.
Co do 2. to ten kod
Może się dwa razy wykonać na a4000.
A znowu jesli chodzi o bit BLTPRI czyli 'nasty bit' to według mnie może być tylko używany przy sprawdzeniu czy blitter skończył swoją pracę, czyli
Chyba że nastąpi przerwanie wyższego poziomu, to wtedy zostanie przerwany kod i nastąpi wywołanie kodu handlera wyższego poziomu i po zakończeniu powrót do poprzedniego przerwania.
Ostatnia aktualizacja: 20.11.2023 10:25:51 przez asman
Co do 2. to ten kod
bsr mój_kod #$20,INTREQ rte
Może się dwa razy wykonać na a4000.
A znowu jesli chodzi o bit BLTPRI czyli 'nasty bit' to według mnie może być tylko używany przy sprawdzeniu czy blitter skończył swoją pracę, czyli
ustawiamy BLTPRI
btst #6,$dff002
.wait btst #6,$dff002
bne .wait
kasujemy BLTPRI
Ja rozumiem, że działa to tak, że procesor jest zajęty wykonywaniem tego kodu obsługi przerwania i nie wskoczy w tym czasie do tej procki póki nie wyjdzie z obecnej obsługi :D
Chyba że nastąpi przerwanie wyższego poziomu, to wtedy zostanie przerwany kod i nastąpi wywołanie kodu handlera wyższego poziomu i po zakończeniu powrót do poprzedniego przerwania.
Ostatnia aktualizacja: 20.11.2023 10:25:51 przez asman
20.11.2023 13:35
[#8]
Re: Przerwania - poziom 3
@asman, post #7
@asman
Ogólnie celuję w A500, ale chcę żeby kod działał wszędzie.
Na pewno taniej będzie sprawdzać po kolei niż za każdym razem włazić do handlera.
Ten Kalms na końcu pisze: "...and it should not lose interrupts if multiple interrupt requests (say a COPER and a BLIT) get set in INTREQ(R) at exactly the same moment"
więc ja to rozumiem jak piszesz, że rzeczywiście lepiej w obsłudze sprawdzać i obsługiwać wszystkie 3 możliwości - znaczy nie wychodzić od razu po obsłużeniu np. Vertb tak jak to jest w tym przykładowym kodzie od Kalmsa pod linkiem, tylko sprawdzać blitter i copper.
Może się dwa razy wykonać na a4000.
Wiem, że trzeba na A4000 wykonać dwa razy potwierdzenie "move #$20,INTREQ", o to Ci chodzi?
BLTPRI
Z tego co rozumiem, to jeśli ten bit jest ustawiony to właściwie nie trzeba czekać na blitter, bo po prostu procesor nic nie wykona. Ja skłaniam się póki co ku kolejkowaniu blitów za pomocą przerwania, ale nie potrafię powiedzieć czy ustawienie BLTPRI na 0 jest bardziej wydajne.
Ostatnia aktualizacja: 20.11.2023 13:35:47 przez zbrożo
Ogólnie celuję w A500, ale chcę żeby kod działał wszędzie.
Na pewno taniej będzie sprawdzać po kolei niż za każdym razem włazić do handlera.
Ten Kalms na końcu pisze: "...and it should not lose interrupts if multiple interrupt requests (say a COPER and a BLIT) get set in INTREQ(R) at exactly the same moment"
więc ja to rozumiem jak piszesz, że rzeczywiście lepiej w obsłudze sprawdzać i obsługiwać wszystkie 3 możliwości - znaczy nie wychodzić od razu po obsłużeniu np. Vertb tak jak to jest w tym przykładowym kodzie od Kalmsa pod linkiem, tylko sprawdzać blitter i copper.
Może się dwa razy wykonać na a4000.
Wiem, że trzeba na A4000 wykonać dwa razy potwierdzenie "move #$20,INTREQ", o to Ci chodzi?
BLTPRI
Z tego co rozumiem, to jeśli ten bit jest ustawiony to właściwie nie trzeba czekać na blitter, bo po prostu procesor nic nie wykona. Ja skłaniam się póki co ku kolejkowaniu blitów za pomocą przerwania, ale nie potrafię powiedzieć czy ustawienie BLTPRI na 0 jest bardziej wydajne.
Ostatnia aktualizacja: 20.11.2023 13:35:47 przez zbrożo
20.11.2023 14:45
[#9]
Re: Przerwania - poziom 3
@zbrożo, post #8
Wiem, że trzeba na A4000 wykonać dwa razy potwierdzenie "move #$20,INTREQ", o to Ci chodzi?
Tak o to.
Z tego co rozumiem, to jeśli ten bit jest ustawiony to właściwie nie trzeba czekać na blitter, bo po prostu procesor nic nie wykona
Ja nie jestem ekspertem ale trzeba wziąć pod uwagę inne procki i inną pamięć (FAST), też może to zależeć od operacji na bliterze jaką wykonujemy.
Zamiast kolejkowania blitów, możesz posłużyć się copperem o ile on się nudzi, Będzie szybciej niż przerwania - tak myślę.
20.11.2023 15:38
[#10]
Re: Przerwania - poziom 3
@zbrożo, post #6
zastanawiałem się czy od razu po obsłużeniu np. Vertb wychodzic czy sprawdzac kolejne możliwosci
Ja sprawdzam wszystko i na koniec czyszczę wszystkie obsłużone bity jedną operacją, działa bez problemu. Moje podejście może się wysypać jak będziesz np robił kolejne blity na przerwaniu blittera - przy małych blitach następny może się skończyć zanim wyczyścisz bity na końcu handlera i przegapisz że ten nowy się skończył. Ja takiego scenariusza nie mam więc akceptuję tę wadę.
20.11.2023 18:19
[#13]
Re: Przerwania - poziom 3
@asman, post #12
Słusznie, ale to co miałem na myśli, to rysowanie kafelków i obiektów o rozmiarze 16x16. Tutaj Blitter się nada dosyć dobrze wykonywany w programie głównym.
Procesor pomoże przy rysowaniu mniejszych obiektów, składających się z kilku lub kilkunastu pikseli, np. 16x2.
Przerwanie Blittera za to jest efektywniejsze w przypadku większych operacji rysujących.
Ostatnia aktualizacja: 20.11.2023 18:27:19 przez Hexmage960
Procesor pomoże przy rysowaniu mniejszych obiektów, składających się z kilku lub kilkunastu pikseli, np. 16x2.
Przerwanie Blittera za to jest efektywniejsze w przypadku większych operacji rysujących.
Ostatnia aktualizacja: 20.11.2023 18:27:19 przez Hexmage960
20.11.2023 18:59
[#15]
Re: Przerwania - poziom 3
@zbrożo, post #14
Tak. Bo te operacje trzeba robić po dwa razy dla kompatybilności z 060 żeby na pewno zadziałały, więc zamiast 6 wpisów mam 2.
Jak umiesz czytać C to tu możesz zerknąć https://github.com/AmigaPorts/ACE/blob/master/src/ace/managers/system.c#L162
Ostatnia aktualizacja: 20.11.2023 19:02:18 przez teh_KaiN
Jak umiesz czytać C to tu możesz zerknąć https://github.com/AmigaPorts/ACE/blob/master/src/ace/managers/system.c#L162
Ostatnia aktualizacja: 20.11.2023 19:02:18 przez teh_KaiN