26

Odp: Blitter - gry,programy

Jeśli już jesteśmy przy strukturze bitplanów - to akurat myślę, że te w ST są lepiej pomyślane niż te w Amidze (uwzględniają specyfikę procesora). Chodzi głównie o to, że na ST logicznie można ich ilość zredukować o połowę poprzez operacje na 32 zamiast na 16 bitach (co procesor potrafi). Masz np.: move.l (a0),d0 ; or.l (a1)+,d0 ; move.l do,(a0)+ - i to ogarnia już 2 bitplany (czyli 4 kolory). W amidze dla 4ch kolorów musisz to 2 razy zrobić.

27

Odp: Blitter - gry,programy

Tak, ale z drugiej strony jeśli chcesz rysować na jednym bitplanie to na ST robisz to word'ami i musisz robić skoki. Na Amidze możesz liniowo jechać longword'ami rysując 32px na raz (a nie 16px na ST). Coś za coś.

A główym powodem dlaczego jestem fanem wersji Amigowej jest to, że na ST/STE nie zrobisz przez to sensownie paralaksy. Nawet jeśli masz hardware scrolling to trzeba ruszać na STE wszystkimi planami na raz. Na amidze możesz scrollować je niezależnie - to jest używane w grach czy demach. Na ST/STE trzeba się ratować wtedy już programowym scrollowaniem i jest słabo:/

Aha, punkt dla ST za to, że dzięki takiej strukturze robisz konwersje C2P używając movep'a i chyba(?) jest to szybsze niż to co robią Amigowcy.

Kolejny argument jest taki, że dodanie do ST 5'tego bitplanu aby mieć 32 kolory przy takiej konstrukcji shifter'a byłoby cieżkie... i niewygodne potem do obsługi przez koderów. Taka struktura przywiązuje Cię to liczby planów która jest potęgą 2. W Amidze dodanie kolejnego bitplanu gdzieś indziej w pamięci nie byłoby taką rewolucją. Oczywiście to już hipotetyczne dywagacje na temat tego co i tak się nie stało;)

Ostatnio edytowany przez mkm (2014-06-21 12:46:20)

Maciek
--------
Atari 65XE + Ultimate 1MB + Stereo + SIO2SD | Atari 520STE + 4MB + UltraSatan | Atari Falcon 030 + CT60e + 14MB ST + 256MB TT + 68882  + CF + Netusbee | Amiga 500 + 1MB + Gotek | Amiga 600 + 2MB Chip + 8MB Fast + CF

28

Odp: Blitter - gry,programy

maciekm napisał/a:

Co więcej moim zdaniem struktura bitplanów w pamięci ST (tzn ich przeplatanie się) też to czasami komplikuję w porównaniu z Amigą. (edit: dobra dramatyzuję to ostatnie przeszkadza w wielu innych rzeczach, ale z blitter'em tragedii przez to nie ma)

hmm, Amiga również używa bitplanów tylko inaczej rozłożonych. Myślę że dyskusyjną sprawą jest to który wariant jest lepszy, pewnie w niektórych rozwiązaniach Amigowy sprawdza się lepiej a w innych Atari przoduje.
Z tego co wiem to na Atari konwersja C2P jest szybsza dzięki właśnie przeplotowi bitplanów. Poniżej mój przykład - kod który tworzy 16 pixelową linię (zapala 16bitów w czterech bitplanach)
Atari:

    lea        addr_ekranu,A0
    moveq    #-1,D0
    move.l    D0,(A0)+
    move.l    D0,(A0)+

Amiga:

    lea        addr_ekranu,A0
    lea        8000(A0),A1
    lea        8000(A1),A2
    lea        8000(A2),A3
    moveq    #-1,D0
    move.w    D0,(A0)
    move.w    D0,(A1)
    move.w    D0,(A2)
    move.w    D0,(A3)

myślę że ilość potrzebnego kodu mówi samo za siebie.

Adam Klobukowski napisał/a:

Wykorzystanie blittera jest w wielu wypadkach na tyle klopotliwe, że niestety w większości wypadków nie ma tak różowo.

no nie wiem, blitter w Atari ma niewiele rejestrów i jest banalny w obsłudze.

taka ciekawostka, Ray//.tscc zaprzągł blitter do cieniowania wielokątów Gouraudem:
http://s390174849.online.de/ray.tscc.de/images/gouraud.gif

erOS napisał/a:

i dlatego nasza kochana firma chciała nam i producentom softu ułatwić życie i postanowiła nie montować tego układu? a jak już się zdecydowała to ci sami producenci postanowili nie psuć tej różowości? :) Czy też może nasz niedostatek produkcji wynikał z dużej popularności modelu bez tegoż układu czy też może programowanie blittera na ST a na Ami różni się tak dramatycznie? :>

dobre pytanie, ja sam chciał bym zapytać czemu STE weszło tak późno do produkcji, czemu linia STfm była produkowana do 1994 roku. itp. Nieznane są drogi Atari :)
Na grupie net.micro.atari16 (pierwowzór comp.sys.atari) można wyczytać że już w 1986 roku można było dokupić blitter do 520ST za skromne $120 :)

maciekm napisał/a:

Na amidze możesz scrollować je niezależnie - to jest używane w grach czy demach. Na ST/STE trzeba się ratować wtedy już programowym scrollowaniem i jest słabo:/

no tak, osobne sterowanie bitplanami w Amidze jest fajnym ficzerem.
Czemu tego nie było w Atari? Myślę że warto pamiętać że ST nie było projektowane jako konkurent Amigi tylko Mackintosha. Tak więc nacisk położono na komfort pracy w aplikacjach (stąd wysoka rozdzielczość STHIGH i twardy dysk) a nie na gry.


maciekm napisał/a:

Kolejny argument jest taki, że dodanie do ST 5'tego bitplanu aby mieć 32 kolory przy takiej konstrukcji shifter'a byłoby cieżkie... i niewygodne potem do obsługi przez koderów.

może dla tego w Atari skoczyło z 16stu od razu do 256 i 65536 kolorów

Ostatnio edytowany przez Cyprian (2014-06-21 21:27:12)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

Odp: Blitter - gry,programy

Cyprian napisał/a:
Adam Klobukowski napisał/a:

Wykorzystanie blittera jest w wielu wypadkach na tyle klopotliwe, że niestety w większości wypadków nie ma tak różowo.

no nie wiem, blitter w Atari ma niewiele rejestrów i jest banalny w obsłudze.

Nie chodzi o jego programowanie, które jest w miarę proste, ale o interakcję z resztą STE która sprawia problemy.

Ostatnio edytowany przez Adam Klobukowski (2014-06-22 09:34:33)

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

30

Odp: Blitter - gry,programy

Adam, jaką interakcję i jakie problemy  :)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

Odp: Blitter - gry,programy

Blokowanie szyny podczas pracy (nawet w trybie HOG), nie do wyeliminowania trzaski a dźwięku DMA itp.

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

32

Odp: Blitter - gry,programy

Cyprian napisał/a:

Jeśli chodzi o sam Blitter to w ST w każdej operacji jest on wielokrotnie szybszy od 68000. W Falconie i Amidze1200 jest inaczej, 68030/20 jest szybsze od blittera.

Blitterem się nigdy nie bawiłem, więc pytam z czystej ciekawości. Co oznacza "w każdej operacji jest on wielokrotnie szybszy od 68000" i szczególnie ile jest to "wielokrotnie"? (3, 5, 8 razy? )
Znaczy się, że np jeśli chciałbym skopiować zwykłą bitmapę 32x64 pikseli procesorem i blitterem, to blitter zrobiłby nieporównywalnie ( bo "wielokrotnie" tak rozumiem ) szybciej?

33

Odp: Blitter - gry,programy

jury, nie robiłem dokładnych pomiarów, więc jeśli takie dane ma Adam czy Cyprian to chętnie się też dowiem.
to co mogę powiedzieć z mojej strony, to że to bardzo zależy od konkretnego case'u który kodujesz.

1)  czyścisz ekran na wszystkich 4 bitplanach. jestem w stanie napisać do tego szybki kod CPU:  movem na wzystkich rejestrach z ujemnym indeksowaniem oraz z unrollowanym loop'em. To jest już dość szybkie. Blitter będzie szybszy, ale różnica biorąc pod wzgląd, że kodujesz cały efekt a to tylko jakiś element nie będzie znacząca.
2)  czyścisz ekran na np 2 bitplanach a 2 pozostawiasz takie jak były. to jest już cieżko napisać bardzo szybki kod CPU bo musisz omijać kawałki pamięci itp. i tutaj różnica na plus blitter'a będzie spora.

moja osobista opinia ogólna jest taka, że blitter od strony technicznej używa się łatwo i przyjemnie (oprócz paru problemów które napisał Adam), ale cieżko jest znaleźć dla niego zastosowanie praktyczne w efektach. tzn napisać efekt tak by byl z założenia oparty na blitterze i był jako całość 2 razy szybszy niż na CPU. nie mówię, że się nie da (patrz cieniowanie o którym pisał Cyprian), ale jest to trudne. dlatego częściej jest używany imho tylko pomocniczo... (gdzie w Amidze koder dostawał od razu szybkie rysowanie linii, wypełnianie polygonów itp)

czyli nie mowię tutaj o matematycznej różnicy szybkości operacji... a raczej o praktycznych obserwacjach, które ja mam.

Ostatnio edytowany przez mkm (2014-06-23 09:45:27)

Maciek
--------
Atari 65XE + Ultimate 1MB + Stereo + SIO2SD | Atari 520STE + 4MB + UltraSatan | Atari Falcon 030 + CT60e + 14MB ST + 256MB TT + 68882  + CF + Netusbee | Amiga 500 + 1MB + Gotek | Amiga 600 + 2MB Chip + 8MB Fast + CF

34

Odp: Blitter - gry,programy

Adam Klobukowski napisał/a:

Blokowanie szyny podczas pracy (nawet w trybie HOG),

a który blitter tak nie robi? Pamięć RAM ma to do siebie że na raz korzystać z niej może tylko jedno urządzenie. Więc 68000 w zależności od sytuacji blokowany jest przez MMU/Shiftera, ACSI, FDC no i blittera.
Ale chyba wiem co chciałeś powiedzieć - w trybie HOG blitter przejmuje szynę danych na cały proces blittowania. W trybie Blit-mode dzieli się szyną z procesorem w czasie pracy.
Zgaduję że problemem w/g ciebie jest współdzielenie szyny 64/64 (64 cykle dla blittera i 64 dla procesora) w Blit-mode.
No nie wiem, dla mnie to jest ok. Oczywiście pewnie Atari mogło lepiej rozwiązać współdzielenie szyny w Blit-mode ale dla "chcącego nic trudnego". Jakieś 7 lat temu na Atari-Forum dodałem skromy wpis, w jaki sposób używać CPU i blitter równocześnie.

Tutaj np. masz screen z 3D Full Leonarda/Oxygene. Jest to overscan połączony z obiektem 3d wypełnianym blitterem:
http://www.pouet.net/content/screenshots/29062.gif

Adam Klobukowski napisał/a:

nie do wyeliminowania trzaski a dźwięku DMA itp.

szczerze mówiąc nigdy nie słyszałem o tym problemie. masz może jakiś konkretny przykład? jakieś demo, aplikację?


jury napisał/a:

Znaczy się, że np jeśli chciałbym skopiować zwykłą bitmapę 32x64 pikseli procesorem i blitterem, to blitter zrobiłby nieporównywalnie ( bo "wielokrotnie" tak rozumiem ) szybciej?

ok, chcemy tylko przekopiować sprite 32x64.
Mój kod, licząc samą pętlę zrobi to w 3072 cylki:

    lea        Dane(PC),A0
    lea        Dane+1000(PC),A7
    moveq    #63,D0
Petla3
    move.l    (A0)+,(A7)+        ;20 cycles
    lea        156(A0),A0        ;8 cycles
    lea        156(A7),A7        ;8 cycles
    dbra.w    D0,Petla3        ;12 cycles

Blitter w 1024 cykle

Jeśli jednak chcemy przesuwać sprite po ekranie to trzeba go rolować. Poniższy kod roluje o 3 pikseli w prawo i zajmuje mu to w 4224 cykli

    lea        Dane(PC),A0
    lea        Dane+1000(PC),A7
    moveq    #63,D0
Petla4
    move.l    (A0)+,D1        ;12 cycles
    ror.l    #7,D1            ;24 cycles
    move.l    D1,(A7)+        ;12 cycles
    lea        156(A0),A0        ;8 cycles
    lea        156(A7),A7        ;8 cycles
    dbra.w    D0,Petla4        ;12 cycles

Blitter potrzebuje 1024 cykle



maciekm napisał/a:

1)  czyścisz ekran na wszystkich 4 bitplanach. jestem w stanie napisać do tego szybki kod CPU:  movem na wzystkich rejestrach z ujemnym indeksowaniem oraz z unrollowanym loop'em. To jest już dość szybkie. Blitter będzie szybszy, ale różnica biorąc pod wzgląd, że kodujesz cały efekt a to tylko jakiś element nie będzie znacząca.

blitter czyści lub wypełnia paternem pamięć w tempie jedno słowo na 4 cykle.
Tutaj właśnie widać zaletę blittera vs unrolowany kod. Blitter zrobi to szybciej no i procedura zajmie zaledwie parę bajtów.


maciekm napisał/a:

moja osobista opinia ogólna jest taka, że blitter od strony technicznej używa się łatwo i przyjemnie (oprócz paru problemów które napisał Adam), ale cieżko jest znaleźć dla niego zastosowanie praktyczne w efektach. tzn napisać efekt tak by byl z założenia oparty na blitterze i był jako całość 2 razy szybszy niż na CPU. nie mówię, że się nie da (patrz cieniowanie o którym pisał Cyprian), ale jest to trudne. dlatego częściej jest używany imho tylko pomocniczo... (gdzie w Amidze koder dostawał od razu szybkie rysowanie linii, wypełnianie polygonów itp)

czyli nie mowię tutaj o matematycznej różnicy szybkości operacji... a raczej o praktycznych obserwacjach, które ja mam.

Nie znam się na scenowym programowaniu (chyba się zapiszę na lekcje do Ciebie :) ), nie będę się więc wypowiadał na temat konkretnych efektów.
Wiem tylko że blitter nie jest odpowiednikiem np. CPU czy GPU - nie jest uniwersalny. Został zaprojektowany do ściśle określonych prostych zadań. Najważniejsze żeby mieć pomysł jak go wykorzystać.

Co do czyszczenia pamięci, to nie myślałeś wykorzystać do tego blitter i Makra?
Jedno makro inicjujące blitter na początku programu, drugie uruchamiające operację blittera ?

Ostatnio edytowany przez Cyprian (2014-06-26 17:19:30)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

Odp: Blitter - gry,programy

Cyprian napisał/a:
Adam Klobukowski napisał/a:

Blokowanie szyny podczas pracy (nawet w trybie HOG),

a który blitter tak nie robi? Pamięć RAM ma to do siebie że na raz korzystać z niej może tylko jedno urządzenie. Więc 68000 w zależności od sytuacji blokowany jest przez MMU/Shiftera, ACSI, FDC no i blittera.
Ale chyba wiem co chciałeś powiedzieć - w trybie HOG blitter przejmuje szynę danych na cały proces blittowania. W trybie Blit-mode dzieli się szyną z procesorem w czasie pracy.
Zgaduję że problemem w/g ciebie jest współdzielenie szyny 64/64 (64 cykle dla blittera i 64 dla procesora) w Blit-mode.
No nie wiem, dla mnie to jest ok. Oczywiście pewnie Atari mogło lepiej rozwiązać współdzielenie szyny w Blit-mode ale dla "chcącego nic trudnego". Jakieś 7 lat temu na Atari-Forum dodałem skromy wpis, w jaki sposób używać CPU i blitter równocześnie.


Tutaj np. masz screen z 3D Full Leonarda/Oxygene. Jest to overscan połączony z obiektem 3d wypełnianym blitterem:
http://www.pouet.net/content/screenshots/29062.gif

Oczywiście że się da, ale całkowite blokowanie szyny na 64 cykle jest problematyczne, szczególnie jak masz efekty które wymagają dokładnego cyklowania  każdej linii.

Cyprian napisał/a:
Adam Klobukowski napisał/a:

nie do wyeliminowania trzaski a dźwięku DMA itp.

szczerze mówiąc nigdy nie słyszałem o tym problemie. masz może jakiś konkretny przykład? jakieś demo, aplikację?

Konkretny przyklad to każde demo/aplikacja używająca blittera i dźwięku DMA. Blitter ma najwyższy priorytet, i jeśli DMA będzie potrzebowało próbki w momencie gdy Blitter pracuje, to będzie trzask. Nie są to jakieś wielkie zakłócenia, ale wystarczy się wsłuchać by je usłyszeć. Jak na razie nikomu nie udało się tego wyeliminować, i chyba nie jest to możliwe, bo z tego co się ornientuje to nie da się przewidzieć kiedy dźwięk DMA będzie chciał uzyskać dostęp do pamięci.

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

36

Odp: Blitter - gry,programy

Adam: pierwsze słysze o tym poroblemie, masz jakieś źródła?

What can be asserted without proof can be dismissed without proof.

37

Odp: Blitter - gry,programy

Adam Klobukowski napisał/a:

Oczywiście że się da, ale całkowite blokowanie szyny na 64 cykle jest problematyczne, szczególnie jak masz efekty które wymagają dokładnego cyklowania  każdej linii.

Atari na szczęście zaopatrzyło SDMA w 8 bajtowe FIFO, więc blitter bez zauważalnego efektu może zablokować procesor na max 640 cykli dla 50kHz stereo lub 10240 cykli dla 6kHz mono.
Więc, może to być problematyczne ale jedynie dla nowicjusza :)

Adam Klobukowski napisał/a:

Konkretny przyklad to każde demo/aplikacja używająca blittera i dźwięku DMA. Blitter ma najwyższy priorytet, i jeśli DMA będzie potrzebowało próbki w momencie gdy Blitter pracuje, to będzie trzask. Nie są to jakieś wielkie zakłócenia, ale wystarczy się wsłuchać by je usłyszeć. Jak na razie nikomu nie udało się tego wyeliminować, i chyba nie jest to możliwe, bo z tego co się ornientuje to nie da się przewidzieć kiedy dźwięk DMA będzie chciał uzyskać dostęp do pamięci.

Adam, nie ma technicznej możliwości kolizji dostępu do pamięci pomiędzy blitterem i SDMA ponieważ pracują one na odrębnych szynach danych. SDMA na szynie Shiftera a blitter na szynie CPU. Obie szyny dzięki układowi GLUE korzystają z pamięci naprzemiennie.

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

Odp: Blitter - gry,programy

Cyprian napisał/a:
Adam Klobukowski napisał/a:

Oczywiście że się da, ale całkowite blokowanie szyny na 64 cykle jest problematyczne, szczególnie jak masz efekty które wymagają dokładnego cyklowania  każdej linii.

Atari na szczęście zaopatrzyło SDMA w 8 bajtowe FIFO, więc blitter bez zauważalnego efektu może zablokować procesor na max 640 cykli dla 50kHz stereo lub 10240 cykli dla 6kHz mono.
Więc, może to być problematyczne ale jedynie dla nowicjusza :)

Adam Klobukowski napisał/a:

Konkretny przyklad to każde demo/aplikacja używająca blittera i dźwięku DMA. Blitter ma najwyższy priorytet, i jeśli DMA będzie potrzebowało próbki w momencie gdy Blitter pracuje, to będzie trzask. Nie są to jakieś wielkie zakłócenia, ale wystarczy się wsłuchać by je usłyszeć. Jak na razie nikomu nie udało się tego wyeliminować, i chyba nie jest to możliwe, bo z tego co się ornientuje to nie da się przewidzieć kiedy dźwięk DMA będzie chciał uzyskać dostęp do pamięci.

Adam, nie ma technicznej możliwości kolizji dostępu do pamięci pomiędzy blitterem i SDMA ponieważ pracują one na odrębnych szynach danych. SDMA na szynie Shiftera a blitter na szynie CPU. Obie szyny dzięki układowi GLUE korzystają z pamięci naprzemiennie.

Trochę doczytałem i jestem mądrzejszy (http://dev-docs.atariforge.org/files/ST … 5-1989.pdf). Oczywiście, zwracam honor, nie chodzi o szynę tylko o przerwania. SDMA na końcu odtwarzania sampla (może) generować przerwanie. Typowo jest to używane przy odtwarzaniu dźwięku miksowanego przez CPU sampel po samplu, czyli przykładowo odtwarzanie MODów. Jeśli to przerwanie się opóźni (bo np. trwa operacja blittera), będziesz miał przerwę w dźwięku i możliwe zniekształcenie. Bez wycyklowania wszystkich operacji nie da się tego uniknąć, więc raczej nie jest to po prostu możliwe. Posłuchajcie sobie Braindamage czy Stardusta (w trakcie tunelu) na realnym STE, a potem odtwórzcie sobie te mody na tym samym STE w trakerze który nie używa blittera (ale używa SDMA) - będzie różnica. Mało słyszalna, ale jest :)

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

39

Odp: Blitter - gry,programy

Adam, co do "wycyklowania" czyli synchronizacji - to nie jest jakaś filozofia. Chociażby VSync - albo synchronizujesz operacje graficzne z przerwaniem pionowym i masz stabilny obraz albo masz migające sprajty. To samo tyczy się SoundDMA, Midi, Centronics, RS232, czy transferu danych klawiatury/myszy. Bez synchronizacji komputer był by ślepy i głuchy.
Może się mylę, ale uważam że dobry programista ma to "wycyklowanie"/synchronizację cały czas na uwadze, gdyż przykładowo głupia instrukcja DIVS może opóźnić przerwanie o 156 cykli.

Swoją drogą zakładam że Atari właśnie po to dodało do SoundDMA 8 bajtowy bufor FIFO by w razie opóźnienia w obsłudze przerwań, bez problemu kontynuować odtwarzanie dźwięku z bufora. Tak jak pisałem pierwszy raz słyszę o tym problemie.

Ostatnio edytowany przez Cyprian (2014-06-26 21:32:21)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

Odp: Blitter - gry,programy

No oczywiście, wszystko się da, tylko pytanie ile trzeba w to pracy włożyć. Jak nie napiszesz sam procedury odtwarającej MODa, to nie przewidzisz kiedy wystąpi przerwanie SDMA. Nawet jak napiszesz, może to zależeć od MODa, efektów, itp. W ogólnym przypadku nie widzę możliwości.

Problem nie jest jakiś duży, ale jest.

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

41

Odp: Blitter - gry,programy

Cyprian napisał/a:
jury napisał/a:

Znaczy się, że np jeśli chciałbym skopiować zwykłą bitmapę 32x64 pikseli procesorem i blitterem, to blitter zrobiłby nieporównywalnie ( bo "wielokrotnie" tak rozumiem ) szybciej?

ok, chcemy tylko przekopiować sprite 32x64.
Mój kod, licząc samą pętlę zrobi to w 3072 cylki:

    lea        Dane(PC),A0
    lea        Dane+1000(PC),A7
    moveq    #63,D0
Petla3
    move.l    (A0)+,(A7)+        ;20 cycles
    lea        156(A0),A0        ;8 cycles
    lea        156(A7),A7        ;8 cycles
    dbra.w    D0,Petla3        ;12 cycles

Blitter w 1024 cykle

Jeśli jednak chcemy przesuwać sprite po ekranie to trzeba go rolować. Poniższy kod roluje o 3 pikseli w prawo i zajmuje mu to w 4224 cykli

    lea        Dane(PC),A0
    lea        Dane+1000(PC),A7
    moveq    #63,D0
Petla4
    move.l    (A0)+,D1        ;12 cycles
    ror.l    #7,D1            ;24 cycles
    move.l    D1,(A7)+        ;12 cycles
    lea        156(A0),A0        ;8 cycles
    lea        156(A7),A7        ;8 cycles
    dbra.w    D0,Petla4        ;12 cycles

Blitter potrzebuje 1024 cykle

Ano to faktycznie różnica jest duża, muszę kiedy zebrać w sobie moc i się blitterem w końcu pobawić.

Adam Klobukowski napisał/a:

czy Stardusta (w trakcie tunelu) na realnym STE, a potem odtwórzcie sobie te mody na tym samym STE w trakerze który nie używa blittera (ale używa SDMA) - będzie różnica

Ha, ja za to pierdzenie raczej obwiniałem twórcę tej muzyczki, choć za pierwszym razem jak grałem w tunel, to myślałem, że to wina głośniczków monitora, ale ta hipoteza szybko runęła, jak na każdym odsłucho tak samo pierdziało. A tu proszę, to nie muzak winien, muszę w takim razie posłuchać sobie jej bez tunelu :)

42

Odp: Blitter - gry,programy

Adam Klobukowski napisał/a:

Posłuchajcie sobie Braindamage czy Stardusta (w trakcie tunelu) na realnym STE, a potem odtwórzcie sobie te mody na tym samym STE w trakerze który nie używa blittera (ale używa SDMA) - będzie różnica. Mało słyszalna, ale jest smile

Adam, ja osobiście nie pokusił bym się o tak jednoznaczne stwierdzenie bez dokładnej analizy kodu oraz weryfikacji tego w debuggerze.
Tak więc skąd u ciebie przekonanie że to wina blittera a nie na przykład złego kodu?

Ostatnio edytowany przez Cyprian (2014-06-27 08:48:01)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

43

Odp: Blitter - gry,programy

I przypominam, że mod do StarDusta jest modem z Amigi, więc na siłę dostosowanym do STE.

Sikor umarł...

Odp: Blitter - gry,programy

Cyprian napisał/a:
Adam Klobukowski napisał/a:

Posłuchajcie sobie Braindamage czy Stardusta (w trakcie tunelu) na realnym STE, a potem odtwórzcie sobie te mody na tym samym STE w trakerze który nie używa blittera (ale używa SDMA) - będzie różnica. Mało słyszalna, ale jest smile

Adam, ja osobiście nie pokusił bym się o tak jednoznaczne stwierdzenie bez dokładnej analizy kodu oraz weryfikacji tego w debuggerze.
Tak więc skąd u ciebie przekonanie że to wina blittera a nie na przykład złego kodu?

W (programowym) debuggerze tego nie zweryfikujesz, musiałbys skonstruować sobie sprzętowy. Skąd moje przekonanie? Cóż, wierzę w fińską solidność ;)

Sikor napisał/a:

I przypominam, że mod do StarDusta jest modem z Amigi, więc na siłę dostosowanym do STE.

Nie ma modów 'dostosowanych' do STE.

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

45

Odp: Blitter - gry,programy

używam dwóch programowych debuggerów - Steem Debug i Hatari  :P
pierwszy wygodny - okienkowy, drugi wypasiony, z obsługą plików wsadowych ale niestety konsolowy

Ostatnio edytowany przez Cyprian (2014-06-27 19:08:09)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

46

Odp: Blitter - gry,programy

Adam Klobukowski napisał/a:

Nie ma modów 'dostosowanych' do STE.

Ale o ile dobrze pamiętam Paula nieco odmiennie je interpretuje, lecz mogę się mylić. Poza tym - jest to format natywny dla Amigi, dla innych platform tylko dostosowany, więc tylko przybliżony w lepszy lub gorszy sposób.
Dodatkowo - Paula nie obciąża procka, a DMA niestety tak. Szczątkowo, ale zawsze.

Sikor umarł...

47

Odp: Blitter - gry,programy

Sikor, SDMA tak jak Paula nie obciąża procka - samo odtwarzanie sampli zajmuje 0% mocy procesora.
To procedura odtwarzania MODów jest czasochłonna, zarówno na Atari jak na Amidze. Z tego co pamiętam to na tym drugim zajmuje 6-7 linii ekranowych a na ST Lance player koło 100 linii dla 50Khz i koło 46 dla 12KHz

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

48

Odp: Blitter - gry,programy

Aha, thx za info.

Sikor umarł...

49

Odp: Blitter - gry,programy

Sikor, tu masz wątek na atari-forum o tym ile to zajmuje czasu: http://www.ourtari-forum.com/viewtopic. … fd9966562d
Paula ma taki bajer, że sprzętowo miksuję sample na 4 kanałach i nie musisz tego robić cpu. W STE masz 2 kanały, więc musisz miksować sample programowo i to zajmuje procesor. Tak, jak pisał Cyprian sam replay zmiksowanych sampli już nie boli;)

Maciek
--------
Atari 65XE + Ultimate 1MB + Stereo + SIO2SD | Atari 520STE + 4MB + UltraSatan | Atari Falcon 030 + CT60e + 14MB ST + 256MB TT + 68882  + CF + Netusbee | Amiga 500 + 1MB + Gotek | Amiga 600 + 2MB Chip + 8MB Fast + CF

50

Odp: Blitter - gry,programy

A nie można by ich miksować blitterem? Nie ma trybu ADD z przesunięciem? (nie znam się to się wypowiem)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje