Player ETrackera.

[Sir David]

W skrajnych przypadkach praktykowało się prerenderowanie muzyki (w całości czy fragmentach) do pamięci i wtedy player, którego rola sprowadzała się do ustawienia rejestrów AY, zajmował w ogóle grosze.

Właśnie coś takiego chodzi mi ostatnio po głowie. Mam zamiar zrobić taki player na Sama, ale jeszcze nie zdążyłem się przysiąść. Sam pamięci ma pod dostatkiem, ale każdy takt na wagę złota. Dla dem, które teraz próbuję pisać, byłoby to idealne rozwiązanie. Jeżeli player do ETrackera trzyma gdzieś w pamięci wartości wszystkich rejestrów SAA, to sprawa byłaby bardzo prosta. Może Mat pamięta, czy trzyma i ewentualnie gdzie? Oszczędziłoby mi to grzebania się w playerze.

[matofesi]

Trzyma. Informacja w którym miejscu powinna być w manualu - po tylu latach niestety nie pamiętam.

edit: No dobra... sprawdziłem w manualu - nie ma tej informacji. Będziesz jednak musiał pogrzebać.

[Tygrys]

To ja jeszcze dodam ze Mat nie pisał playera do muzyki, lecz edytor. Zrobił to Kaz. Tak więc aby Ci podpowiedzieć co i jak, musiałby wykonać taką samą pracę, jaką ma do wykonania Sir David.

[Sir David]

Wiem, że player pisał Kaz, ale Mat mógł mieć trochę przydatnych informacji na jego temat. Położenie tablicy wartości rejestrów taką jest, choćby do wskaźników częstotliwości/głośności kanałów (z tego co wiem, z rejestrów SAA nie da się nic odczytać). Dobrze przynajmniej wiedzieć, że to, czego szukam, tam jest

[matofesi]

Wykonał Z szybkiego oglądu zdisassemblowanego playera wychodzi mi, że rejestry siedzą w playerze zaczynając od offsetu $03d3. Kawałek kodu, który wyrzuca dane na porty wygląda tak:

Kod: [Zaznacz]

                ld bc,$01FF      ; 01FF01     ; db $01, $FF, $01
                ld de,$1C01      ; 11011C     ; db $11, $01, $1C
                out (c),d        ; ED51       ; db $ED, $51
                dec b            ; 05         ; db $05
                out (c),e        ; ED59       ; db $ED, $59
l_810F:         ld hl,l_83EC     ; 21EC83     ; db $21, $EC, $83
                ld d,$19         ; 1619       ; db $16, $19
l_8114:         inc b            ; 04         ; db $04
                out (c),d        ; ED51       ; db $ED, $51
                dec b            ; 05         ; db $05
                ld a,(hl)        ; 7E         ; db $7E
                out (c),a        ; ED79       ; db $ED, $79
                dec d            ; 15         ; db $15
                ret m            ; F8         ; db $F8
                dec hl           ; 2B         ; db $2B
                jr l_8114        ; 18F4       ; db $18, $F4


[matofesi]

@Sir David Problem polega na tym, że mnie się z czasów sama zachowała słaba kserówka technical manuala i jeden zeszyt z jakimiś notatkami nie związanymi z tematem. I to co w głowie

[Sir David]

Wykonał

Dzięki Mat! Ale może jeszcze coś mi podpowiesz? Widzę, że zapisywane są rejestry od $00 do $19 (od $1a do $1f są nieużywane, pomijając jedno użycie $1c na starcie).  Tylko że w SAA jest jeszcze kilka nieużywanych rejestrów z tego zakresu, są to: $06,$07,$0e,$0f,$13,$17. Czyżby mimo to były za każdym razem zapisywane? To jednak trochę strata czasu, nawet ten player można było nieco przyśpieszyć za cenę lekkiego wydłużenia kodu. Dobrze myślę?

[matofesi]

Prawie wszystko można przyspieszyć  Tutaj bardziej chodziło o to, że player i wynikowy moduł mają być małe. Inna wersja kompilatora, która nie pozwalała używać jakiejś kombinacji obwiedni dawała większy moduł, player był ciut większy ale za to działał sporo szybciej.

Tutaj najprostszą metodą byłoby rozwinięcie pętli. Tylko nie jestem pewien czy zysk byłby większy niż kilkadziesiąt taktów. Ale jak ci się chce bawić, to w załączniku masz rozkompilowanego playera - nie poprawiałem zmiennych więc musiałbyś się temu przyjrzeć bliżej, ale to co jest po kompilacji pasmo daje dokładnie ten sam wynik binarny co na początku.

[Sir David]

Prawie wszystko można przyspieszyć  Tutaj bardziej chodziło o to, że player i wynikowy moduł mają być małe.

Hmmm... Ale w sumie po co małe? Na Samie? Tu bardziej doskwiera niedostatek taktów, a nie pamięci

Inna wersja kompilatora, która nie pozwalała używać jakiejś kombinacji obwiedni dawała większy moduł, player był ciut większy ale za to działał sporo szybciej.

Sprawdzałem i niestety te fajniesze moduły (z różnymi efektami) brzmią wtedy źle... Więc takie rozwiązanie raczej odpada.

Tutaj najprostszą metodą byłoby rozwinięcie pętli. Tylko nie jestem pewien czy zysk byłby większy niż kilkadziesiąt taktów.

O tym pomyślałem. Zysk może niezbyt wielki, ale player wystarczyło napisać raz i go wszędzie używać, można więc było wycisnąć na prędkości ile się da.

Ale jak ci się chce bawić (...)

W tego typu player nie chce mi się. Jak na początku mówiłem, zamierzam napisać player, który w zasadzie by tylko wrzucał do rejestrów uprzednio przygotowane dane. Do przygotowania tych danych chcę użyć playera z ETrackera. Moduł będzie zajmował dużo, jak na 8-bitowce nawet bardzo dużo, ale na Samie to nie problem. Zobaczę też jeszcze, jak takie dane się kompresują. Jak dobrze, to będzie w ogóle super

[matofesi]

Hmmm... Ale w sumie po co małe? Na Samie? Tu bardziej doskwiera niedostatek taktów, a nie pamięci

Na prawdę uważasz, że będę pamiętał dlaczego decyzja była taka a nie inna?

Sprawdzałem i niestety te fajniesze moduły (z różnymi efektami) brzmią wtedy źle... Więc takie rozwiązanie raczej odpada.

Bo to było rozwiązanie dla świadomego ograniczeń twórcy modułów - większość (jeśli nie wszystkie) prac Ziutka używanych w naszych produkcjach kompilowała się poprawnie "szybkim" kompilatorem.

[RCL]

zamierzam napisać player, który w zasadzie by tylko wrzucał do rejestrów uprzednio przygotowane dane. Do przygotowania tych danych chcę użyć playera z ETrackera. Moduł będzie zajmował dużo, jak na 8-bitowce nawet bardzo dużo, ale na Samie to nie problem. Zobaczę też jeszcze, jak takie dane się kompresują. Jak dobrze, to będzie w ogóle super

Może zajmować bardzo dużo. Nawet na AY, gdzie rejestrów jest mniej, to dzieśiątki kilo.  Ale zobacz czy proste RLE w locie (per rejestr) nie skróci tego jakoś znacząco.

Na dodatek, można zachować strukturę patternów czy kanałów.

[Sir David]

Podział na patterny chcę zachować. Z pierwszych prób wynika, że bez żadnej optymalizacji, wrzucając co ramkę całe 26 rejestrów, pattern zajmuje ok. 10 kB (lub niewiele ponad). Daje to rząd wielkości 100 kB na cały moduł. Do przełknięcia jeżeli się okaże, że dzięki temu zyskuje się sporo czasu. A już mam parę pomysłów na optymalizację, tylko muszę przeanalizować zmienność w czasie danych wrzucanych do poszczególnych rejestrów.