Pytanie o Multicolor

[sect0r]

Dla Was - starej gwardii, pewno nic specjalnego. Ja dopiero raczkuje. Cos tam probowalem robic z ramka, jednak bez skutku, linie wychodza ukosne, do tego grube.
Zeby to zsynchronizowac z ekranem to wogole czarna magia
Ktos moglby mnie naprowadzic, podac jakis algorytm.
Czy na ekranie robimy to przez zmiane bitow odpowiadajacych za PAPER czy INK ?
Czy zeby np zrobic 1px linie danego koloru, musze pozostale linie ramki takze zapelnic ?
Jakas tablica czy jak Jak zsynchronizowac to dodatkowo z tym co sie dzieje na borderze?
https://www.youtube.com/watch?v=zBOPdiGC5EY

Bylbym wdzieczny za kod 1px linijki lecacej w dol przez border i ekran, wtedy moglbym to jakos przeanalizowac, moze jakies wnioski wyciagnac...

[matofesi]

Huhu... Na prawdę? Tylko tyle?

Multicolor i efekty borderowe to jedne z trudniejszych do realizacji efektów na Spectrum (nie licząc zaawansowanej matematyki i przerzucania dużych ilości danych). Nie da się tego opisać w prosty sposób - każdy efekt liczy się i koduje zgodnie z potrzebami tego efektu.

Podstawowa kwestia to znajomość czasów wyświetlania poszczególnych fragmentów ekranu i czasów wykonania poszczególnych rozkazów procesora. Potem jeszcze dobrze jest zrozumieć contention-patterns (czyli opóźnienia narzucane na czasy wykonania rozkazów w wypadku równoczesnego z ULA dostępu do pamięci). A na koniec już tylko liczyć... I jeszcze tylko uwzględnić to, że program uruchamiany na różnych komputerach będzie miał różne przebiegi i multicolor dopasowany do Spectrum 48 nie będzie działał poprawnie na 128

Ogólnie cały trik polega na tym, że musisz tak wyliczyć punkt zmiany ramki/atrybutów ekranu, żeby trafić zanim raster dojdzie do tego punktu po czym odczekać stosowną ilość czasu, żeby przeszedł dalej i zmienić ten sam atrybut jeszcze raz.

Większość czasu efektów borderowych to czekanie w pętlach opóźniających na odpowiedni moment. Multicolor to połączenie czekania z szybką zmianą atrybutów.

Nie wiem jak mocno się czujesz w kodowaniu na tym poziomie, ale sugerował bym na początek może coś prostszego

[sect0r]

Dzięki za przybliżenie tematu Na razie się nie czuję, ale za kilka latek intensywnej nauki kto wie...
Tak przy okazji timingów, to robi się detekcję 48,+2,+2a,pentagon , czy raczej każdy to olewa i jest "jak nie masz takiego sprzetu jak ja to twój problem"

[RafalM]

Tak przy okazji timingów, to robi się detekcję 48,+2,+2a,pentagon , czy raczej każdy to olewa i jest "jak nie masz takiego sprzetu jak ja to twój problem"

Jedni robią, drudzy nie

A temat rzeczywiście jest zaawansowany.
W najprosztszym ujęciu wygląda to tak że robimy instrukcję HALT tak by zacząć od początku rysowania nowej ramki a potem wykonujemy kod o dokładnie wyliczonym czasie trwania. W określonych, dokładnie wyliczonych momentach zmieniamy atrybuty na ekranie albo border. W efekcie kawałek kwadratu 8x8 jest rysowany ze starym atrybutem, a kawałek z nowym.

Chcesz multicolor na borderze to wpisz w Basicu

1 BORDER 1:BORDER 2:BORDER 3
2 GOTO 1

No i jest A to że pasy latają wynika z braku jakiejkolwiek synchronizacji, czyli właśnie tego najtrudniejszego elementu.

[matofesi]

A jak chcesz kawałek synchronizacji, to zrób tak

Kod: [Zaznacz]

10 PAUSE 1 : BORDER 0 : BORDER 1 : BORDER 2 : BORDER 3 : BORDER 4 : BORDER 5 : BORDER 6 : BORDER 7 : BORDER 6 : BORDER 5 : BORDER 4 : GO TO 10


[Abrimaal]

Ok, to może dalej. Lista timingu poszczególnych modeli byla podana w którymś temacie. Pozwolę sobie ją skopiować z zapisanego pliku (rozjechala sie troche). AY clock tutaj nie wchodzi w grę. Interesują mnie pozostałe wartości. Gdybym chciał podzielić border na dwie części (w wybranej konfig. sprzętu), które wartości są istotne? Top Border podany jest 2 razy. Domyślam się że wartości LB i TB to ilość taktów CPU od początku ramki (przerwania czy HALT), lepiej jednak nie domyślać się i poprosić o wytłumaczenie znaczenia poszczególnych parametrów.

Kod: [Zaznacz]

Name            CPU clock       AY clock        LB  HS   RB  HR         TB  VS   BB  VR         IRQ     Top border      pattern
-----------------------------------------------------------------------------------------------------------------------------------
16K                  3500000         0               24, 128, 24, 48         48, 192, 48, 24         32      14336           65432100
48K                  3500000         0                24, 128, 24, 48         48, 192, 48, 24         32      14336           65432100
48K NTSC         3527500         0                  24, 128, 24, 48         24, 192, 25, 23         32      8960             65432100
128K                3546900         1773400        24, 128, 24, 52         48, 192, 48, 23         36      14362           65432100
+2                   3546900         1773400         24, 128, 24, 52         48, 192, 48, 23         36      14362           65432100
+2A                 3546900         1773400         24, 128, 24, 52         48, 192, 48, 23         32      14362           76543210
+3                   3546900         1773400         24, 128, 24, 52         48, 192, 48, 23         32      14362           76543210
+3e                 3546900         1773400         24, 128, 24, 52         48, 192, 48, 23         32      14362           76543210
TC2048            3500000         0               24, 128, 24, 48         48, 192, 48, 24         32      14321           65432100
TC2068            3500000         1750000         24, 128, 24, 48         48, 192, 48, 24         32      14321           65432100
TS2068            3528000         1764000         24, 128, 24, 48         24, 192, 25, 21         32      9169             65432100
Pentagon        3584000         1792000         36, 128, 28, 32         64, 192, 48, 16         36      17988           65432100
Pentagon 512K   3584000     1792000         36, 128, 28, 32         64, 192, 48, 16         36      17988           -
Pentagon 1024K 3584000     1792000         36, 128, 28, 32         64, 192, 48, 16         36      17988           -
Scorpion          3500000         1750000         24, 128, 32, 40         48, 192, 48, 24         36      14336           -
SE                    3500000         1750000         24, 128, 24, 48         47, 192, 48, 25         32      14336           65432100

[matofesi]

Jakbyś przeczytał to, co było napisane pod tabelką, to nie musiałbyś pytać

Line timings - czasy poszczególnych elementów pojedynczej linii w taktach (t-states)
    LB - left border - lewa część ramki
    HS - horizontal screen - główna część linii
    RB - right border - prawa część ramki
    HR - horizontal retrace - powrót plamki
Frame timings - czasy poszczególnych elementów ramki w liniach
    TB - top border - górna część ramki
    VS - vertical screen - główna część ekranu
    BB - bottom border - dolna część ramki
    VR - vertical retrace - powrót plamki

LB to lewy border, TB to górny border.

Frame timings podane są w liniach, Line timings w taktach. Pojedyncza linia to suma taktów z Line Timings - dla 48K to na przykład 24+128+24+48=224 takty na linię. Czyli na przykład górny border ma w sumie 48*224=10752 takty i tyle właśnie czasu musisz odczekać od początku bordera, żeby zmiana koloru ramki trafiła dokładnie w początek bitmapy ekranu. Dodatkowo trzeba oczywiście uwzględnić sam czas obsługi przerwania (kolumna IRQ w taktach), czas powrotu plamki (bo przerwanie generowane jest na koniec a nie na początek ekranu) oraz czas wykonania samej procedury obsługi (zrzucenie przynajmniej części rejestrów na stos itp. - o ile robisz to w przerwaniach). Po przeliczeniu tych wszystkich "opłat administracyjnych" możesz sobie wyliczyć ile czasu musisz jeszcze "zmarnować", żeby dojść do tego punktu na ekranie w którym chcesz zmieniać kolory. O ile w wypadku prostego dzielenia bordera czy rysowania na nim pasków na całą szerokość sprawa jest stosunkowo prosta o tyle przy próbach dzielenia w pionie liczenie jest odrobinę bardziej skomplikowane. Generalnie kod generujący efekty na borderze składa się głównie z pętli opóźniających

No i oczywiście to wszystko wygląda tak prosto tylko w wypadku bordera. Jeśli próbujesz zrobić prawdziwy multicolor na atrybutach dochodzi oczywiście kwestia memory contention czyli "wyścigu" między ULA a procesorem o dostęp do pamięci (a właściwie po prostu blokowania przez ULA procesora). Ostatnia kolumna to liczba taktów opóźnienia zależnie od tego w którym momencie odwołujesz się do pamięci ekranu. Dla 48K masz 65432100 co oznacza, że jeśli do pamięci ekranu próbujesz się dostać   w takcie 14335 (kolumna Top border to przeliczony na takty czas od fizycznego wywołania przerwania do punktu w którym ULA pobiera pierwsze dane z pamięci ekranu a co za tym idzie do logicznego punktu w którym rysowany jest pierwszy piksel bitmapy - dla 48K jest to 14336 taktów)  - oczywiście liczymy od zera - ULA do twojego rozkazu dostępu do pamięci wykonanego w tym punkcie dorzuci 6 dodatkowych taktów. Jeśli trafisz takt później - 5 itd. przez 6 kolejnych punktów. Potem masz dwa takty w których dostęp do pamięci nie dorzuca dodatkowego opóźnienia a następnie całość zaczyna się od początku - 16 razy na linię. Następnie wyświetlany jest prawy border, powrót plamki i lewy border - w 48K 24+48+24=96 taktów w których pamięć jest dostępna bez opóźnień i cały cykl zaczyna się od początku. Licząc więc takty dal multicoloru musisz uwzględniać te opóźnienia - musisz dokładnie wiedzieć w którym miejscu wyświetlania ekranu znajduje się twój kod i stosownie do tego uwzględniać opóźnienia. Musisz oczywiście pamiętać, że opóźnienia dotyczą nie tylko ekranu, ale każdego dostępu do pamięci od $4000 do $7fff - nawet jeśli nie zapisujesz w ekran a masz tylko jakieś zmienne w tym zakresie, to dostęp do nich (zarówno zapis jak i odczyt) musisz również uwzględnić w wyliczeniach. W wyliczeniach musisz też uwzględniać to, że opóźniane są (według tego samego wzorca) rozkazy IN i OUT odwołujące się do parzystych portów.
W wypadku prostszych efektów można sobie darować dokładne wyliczenia i zrobić kod "na rympał" poprawiając czasy "na oko" albo dodać sobie procedurki obsługi klawiatury zmieniające stałe czasowe i synchronizować efekt tak długo aż trafisz w to, czego oczekujesz.

Na koniec oczywiście jest jeszcze kwestia tego, że zależnie od maszyny na której kod się wykonuje czasy są różne - 48K ma 224 takty na linię ale 128K już 228 a +2A/+3 mają inny wzorzec opóźnień itd. Zrobienie efektu, który będzie wyglądał dobrze na każdym sprzęcie jest dość trudne - albo trzeba policzyć i przygotować kod dla różnych wersji a następnie robić detekcję i stosować odpowiednią wersję kodu albo przeprowadzić detekcję opóźnień, czasów itp. i na tej podstawie wygenerować właściwe pętle opóźniające. Można też po prostu napisać, że nasz efekt jest przeznaczony dla Spectrum 128 i na tym poprzestać

W załączniku przykład najprostszego efektu - podział ekranu na dwie równe części. Kod jest zrobiony trochę "na oko" i tylko dla 48K, ale działa

Kod najpierw przygotowuje procedurę obsługi przerwań z pustą obsługą (EI+RET), potem wypełnia atrybuty - górna połówka żółta, dolna niebieska a następnie zaczyna główną pętlę opóźniającą. Żeby podzielić ekran na pół pierwszy OUT musi się pojawić na początku ramki zaraz poprzerwaniu, drugi w połowie, czyli w punkcie

Kod: [Zaznacz]

top_border - left_border - horizontal_retrace + 224 * ( 192/2)
Dla 48K będzie to

Kod: [Zaznacz]

14336-24-24+(224*(192/2)) = 35792
I tyle właśnie musimy odczekać od początku ramki, żeby drugi OUT trafił w połowę ekranu. Pętla wygląda więc tak:

Kod: [Zaznacz]

        ei
        halt

        ld a,6          ; 7
        out ($fe),a     ; 11
Wygenerowanie przerwania to 32 takty, jego obsługa to 4+10 (EI+RET), zmiana koloru ramki kolejne 18 - razem 64 takty.

Kod: [Zaznacz]

        ld bc,992         ; 10
l0:
        nop               ; 4
        nop               ; 4
        nop               ; 4

        dec bc            ; 6
        ld a,b            ; 4
        or c              ; 4
        jp nz,l0          ; 10
Licznik pętli to właśnie to, co zawsze trzeba sobie dostosować - musimy "zmarnować" 35792 i do tej wartości musimy się zbliżać. Wiedząc, że obsługa pętli zajmuje konkretną liczbę taktów możemy sobie podzielić jedną wartość przez drugą, zaokrąglić i uzyskać jakiś licznik. Jeśli do pętli dorzucimy kilka NOPów (po 4 takty każdy) licznik się zmniejsza itd.
W naszym przypadku pętla i 3 NOPy to 36 taktów. Jeśli od 35792 odejmiemy początkowe 64 takty i 10 taktów na inicjalizację licznika i wynik podzielimy przez 36 dostajemy 992 "z kawałkiem". Liczymy więc dalej... 36*992 = 35712 - tyle zużywa pętla. 35792-35712-74=6 - i tyle taktów zostaje nam do punktu, w którym mamy wykonać drugiego OUTa.

Kod: [Zaznacz]

        ld a,1          ; 7
        out ($fe),a
Zużywamy o jeden takt za dużo, ale w wypadku bordera nie ma to strategicznego znaczenia, bo trafiamy z OUTem gdzieś w powrót plamki i zmiana koloru i tak trafia tam, gdzie jej oczekujemy

I to właściwie tyle - jeśli efekty mają być bardziej skomplikowane musimy się bardziej nakombinować z liczeniem, ale zasada jest właśnie taka

[RafalM]

To często nie jest też tak że na początku siadasz z kartką i kalkulatorem i wszystko wyliczasz a potem już tylko zamieniasz na kod.

Wszystkie te multicolory można robić empirycznie, metodą prób i błędów i chyba czasem tak jest łatwiej niż wszystko ogarnąć w teorii i wyliczyć.

Czyli np.:
-piszesz jakiś atrybut na ekran
-robisz jakieś opóźnienie wzięte na razie z sufitu
-piszesz nowy atrybut na ekran

i patrzysz co wyszło. Czy zmienił się za wcześnie, za późno czy w sam raz, czyli z początkiem nowej linii. Jak jest dobrze to zostawiasz jak nie, to zmieniasz opóźnienie w pożądanym kierunku i znów sprawdzasz.

[matofesi]

Jak z każdym problemem można podejść na kilka sposobów - ten opisany przeze mnie to taki mniej więcej "naukowy". To o czym ty piszesz to metoda, którą ja nazywam "na rympał"

W wypadku prostszych efektów można sobie darować dokładne wyliczenia i zrobić kod "na rympał" poprawiając czasy "na oko" albo dodać sobie procedurki obsługi klawiatury zmieniające stałe czasowe i synchronizować efekt tak długo aż trafisz w to, czego oczekujesz.

Oczywiście, że się da, ale czasem dobrze jest też rozumieć co dokładnie się robi - przy pierwszych zabawach z multikolorem rozumiałem tylko to, że muszę się zmieścić przed rastrem. Nie mieliśmy wtedy takich ładnych rozpisek taktów, linii itp. i w zasadzie wszystko było na rympał

[Abrimaal]

Dzięki za tak szczegółowe wyjaśnienie i kod-bazę od którego można zacząć. Próbowalem kiedyś zmieniać kolor w jednej kratce i - nigdy nie myślałem że wymaga to takich opóźnień aby linie "stały".
Mam na myśli połączenie multikoloru z ULAplus, np. jakiś płynnie rozjaśniający się napis, przechodzący z jednego koloru w drugi. Już nawet w standardowych kratkach prezentuje się to bardzo efektownie, gdyby udało się połączyć z multikolor, można osiągnąć efekt, jakiego jeszcze nie było.
Istnieje takie mini-demo dla ULAplus, które zmieniając wartość koloru dla ekranu w jednym kolorze, w nieskończonej pętli tworzy pełnoekranowy multikolor używając tylko instrukji OUT i licznika. Nie jest to wprawdzie zsynchronizowane, ale łącząc obie metody efekt byłby Shock (sic!).
Kod wygląda tak. Nie wiem jak z synchronizacją dla JR NZ, które ma różną ilość taktów. W tym o czym myślę nie byłoby instrukcji warunkowych, wartości kolorów by były odczytywane z tabeli w pamieci, zmieniane w stałych odstępach. Tylko... czy jest to wykonalne?

Kod: [Zaznacz]

LD D, 64 ; 32768 7Ts
LD BC, 48955 ; 32770 10Ts
OUT (C), D ; 32773 12Ts
LD D, 1 ; 32775 7Ts
LD BC, 65339 ; 32777 10Ts
OUT (C), D ; 32780 12Ts
LD D, 9 ; 32782 7Ts
LD BC, 48955 ; 32784 10Ts
OUT (C), D ; 32787 12Ts
LD D, 0 ; 32789 7Ts
LD BC, 65339 ; 32791 10Ts
OUT (C), D ; 32794 12Ts
LD D, 1 ; 32796 7Ts
LD BC, 254 ; 32798 10Ts
OUT (C), D ; 32801 12Ts
LD D, 8 ; 32803 7Ts
LD BC, 48955 ; 32805 10Ts
OUT (C), D ; 32808 12Ts
LD D, 0 ; 32810 7Ts
LD E, 0 ; 32812 7Ts
LD L, 0 ; 32814 7Ts
L_8030: LD BC, 65339 ; 32816 10Ts
OUT (C), E ; 32819 12Ts
LD A, 10 ; 32821 7Ts
NOP ; 32823 4Ts
L_8038: DEC A ; 32824 4Ts
JR NZ, L_8038 ; 32825 7/12Ts
NOP ; 32827 4Ts
NOP ; 32828 4Ts
NOP ; 32829 4Ts
INC E ; 32830 4Ts
INC D ; 32831 4Ts
JR NZ, L_8030 ; 32832 7/12Ts
LD D, 1 ; 32834 7Ts
LD BC, 254 ; 32836 10Ts
OUT (C), D ; 32839 12Ts
INC L ; 32841 4Ts
LD E, L ; 32842 4Ts
HALT ; 32843 8Ts
LD D, 0 ; 32844 7Ts
LD A, 194 ; 32846 7Ts
L_8050: DEC A ; 32848 4Ts
JR NZ, L_8050 ; 32849 7/12Ts
LD A, 235 ; 32851 7Ts
L_8055: DEC A ; 32853 4Ts
JR NZ, L_8055 ; 32854 7/12Ts
OUT (C), D ; 32856 12Ts
JP L_8030 ; 32858 10T

[RafalM]

Co to przedstawiłeś to jeszcze inna technika, różna od "normalnego" multicoloru i możliwa tylko na ULA+. Trzeba by pewnie dla niej wymyśleć jakąś nazwę

W zwykłym multicolorze na Spectrum bez dopalaczy zmieniamy w locie wartość atrybutów i piszemy nowy atrybut do każdej kratki gdzie ma być multicolor.

Tutaj wysyłasz tylko jedną wartość do portu i od razu zmieniasz całą paletę - wszystko od tego rozkazu będzie sie rysowało już samo w nowych kolorach. Pewnie tak jest nawet łatwiej. Tylko jak to mówią to już nie jest Spectrum     

[Frodo]

Zużywamy o jeden takt za dużo, ale w wypadku bordera nie ma to strategicznego znaczenia, bo trafiamy z OUTem gdzieś w powrót plamki i zmiana koloru i tak trafia tam, gdzie jej oczekujemy

I to właściwie tyle - jeśli efekty mają być bardziej skomplikowane musimy się bardziej nakombinować z liczeniem, ale zasada jest właśnie taka

<przykład split_border.asm>
W tym przykładzie mamy dwukrotnie out out ($fe),a z różnymi kolorami. Nie wiem dlaczego w emulatorze zxspin odrysowuje cały ekran dzieląc po połowie zamiast borderu. Gdy debuguję i zmieniam wartość w rejestrze a, wtedy uruchomiony dalej program zmienia mi tylko kolor ramki. Ale na początku zmienił cały ekran.

[matofesi]

Port $fe odpowiada za kolor ramki. Ekran jest na początku wypełniany odpowiednimi atrybutami tak, żeby był podzielony na pół. Jak chcesz zmienić kolory na ekranie to musisz zmienić atrybuty używane do jego wypełnienia w pętli na początku.

[rafamiga]

Tak swoją drogą, zamiast żmudnego liczenia cykli wystarczyło znaleźć odpowiednią liczbę dla B i zrobić DJNZ w miejscu. Tak robiłem swoje efekty na borderze, zdaje się było tam:

LD B,12
DJNZ $

Czeka dokładnie jedną linię, circa about.

Trudniej było zrobić napisy na borderze, jak np. w Sentinelu. Ale dawało się, magiczną instrukcją OTIR albo sekcją OUTI i paroma NOP-ami.

[matofesi]

Tak swoją drogą, zamiast żmudnego liczenia cykli wystarczyło znaleźć odpowiednią liczbę dla B i zrobić DJNZ w miejscu.

Ależ oczywiście, że można. Tak robiliśmy to "w dawnych czasach" i to jest metoda, którą nazywam "na rympał" - podstawiamy jakieś opóźnienia i patrzymy czy pasuje a jak nie to szukamy innej wartości. I to jest oczywiście jedna z możliwych metod.

Tyle, że jeśli chcesz pewne rzeczy zrobić precyzyjnie (np. normalny multicolor na atrybutach powiązany z borderem) to czasem dobrze jest wiedzieć co dokładnie i w którym miejscu się dzieje i sobie pewne rzeczy policzyć zamiast dopasowywać