Kurs Assemblera cz. 6
- TeBe / MadTeam
Tematem tego wydania kursu jest InertiaPlayer & ProTracker. Na początek trochę historii, czyli jak doszło do powstania Inertii, a potem ProTrackera.
Wszystko zaczęło się od wydania przez Mirage pakietu z playerem plików MD8. Były to zmodyfikowane pliki MOD, tzn. sample 8-bitowe przekonwertowane na 4-bit, oraz zmiany w trackach itp. Wszystie te zmiany miały przyspieszyć odgrywanie i skrócić rozmiar w stosunku do oryginalnego pliku MOD. Zaowocowało to wzrostem zużytych dyskietek 5i1/4 i niemożnością pochwalenia się swoją twórczością przed użytkownikami Amig, PC, ST. Profi jako zapalony muzykant, dotąd tylko CMC, później MPT zapragnął nie tylko dokonywać konwersji MOD->MD8, ale stworzyć w końcu coś swojego.
Sam engin playera, sposób regulacji głośności sampla, schemat odczyty pliku MD8 otrzymaliśmy od Marka Goderskiego, autora opisu systemu SpartaDosX. Ten bardzo ciekawski człowiek postawił sobie za cel disasemblacje playera i przyjrzenia mu się z bliska. Sam program był zabezpieczony, ładował się w niskie obszary normalnie nachodząc na DOS, dodatkowo był eorowany kilka razy. Autorom bardzo zależało by nikt nie zajrzał do źródełka ;). Dzięki odpowiedniej wersji Sparty, zostawiającej dużo miejsca dla programów, swoich disasemblerów i innych narzędzi pod Sparte, udało się Markowi zdisasemblować player i zrozumieć jego działanie. Tak wyedukowani przez niego i wzbogaceni źródełkami w formacie jedynie słusznym czyli QA (obecnie X-Asm), zaczęliśmy tworzyć Inertie, tzn. Profi zaczął tworzyć, potem doszła niezdrowa konkurencja z mojej strony, tzn. jak on stworzył wersje np. X, to ja coś poprawiałem i wychodziła wersja Y. Podobnie było w przypadku Visage, on zaczął, ale że nie miał procedur kompresji, dekompresji to ja skończyłem. Może dlatego Profi potem odwrócił się od Madtemu, a może to przez dziewczynę.
Wracając do tematu, mieliśmy playera co prawdza tylko MD8, ale nie było jeszcze 8-bitowego przetwornika. Na horyzoncie pojawił się jednak Psychol, który oprócz masy innych wynalazków militarnych jak żelazko rozpylające gaz wpadł na pomysł zwiększenia możliwości dźwiękowych Atarka przez 8-bitowy przetwornik. Ekipa Madteamu zebrała się w ciemnym pokoiku Psychola, by usłyszeć nową zabawkę. Na początku był tylko 1 kanał. Psychol napisał sobie program do odtwarzania sampli, by potem męczyć sąsiadów telefonami i odtwarzanymi z Atari dziwnymi tekstami. Zrobił też automatyczną sekretarkę, która odtwarzała nagrany tekst, a potem zapisywala ileś KB rozmowy.
Pojawiły się inne pomysły na zastosowanie wynalazku, w tym czasie mieliśmy już źródła playera MD8, wiedzieliśmy że tak naprawdę gra on na jednym kanale, wartość wpisywana do rejestru była wyliczana jako suma wszystkich kanałów. Taki sposób miał wyeliminować zagłuszanie się jednego kanału przez drugi (pewnie chodzi o interferencje). Profi wziął się z zapałem do pracy i tak narodziła się późniejsza Inertia. Aktualnie wczytywała jeszcze MD8 ale odtwarzała już na 8-bitowym przetworniku, jakby go nazwać ... Covoxie ;) Efekt odgrywania sumy 4 kanałów na 1 przetworniku był mało zadowalający, były duże zniekształcenia, zbyt wyraźnie było to słychać. Tak więc żeby dużo nie kombinować trzeba dorzucić następne 3 kanały. I tak dzięki współpracy Psychola i Profiego zaczął wyłaniać się coraz to bardziej dopracowany kształt playera. Pojawiły się też sugestie aby przyspieszyć player przez sprzętową regulacje głośności, ale Psychol stwierdził, że skomplikowałoby to zbytnio całego Atarowskiego Covoxa. Tak więc pozostaliśmy przy metodzie zastosowanej w MD8, odpowiednio tylko modyfikując tablice głośności, ze wzoru którego już nie pamiętam.
Natomiast ProTracker był naturalnym rozwinięciem Inertii, który miał zaspokoić ambicje twórcze Profiego. Był to największy jego projekt, projekt jak najbardziej udany i skończony. Przedtem był jeszcze nigdy nie pokazany ogółowi sampler i odtwarzacz sampli w zbajerowanym przez Rockego środowisku graficznym, z graficznym equilizerem, z zaznaczaniem fragmentów sampla i wszystkich z tym związanych bajerów.
Inertia Player v3.7
Nie jest to wersja Inertii Profiego, ale nie powinna się wiele różnić od jego wersji 3.7 (może kiedyś zdarzy się cud, Profi zajrzy tutaj i dorzuci coś do tego ogródka). Operacje I/O ze stacją dysków odbywają się bez udziału DOSu. Tak więc Pinokiowi się to nie spodoba ;)
Tak jak w przypadku ProTrackera jeśli ktoś będzie chciał cokolwiek modyfikować, niech to będzie zorganizowane. Jeden człowiek, czy grupa czuwa nad projektem, inni pomagają. Żeby nie było tak, że nagle pojawi się 100 wersji różniących się autorem ;)
Pare ogólnych uwag na temat działania. Dla przyspieszenia działania playera jest on umieszczony na stronie 0. Całość w sumie zajmuje 3 strony pamięci, od $0000-$02ff i nie ma wpływu na stos, stos jest nieużywany, ponieważ wyłączone są wszelkie przerwania. Normalnie kod playera umieszczony jest gdzieś w pamięci i dopiero gdy jest potrzebny przepisywany jest na strone 0 i dalej. Oczywiście zawartość strony 0 musi zostać zachowana, a po skończeniu odgrywania jest odtwarzana jej zawartość.
W celu przyspieszenia odgrywania sampli, sprawdzany jest tylko starszy bajt ich adresu. Sposób ten wymaga aby sample były odpowiednio umieszczone w pamięci, tzn. młodszy bajt adresu ostatniego bajtu sampla jest równy 0. Jak to osiągngąć? Długość sampla jest reprezentowana przez liczbe stron, tzn. dla długości sampla $1578 mamy $15+1 stron. W jednym banku pamięci zmieścimy $40 stron. Najwięcej stron zmieścimy w pamięci głównej, będzie tutaj najdłuższy z sampli. Jeśli będziemy korzystali z DOSu tej pamięci będzie mniej.
Podczas odtwarzania sampli wyłączone są wszystkie przerwania. Synchronizacja odbywa się przez wywołanie procedury odgrywającej sample N razy. Ta procedura znajduje się właśnie na stronie zerowej pamięci. Potem następuje skok do procedury odczytującej pattern, modyfikacja adresów w playerze i znowu skok na strone zerową. Player za każdym razem kiedy wpisuje wartości do 4 kanałów musi zajmować tyle samo cykli zegara. Im dokładniej będzie to zrealizowane tym lepszej jakości otrzymamy dźwięk. Dokładniej częstotliwość odtwarzania mierzył Psychol oscyloskopem i jakimś swoim elektronicznym urządzeniem. Zliczało ono odwołania do strony pamięci z rejestrami Covoxa.
Przykład odtworzenia sampla na 1 kanale w playerze Inertia. Pętla ma stałą długość deklarowaną w stałej VBL, tutaj $d8 i ma ona wpływ na tempo. Jakakolwiek zmiana w playerze, zmieniająca liczbe cykli spowoduje zmianę tej wartości.
pmain equ *
bank0 lda #$fe ;bank w którym znajduje się sampl
sta $d301
ist_0 lda #0 ;tego nie rozumiem, bo brak w playerze odwolan do ist_0 itp.
iad0_m adc #0 ;ale sa odwołania do "iad0_m" i "iad0_s"
sta ist_0+1
lda p_0c+1 ;modyfikacja adresu sampla, dodajemy wartosc z tablicy czestotliwosci
iad0_s adc #0 ;mlodszy bajt adresu
sta p_0c+1
bcc p_0c
inc p_0c+2 ;starszy bajt adresu
lda p_0c+2 ;sprawdzenie czy to już koniec sampla
ien0_s cmp #0
bcc p_0c
ire0_m lda #0 ;ustawienie nowego adresu poczatkowego sampla
sta p_0c+1 ;czyli petla sampla
ire0_s lda #0
sta p_0c+2
jmp bank1
p_0c ldx $ffff ;wartość sampla
ivol10 lda $d800,x ;tablica głośności
ch0 sta $d600 ;graj, jeśli urzadzeniem jest POKEY to będzie adres $d200
bank1 ........... nastepny kanal itd.
Na końcu tej pętli występuje już tylko:
p_e dey ;zmniejszamy wartość Y i pętlimy się dalej
beq pat
jmp pmain
* -----------------
* requests
pat ldy #vbl ;odświeżamy zawartość rejestru Y
dec cnts ;licznik długości patternu
beq pre
jmp pmain
pre lda #0 ;tutaj zaczyna się procedura dekodowania patternu
sta patend
lda #$fe
sta $d301
*---------------------------
* track 0
Normalnie w pliku ASM wygląda to inaczej ponieważ wszyskie rozkazy "lda" "sta" "inc" musiały zostać zapisane w formie "dta b(lda),b(value)", dlaczego? Spójrzmy na taki przykład:
org $0000 lda bajt bajt dta b(0,1,2,3,4,5)
Po kompilacji otrzymamy:
X-Assembler 2.5.2 by Fox/Taquart
Source: G:\!Atari\inne\_profi\it37\xxx.asm
1 opt h+
2 org $0000
3
4 0000 main
5 FFFF> 0000-000B> AD 06 + lda bajt ;rozkaz $AD nie dotyczy strony zerowej
6 0003 AE 07 00 ldx bajt+1 ;tutaj też zamiast na 2-óch bajtów mamy 3-y
7
8 0006 00 01 02 03 04 05 bajt dta b(0,1,2,3,4,5)
Dopiero jeśli tablica "bajt" wystąpiłaby przed programem, kompilator skompilowałby to z rozkazami strony zerowej.
X-Assembler 2.5.2 by Fox/Taquart
Source: G:\!Atari\inne\_profi\it37\xxx.asm
1 opt h+
2 org $0000
3
4 FFFF> 0000-0009> 00 01 + bajt dta b(0,1,2,3,4,5)
5
6 0006 main
7 0006 A5 00 lda bajt ;mamy 2-bajty
8 0008 A6 01 ldx bajt+1 ;tutaj też czyli to musi dotyczyć strony zerowej
9
Uruchomienie Inertii, kompilacja pliku "IT37.ASM":
opt h+
org $8000 ;załadowanie tablic głośności
ins 'mod8.tab'
org $7000 ;załadowanie skompliowanego playera
ins 'play37.obx'
org $2000 ;załadowanie skompilowanej Inertii
ins 'mod37.obx'
org $600
start ldx #18
ldy #0
s lda $2000,y ;przepisanie Inertii pod adres $0700
d sta $0700,y
dey
bne s
inc s+2
inc d+2
dex
bne s
jmp $0700 ;i uruchomienie
run start
Uruchamiamy plik "IT37.OBX" i możemy już używać Inertii. W przypadku emulatora wystarczy że w napędzie 1 będzie dyskietka z plikami MOD, a program możemy uruchomić przez "ALT+X".
ProTracker v1.5
Dysponuje tylko kopią v1.5, nie jestem pewien czy były nowsze, wiem że w stosunku do Inertii player ma niższą częstotliwość odtwarzania oraz mniej efektów. Ostatnia z Inertii miała coś więcej niż 3 komendy występujące w ProTrackerze. Aktualnie przyglądając się kodowi programu można zauważyć że w QA zabrakło miejsca na etykiety i większość skoków Profi zapisywał w postaci "*+nn", co nie sprzyja przejrzystości programu. Jakiekolwiek modyfikacja muszą być przeprowadzane ostrożnie, ale są możliwe bo Profi nie optymalizował zbytnio trackera.
Oczywiście jeśli ktokolwiek będzie coś poprawiał powinien udostępnić to ogółowi i powinno to być ujednolicone, tzn. jest jedna osoba która wprowadza modyfikacje, czyli czuwa nad projektem, a nie kildadziesiąt poprawia i kilkadziesiąt wersji się pojawia. Większość osób jest już dorosłych więc nie powinno być problemów ze zrozumieniem tej zasady.
Pierwsza modyfikacja dotyczy procedur zmiany oktawy. Widać że zaremowane znakiem ";" instrukcje w podprogramie "_dn" powtarzają się w podprogramie "_up". Dzięki takiej optymalizacji zwolniliśmy troche pamięci.
_up lda okt ;podnies oktawe 1 wyzej
cmp #2
beq _up1
inc okt
inc okt
_oktShow ldx okt
lda oktawa,x
sta _e1+9
inx
lda oktawa,x
sta _e1+10
inx
lda oktawa,x
sta _e1+11
jsr _pr
_up1 jsr cl_k
rts
_dn lda okt ;opusc oktawe nizej
beq _up1
dec okt
dec okt
; ldx okt
; lda oktawa,x
; sta _e1+9
; inx
; lda oktawa,x
; sta _e1+10
; inx
; lda oktawa,x
; sta _e1+11
; jsr _pr
; jsr cl_k
; rts
jmp _oktShow
"_e1+9" "_e1+10" "_e1+11" to adresy pamięci obrazu, czyli miejsca w których pojawiają się napisy reprezentujące oktawe, np. "1:2" "2:3"
Poniższa modyfikacja optymalizuje szybkość działania, oszczędzamy 2 cykle zegara.
Oryginalnie wyglądało to tak:
_p0rom ldx #0
_pp1 lda TempBuffer,x
tay
A po modyfikacji tak:
_p0rom ldx #0 _pp1
ldy TempBuffer,x
; tay
lda ZeroPage,x
sta TempBuffer,x
tya
sta ZeroPage,x
inx
cpx #$d8
bne _pp1
rts
Zadaniem tej procedury jest przed każdym odegraniem czegokolwiek przepisanie procedur znajdujących się w "TempBuffer" na stronę zerową, a dane znajdujące się na stronie zerowej przepisać do "TempBuffer". Te procedury to skompilowany player, w sumie $d8 bajtów.
Podobnie można postępować w przypadku pozostałych procedur, np. główna rozdzielnia obsługująca klawisze "KEYBD". Oto jej fragment:
keybd jsr wait
lda 764
cmp #231
bne *+5
jmp _exit ;opusc program
cmp #173
bne *+5
jmp _trans ;transpozycja
cmp #150
bne *+5
jmp _exchg ;zmiana instrumentu
cmp #71
bne *+5
jmp inc_p ;zwieksz nr. patternu
cmp #70
bne *+5
jmp dec_p ;zmniejsz nr.patternu
cmp #15
bne *+5
jmp dn_p ;przes. w dol patt.
cmp #14
bne *+5
...
...
...
itd.
Można przyspieszyć działanie kosztem pamięci, np. kosztem 512 bajtów, pierwsze 256 bajtów to młodsze adresy procedur, ostatnie 256 bajtów to starsze adresy procedur. Numer określający kod naciśniętego klawisza z 764 byłby indeksem do naszej tablicy. Bierzemy młodszy, starszy modyfikujemy adres w pamięci i JMP, np.
Sposób najszybszy:
keybd jsr wait
ldy 764
lda lAdr,y ;4 cykle
sta _jmpAdr+1 ;4
lda hAdr,y ;4
sta _jmpAdr+2 ;4
_jmpAdr jmp $ffff ;3
;Razem 15 cykli
Sposób zajmujący więcej cykli zegara, ale najkrótszy. Adresy w tablicy muszą być zmniejszone o 1. Wykorzystana jest właściwośc instrukcji "RTS", która zdejmuje ze stosu pomniejszony o 1 adres powrotny i tam skacze.
keybd jsr wait
ldy 764
lda hAdr,y ;4 cykle
pha ;3
lda lAdr,y ;4
pha ;3
rts ;6
;Razem 20 cykli
Uwaga: Niektóre obszary są deklarowane na "sztywno". Należy dokładnie zapoznać się z mapą pamięci jaką wykorzystuje ProTracker zanim zaczniemy jakieś drastyczne zmiany. W pliku "ADRESY.ASM" znajdują się deklaracje etykiet.
Pierwsze zmiany jakie bym proponował to zamiana skokow "*+nn" na odpowiadające im etykiety.
Główne procedury:
- _VOLMV procedura wywoływana jest przed odegraniem całego MOD-a lub patternu. Przepisuje tablice głośności z ostatniego banku pamięci (spod adresu $4000 pod adres $d800 32-strony pamięci, ostatnią stronę powiela $f700 na $f800).
- LOA_MOD procedura wczytująca plik MOD, patterny pod $c600, nagłówek pliku MOD to 1084 bajty
- PMAIN integralna część playera, tutaj następuje dekodowanie patternu dla każdego tracka i modyfikacja adresów playera.
- IO operacje wejścia/wyjścia
- FUNC2 procedury odczytu sampla z nagłówkiem 27-bajtowym
- ORDERS procedury obsługi edycji okna "ORDER"
- XCHG procedury obsługi "wymiany instrumentu na inny"
- TRANS procedury obsługi "transpozycji"
- FUNCTION pozostałe procedury związane z edycja tracku, patternu itp.
- MOVE przepisuje tablice głośności do ostatniego banku pamięci, jeśli wybrane urządzenie to POKEY to modyfikuje tablice, jeśli COVOX to modyfikuje program i zamiast "lsr @" wstawia rozkazy "nop" wtedy tablica nie zostaje zmodyfikowana. Tablice "TIDL" oraz "TID2" zostają przepisane odpowiedio pod "AdrTidl" oraz "AdrTid2".
- TIDL tablice nut - częstotliwosci dla sampli, wartość z tablicy dodawana jest do adresu sampla
- TID2 tablica nut uzywana podczas edycji do odtwarzania pojedyńczych sampli
- SELECT stąd startuje cały program, rozpoznanie pamięci dodatkowej, wybór urządzenia Pokey lub Covox
Główne pliki:
- TS.FNT zestaw znaków dla ProTrackera, ładowane pod adres $2000
- VOLUME.TAB tablica głośności, ładowana pod adres $8800
- PM.ASM źródło playera, w osobnym pliku bo nie można załadować bezpośrednio do pamięci czegokowiek tak długiego na strone 0.
Sposób kompilacji głównego pliku TR.ASM:
- Najpierw kompilujemy plik "_PMAIN.ASM" bez nagłówka (opt h-). Powstały plik "_PMAIN.OBX" zostanie wykorzystane podczas kompilacji "TR.ASM"
- Kompliujemy plik "TR.ASM". Na samym początku występuje kompilacja pliku "PM.ASM" bez generowania nagłówka i pliku wynikowego "opt h-o-". Jest to konieczny zabieg, który umożliwia pozostałej części programu poznanie adresów występujących w playerze. Odwołania do nich będą kompilowane jako odwołania do strony zerowej. Plik "_PMAIN.OBX" to tak naprawde skompilowany plik "PM.ASM".
