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;)

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

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

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.

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.

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 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, 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, 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.

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

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

I przypominam, że mod do StarDusta jest modem z Amigi, więc na siłę dostosowanym 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

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

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;)