Można zamienić tablicę masek/offsetów na tablicę masek/offsetów lewą i tablicę masek/offsetów prawą. Wtedy zamiast dwóch lsl.w #3,d0 i lsl.w #3,d1 będą podwójne dodawania add.w d0,d0; add.w d0,d0 i add.w d1,d1; add.w d1,d1. To da oszczędności 12 cykli na linię wypełniającą. Jak będę miał chwilę czasu, zrobię odpowiednie zmiany.

Wszystko OK, tylko że leniuchy powinny sobie ten bit wyczyścić, a nie ustawić... :P

Dzięki za kod. :) Zdążyłem już zrobić małe rozpoznanie i pod rejestr 1d należy wpisać wartość #$40, bo ustawiamy tylko 6 bit (div mode 50), a resztę zerujemy.

Dzięki za kod. :) Wychodzę z założenie, że im mniej, tym lepiej i na początku programu wyłączam sobie wszystko, co się tylko da. Później w razie konieczności włączam sobie kolejne klocki i timer C będzie mam nadzieję jednym z nich. :)

Hmmm... Coś podobnego udało mi się zrobić (i nie wiedzieć czemu nie gra ;)). Widzę, że ustawiasz swoją prockę pod timer C i zostawiasz domyślne systemowe ustawienia zegarów (200Hz). Chętnie podrążyłbym temat i zobaczył całą inicjalizację timera, masz coś takiego?

Noo zawsze sobie pamięć na początku alokuje. :) Ale za to nie rozpakowałem pliku, więc chyba tutaj leży mój f**k up. :D Chętnie spojrzę na kod odgrywający muzę na timerze C, bo cosik nie możemy się ostatnio dogadać. :P

Dzięki za linka. :) Kurcze, u mnie z video counterem, to nawet base'a nie muszę ustawiać - zresztą pisał to też Cyprian. Muszę w takim razie jeszcze raz spojrzeć na coutera, bo może niepotrzebnie spinałem się z timerem - chociaż i tak go wykorzystuje, żeby sobie kilka palet kolorów na ekranie wyświetlać. :D Z tego, co się orientuję, to countera używa się do split screenów, tam trzeba wyświetlany adres zmieniać natychmiast. I ta świadomość natychmiastowości podmiany nie do końca mi przy podwójnym buforze pasuje ;) co nie oznacza, że jest błędna.

OK. Widzę, że temat się rozwinął :D Po dwóch dniach rozgryzłem to już dosyć mocno, więc podzielę się obserwacjami :) Po pierwsze: ustawienie video base'a ma miejsce przy następnym VBL, video counter wprowadza zmiany natychmiast. Przy podwójnym buforze (jeśli się go wykorzystuję - ja tak robię), w grę wchodzi tylko Video Base. I teraz: zmiana $ff8265 z wartości niezerowej na zerową powoduje mignięcia, ponieważ zmiany wprowadzane są NATYCHMIAST, a nie przy kolejnym VBL. Więc jeśli zmieniacie to w vbl, będziecie mieć mignięcie, chyba że korzystacie z rejestrów video countera - ale to rozwali wam podwójny bufor. Rozwiązaniem jest zmiana tego rejestru PO wyświetleniu ekranu. Można do tego zastosować albo HBL i zliczyć sobie, kiedy skończy się wyświetlanie ekranu, albo zastosować timer b i też poczekać na koniec wyświetlania. Ja wybrałem timer, rejestr zmieniam w odpowiednim momencie i nie mam migotania :) Spróbujcie zrobić hscrolla na video base i z pixel shiftem, to zobaczycie, o co mi chodzi. :)

Nie do końca orientuję się, jak działa eor fill, ale pamiątaj, że obrys trójkąta trzeba wyrysować, trzeba pobrać poprzednią linię (to w blitterze zajmuje 8 taktów na 16 pikseli, a nie cztery jak przy wypełnianiu) i zeorować ją z aktualną, to z kolei zajmie albo 8 albo 12 taktów na 16 pikseli. Jak sobie podliczymy, to wcale już to tak dobrze nie wygląda. Chyba, że eor fill działa nie tak, jak napisałem? :(

Można pomyśleć o tablicy divsów, to by jeszcze trochę przyspieszyło kod. Jeśli chodzi o wstawianie instrukcji w czasie działania blittera, to chyba zadziała to tylko w przypadku trybu BLIT, czyli trybu dzielonego (ale mogę się mylić). No ciekawe, jak wypadłby blitter w 4 planowym fillerze, ale zaczynam odnosić wrażenie, że mógłby być wolniejszy od motorli (jak sobie spojrzycie na 4 bitplanowego fillera z kilku tematów wstecz, to do wypełniania używam tam movemów i przy długich liniach robię bodajże 64 piksele na jednym movie - to może być już dla blittera za dużo).