Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
Atari STE. Mam procedurę, która wykonuje się w VBL-u. Jak zmierzyć czas jej wykonania w liniach, etc? Jakiś licznik trzeba zrobić na Timer, czy jest jakieś prostsze rozwiązanie?
Nie możesz zrobić na chama, czyli zmierzyć ile razy ci się wykona w ramce? I podzielić przez liczbę linii?
najprościej w emulatorze typu Steem Debugger albo Hatari.
Na timerach można różnymi metodami, np. można zablokować wszystkie przerwania "move #$2700,SR" a potem odczytywać licznik Timer C. Jego wartość jest zmniejszana o jeden 200 razy na sekundę
200 razy na sekundę to za rzadko, raptem 1/4 ramki
200 razy na sekundę występuje przerwanie gdy "Timer C Data" osiągnie wartość 0. Rejestr "Timer C Data" zmniejszany jest 38 400 na sekundę, a inicjowany jest wartością 192.
Z tym że, we wspomnianym przeze mnie wariancie przerwania nas nie interesują (bo są zablokowane) ale zmiana stanu "Timer C Data". Jeśli 38 400 na sekundę to za mało to można przeprogramować MFP.
Zegar MFP to 2 457 600. Rejestr "Timer A/B/C/D Control" (dzielnik do wybrania to: 4 / 10 / 16 / 50 / 64 / 100 / 200) decyduje z jaką prędkością zmniejszany jest (o wartość "1") rejestr Timer A/B/C/D Data.
Domyślnie Timer C ma "Timer Control" ustawiony na podzielnik 64 , czyli "Timer C Data" zmniejszany jest z prędkością 38 400 na sekundę. "Timer C Data" ma domyślną wartość 192, czyli 38 400 / 192 równa się właśnie 200 razy na sekundę.
Przykładowo, dla "Timer A/B/C/D Control" ustawionego na podzielnik 4, rejestr "Timer A/B/C/D Data" zmieniany jest 614 400 razy na sekundę.
Jak mierzymy?
var Poczatek = "Timer A/B/C/D Data"
--- tu coś robimy
var Koniec = "Timer A/B/C/D Data"
var Czas = Koniec - Poczatek
Jeszcze jedna uwaga, rejestr "Timer A/B/C/D Data" jest 8 bitowy, więc przy obliczeniach trzeba wziąć pod uwagę że się 'przekręci'.
Udało się, ustawiłem przerwanie Timer-a A. na circa. 1000hz. Cel jest tego taki, że usiłuję napisać procedurę odgrywającą sample na DMA doczytywane z HDD. Może źle się do tego zabieram - postanowiłem zrobić to na VBL odczytując na jednym VBL-u bufor wielkości 501 bajtów (tyle wychodzi przy podziale 25033 Hz/50 Hz). Chciałem zmierzyć ile zajmuje procedura odczytu danych do bufora, z wizualizacji kolorów wynika, że jest to od 10-50% CPU, z czego te 50% to są piki. Z pomiarów czasu timerem A wynika, że procedura wykonuje się od 8 do 37 obiegów timera, czyli ok 8-37 milisekund. Jednak procedura testu prędkości była wykonywana poza VBL. Są tutaj sporo różnice pomiędzy dwoma metodami pomiaru. Zresztą odgrywanie na VBL i tak źle działa, czasem burczy, jakby jednak odczyt "nie mieścił się w ramce" albo są jakieś zakłócenia VBLa. Może trzeba wyłączyć wszystkie przerwania IRQ, albo w ogóle nie tędy droga?
Burczenie może wynikać z tego że CPU i SDMA mają osobne kwarce, więc za każdym VBLem trzeba doczytać inną ilość sampli, a ty stosujesz stały bufor, więc mogą robić się 'dziury'.
Zresztą te 50Hz jest umowne i zależy od zegara CPU (Do STE były wkładane chyba ze dwa różne). W ST w trybie "50Hz" VBL = CPU clock / 313 / 512. w trybie "60Hz" VBL = CPU clock / 262 / 508. Dla TT będzie też inaczej, tylko jeden tryb, coś koło 59Hz, nie pamiętam teraz dokładnych cyklów.
Dodatkowo, SDMA ma 8bajtowy bufor FIFO, no i przerwanie czy liczniki pokazują stan załadowania danych do bufora a nie stan aktualnie odtwarzanych danych. Na Atari-forum ktoś kiedyś podawał jak obliczyć wielkość bufora na ramkę, poszukam.
Tak się zastanawiam czemu robisz to na VBL, kod tego wymaga?
Podejrzewam że lepszym rozwiązaniem byłoby coś w stylu ringbuffera o długości większej niż 1VBL - grasz z niego sample, a procedura odczytująca odczytuje od razu jak się 'zwolni' miejsce, najlepiej w porcjach o wielokrotności 512b.
A na czym mam robic? Na innym przerwaniu? Główna pętla ma być na efekty
1) na VBL - to co Adam napisał brzmi dobrze, na VBLu dane ładowane sektorami (bo szybciej) ale wielkość bufora raczej większa, na 2 VBLe (np 2x512 bajtów), tak by podczas jednego VBLa ładować bufor który się właśnie nie odtwarza.
2) na przerwaniu kończącym pętlę odtwarzania - Timerze A albo Mono. Tutaj zrobiłem tak że miałem dwa bufory (odtwarzany i oczekujący na odtwarzanie), na przerwaniu zmieniałem bufor do odtwarzania i ładowałem dane do bufora który czeka w kolejce. Z tym że procedura ładowanie danych GEMDOS była wstrzykiwana po przerwaniu bo musiała być wykonywana w trybie USER a nie SUPERVISOR.
Burczenie może wynikać z tego że CPU i SDMA mają osobne kwarce,
doczytałem, kwarc jest wspólny dla CPU i SDMA.
Przykładowy zegar STE: 32 084 988 / 4 = 8 021 247
Częstotliwość odtwarzania:
8 021 247 / 160 = 50 132,79375
VBL PAL:
8 021 247 / 313 / 512 = 50,05270941
Ilość sampli (50066 mono) na VBL PAL
50 132,79375 / 50,05270941 = 1001,6
---edycja---
w sieci znalazłem info że zegar STE dla PAL to 8 021 247 (kwarc 32 084 988) a dla NTSC 8 010 600 (kwarc 32 042 400)
Ostatnio edytowany przez Cyprian (2022-10-19 19:28:58)
Z tym że procedura ładowanie danych GEMDOS była wstrzykiwana po przerwaniu bo musiała być wykonywana w trybie USER a nie SUPERVISOR.
A po co w USER? Ja mam zawsze caly kod w SUPERVISOR, zarpwno główny, jak i przwrwanie
chodziło mi o to by GEMDOS nie był wykonywany w trakcie przerwania, tylko po zakończeniu przerwania, czyli po instrukcji RTE.
Nigdy tego nie sprawdzałem ale ponoć nie działa albo nie jest zalecane.
Wywoływanie jakichkolwiek funkcji GEMDOS, BIOS i XBIOS z przerwań nie jest wspierane.
Jeśli główny program wywoła w tym czasie jeden z w/w podsystemów to system się wywali.
Ja streamowanie z dysku rozwiązałem w ten sposób, że na timerze C mam podpięte przełączanie "tasków". Każdy task ma wrażenie, że jest ciągle wykonywany. Ale tylko jeden task może kożystać z systemu operacyjnego. Nazywam go głównym. Z reguły mam dwa, i ten drugi renderuje efekty. Mogę ustawić dowolny przydział czasu procesora dla każdego tasku na zasadzie "ile odpaleń timera C" wykonywać dany task. Główny task może też oddać swój przydział czasu jeśli akurat nic nie ma do wczytania z dysku.
Taki prymitywny RTOS.
@sqward fajne podejście z taskami.
u mnie właśnie przerwanie końca odtwarzania sampla ('Przerwanie_MONO') przełącza task na drugi który ładuje GEMDOSem nowe dane sampli, który to potem wraca do głównego procesu.
Przerwanie_MONO:
move.w #$2700,SR
bclr.b #MFP_MONO,MFP_ISRA.w
; zamiana buforow
move.l Bufor,D0
move.l Bufor+4,Bufor
move.l D0,Bufor+4
move.l Bufor_Koniec,D0
move.l Bufor_Koniec+4,Bufor_Koniec
move.l D0,Bufor_Koniec+4
; nowy adres dzwięku
move.b Bufor_Koniec+3,SDMA_END+4
move.b Bufor_Koniec+2,SDMA_END+2
move.b Bufor_Koniec+1,SDMA_END
move.b Bufor+3,SDMA_START+4
move.b Bufor+2,SDMA_START+2
move.b Bufor+1,SDMA_START
move.w 0(SP),TMP_SR
move.l 2(SP),TMP_ADDR
move.w #$2300,0(SP)
move.l #TMP_Proc,2(SP)
rte
TMP_Proc:
; czytaj plik
move.l Bufor+4(PC),A0
move.l #Bufor_wielkosc,D0
bsr GEMDOS_Fread
cmp.l #Bufor_wielkosc,D0
bpl TMP_Koniec
ST Flaga_SDMA
TMP_Koniec:
TMP_SR EQU *+2
move.w #$2300,SR
TMP_ADDR EQU *+2
jmp *Ostatnio edytowany przez Cyprian (2022-10-19 22:55:42)
No tak, ale nie masz kontroli nad tym ile to się będzie wykonywać. Bo funkcja Fread może zając dużo czasu... No i kolejny problem to to, że nie wiesz czy podczas wywołania Fread akurat nie sprawdzasz czy user nie wcisnął jakiegoś klawisza.
no tak, w tamtym czasie nie potrzebowałem tego. mógłbym dodać skanowanie klawiszy i timeout na VBLu.
Swoją drogą Timer C jest używany przez TOS 2.x i nowsze oraz przez sterownik dysków. Jak to godzisz z Twoją procedurą?
jmp ([oldTimerHandler]) zamiast rte.
Ok
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 2.000 sekund, wykonano 11 zapytań ]