Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
Przezroczysta obudowa dla Atari 800XL Rusza przedsprzedaż wyjątkowej, przezroczystej obudowy do komputera Atari 800XL!
RECOIL 6.4.5 RECOIL to przeglądarka retro plików graficznych, obsługująca ponad 550 formatów, dostępna na różnych systemach operacyjnych, z regularnymi aktualizacjami.
ABBUC Software 2024 - wyniki Ukazały się wyniki tegorocznego ABBUC Software Competition
Przeszłość spotyka przyszłość Czwarta edycja festiwalu gier konsolowych i komputerowych z lat 80. i 90.
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
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ć.
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)
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.
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:
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 :)
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.
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)
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)
Adam, jaką interakcję i jakie problemy :)
Blokowanie szyny podczas pracy (nawet w trybie HOG), nie do wyeliminowania trzaski a dźwięku DMA itp.
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?
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)
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:
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ę?
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 cyclesBlitter 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 cyclesBlitter potrzebuje 1024 cykle
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.
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)
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:
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.
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.
Adam: pierwsze słysze o tym poroblemie, masz jakieś źródł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 :)
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.
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 :)
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)
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.
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 cyclesBlitter 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 cyclesBlitter potrzebuje 1024 cykle
Ano to faktycznie różnica jest duża, muszę kiedy zebrać w sobie moc i się blitterem w końcu pobawić.
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 :)
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)
I przypominam, że mod do StarDusta jest modem z Amigi, więc na siłę dostosowanym do STE.
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ść ;)
I przypominam, że mod do StarDusta jest modem z Amigi, więc na siłę dostosowanym do STE.
Nie ma modów 'dostosowanych' do STE.
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)
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, 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
Aha, thx za info.
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;)
A nie można by ich miksować blitterem? Nie ma trybu ADD z przesunięciem? (nie znam się to się wypowiem)
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.102 sekund, wykonano 13 zapytań ]