Odtwarzanie RMT w Basicu by Kaz 2009-06-30 08:16:01
Paweł "Sikor" Sikorski:
Na forum atarionline.pl pojawił się temat dotyczący odtwarzania muzyczek w formacie najpopularniejszego obecnie edytora muzycznego dla Atari "Raster Music Tracker" w innych językach programowania niż assembler. Po nieśmiałej propozycji Mikera, że może ktoś się przyjrzy temu i dorobi przerwania, okazało się, że ktoś taki się znalazł. Dokonał tego Marok. Napisał prostą procedurkę, która tak potrafi się odwołać do playera Rastera (który to player, wbrew mojemu wcześniejszemu wyjaśnieniu, nie jest zmodyfikowany), aby potrafił grać w wolnej chwili. Pierwsze testy nie napawały optymizmem, ale ostatecznie wszystko się udało.
Zostałem poproszony o łopatologiczną instrukcję "użycia", bo jak się okazuje, nie każdy potrafi sobie kod sam skompilować i wykorzystać we własnym programie. Postanowiłem więc, że pewne adresy ustawię na sztywno i wszystko połączę w jeden blok, aby było jak najłatwiej użyć procedur odtwarzania. Użyłem liczby mnogiej ponieważ mamy cztery playery, ze względu na specyfikę "Raster Music Trackera".
Ponieważ jestem człowiekiem leniwym, a rzecz robiłem także dla siebie, postanowiłem, że player musi być poniżej adresu $9C00 - bo tam często umieszczam fonty. Adres playera musi się zaczynać od początku strony, metodą prób i błędów wybrałem adres $9500. Mimo różnej długości playerów - postanowiłem, że w tej wersji wszystkie będą startowały właśnie stamtąd.
Procedurę uruchamiającą postanowiłem umieścić bezpośrednio przed playerem, a trzeba wiedzieć, że po kompilacji zajmuje jeszcze kilka bajtów przed sobą - dokładnie kod każdego playera zaczyna się od $9282. Procedurę uruchomieniową po wyliczeniu umieściłem pod adresem $91C9 - ale niestety, zawieszało to komputer lub całkowicie psuło muzykę... Na szczęście w opisie pliku znalazłem wyjaśnienie (zresztą Marok chyba tez o tym wspominał): player jeszcze wykorzystuje około 1KB pamięci poniżej siebie! Ostatecznie procedura uruchomieniowa znalazła się pod adresem $8F85. I wszystko gra :).
Mamy cztery odtwarzacze:
W "Turbo Basic XL" należy dołączyć player i muzyczki, oczywiście odpowiednio ustawionych w pamięci. W przykładzie są ustawione na $7000, ale mogą być gdziekolwiek w przestrzeni dla danych. Używamy do tego prostych instrukcji BLOAD "D:RMTMONO.PLY", którą wczytujemy player oraz BLOAD"D:MUZYKA.RMT". Po skompilowaniu programu, gdy robimy wersję plikową - nie korzystamy z tej metody, tylko linkujemy odpowiednie pliki.
Teraz już możemy używać playera do woli, a zasada jest z grubsza taka, jak przy znanym dużo wcześniej odtwarzaczu CMC. Wywołujemy we własnym programie przez X=USR (adres_procedury_usr, adres_playera, adres_muzyczki, pozycja_w_songu) - i gra muzyka! :). Kilka słów wyjaśnień:
W przypadku załączonych playerów (używamy tylko jednego, wybranego) wpisujemy po prostu: X=USR($8F85,$9500,$7000) - i muzyka gra nam od początku. Uwaga! $7000 to opcja ustawiona w przykładach. Ponadto trzeba pamiętać, że w obecnej wersji odtwarzacze RMT prawidłowo obsługują tylko muzyczki odgrywane 1 raz na ramkę. Proponuję potestować - albo wgrywając playery według receptury zawartej w opisie albo podmieniając pliki z muzyczkami na dyskietce. Jeżeli korzystamy z podanego przeze mnie programu testowego, wszystko musi się znajdować w katalogu zamapowanym jako "D:" (czyli po prostu w stacji numer jeden).
Programy tutaj. Mile widziane raportowanie błędów!
Na forum atarionline.pl pojawił się temat dotyczący odtwarzania muzyczek w formacie najpopularniejszego obecnie edytora muzycznego dla Atari "Raster Music Tracker" w innych językach programowania niż assembler. Po nieśmiałej propozycji Mikera, że może ktoś się przyjrzy temu i dorobi przerwania, okazało się, że ktoś taki się znalazł. Dokonał tego Marok. Napisał prostą procedurkę, która tak potrafi się odwołać do playera Rastera (który to player, wbrew mojemu wcześniejszemu wyjaśnieniu, nie jest zmodyfikowany), aby potrafił grać w wolnej chwili. Pierwsze testy nie napawały optymizmem, ale ostatecznie wszystko się udało.
Raster Music Tracker
Zostałem poproszony o łopatologiczną instrukcję "użycia", bo jak się okazuje, nie każdy potrafi sobie kod sam skompilować i wykorzystać we własnym programie. Postanowiłem więc, że pewne adresy ustawię na sztywno i wszystko połączę w jeden blok, aby było jak najłatwiej użyć procedur odtwarzania. Użyłem liczby mnogiej ponieważ mamy cztery playery, ze względu na specyfikę "Raster Music Trackera".
Ponieważ jestem człowiekiem leniwym, a rzecz robiłem także dla siebie, postanowiłem, że player musi być poniżej adresu $9C00 - bo tam często umieszczam fonty. Adres playera musi się zaczynać od początku strony, metodą prób i błędów wybrałem adres $9500. Mimo różnej długości playerów - postanowiłem, że w tej wersji wszystkie będą startowały właśnie stamtąd.
Procedurę uruchamiającą postanowiłem umieścić bezpośrednio przed playerem, a trzeba wiedzieć, że po kompilacji zajmuje jeszcze kilka bajtów przed sobą - dokładnie kod każdego playera zaczyna się od $9282. Procedurę uruchomieniową po wyliczeniu umieściłem pod adresem $91C9 - ale niestety, zawieszało to komputer lub całkowicie psuło muzykę... Na szczęście w opisie pliku znalazłem wyjaśnienie (zresztą Marok chyba tez o tym wspominał): player jeszcze wykorzystuje około 1KB pamięci poniżej siebie! Ostatecznie procedura uruchomieniowa znalazła się pod adresem $8F85. I wszystko gra :).
Mamy cztery odtwarzacze:
- RMTMONO.PLY - jak sama nazwa wskazuje, playerek dla
4-kanałowych plików monofonicznych, zajętość pamięci wygląda tak:
USR - $8F85-$9037, player - $9282-9A4D (dla wszystkich USR jest
taki sam, w niektórych muzyczkach można wcisnąć coś między USR-a a
playera).
- RMT4ST.PLY - jak nazwa wskazuje, player stereo dla muzyczek
monofonicznych o przeplocie kanałów L1 L2 R3 R4, pamięć:
$9282-$9A5F.
- RMT4ST2.PLY - jak wyżej, ale L1 R2 R3 L4, $9282-$9A62.
- RMT8ST.PLY - player stereo dla 8 kanałów, $9282-$9B59
W "Turbo Basic XL" należy dołączyć player i muzyczki, oczywiście odpowiednio ustawionych w pamięci. W przykładzie są ustawione na $7000, ale mogą być gdziekolwiek w przestrzeni dla danych. Używamy do tego prostych instrukcji BLOAD "D:RMTMONO.PLY", którą wczytujemy player oraz BLOAD"D:MUZYKA.RMT". Po skompilowaniu programu, gdy robimy wersję plikową - nie korzystamy z tej metody, tylko linkujemy odpowiednie pliki.
Teraz już możemy używać playera do woli, a zasada jest z grubsza taka, jak przy znanym dużo wcześniej odtwarzaczu CMC. Wywołujemy we własnym programie przez X=USR (adres_procedury_usr, adres_playera, adres_muzyczki, pozycja_w_songu) - i gra muzyka! :). Kilka słów wyjaśnień:
- adres_procedury_usr - jest to adres procedurki Maroka, u nas
$8f85 (lub dziesiętnie: 33423).
- adres_playera - jest to adres procedury odgrywającej muzykę
(napisanej przez Rastera), u nas w każdym przypadku $9500
(38144).
- adres muzyczki - nazwa mówi sama za siebie. Uwaga! Standardowy
adres ($4000) jest za niski dla "Turbo Basica XL" (w przykładach
jest to $7000).
- pozycja w songu (tak jak submuzyka w CMC) - pozwala nam startować od "wybranego" miejsca. Jest to opcja wywołania - jej brak pozwoli słuchać muzyki "od samego początku".
W przypadku załączonych playerów (używamy tylko jednego, wybranego) wpisujemy po prostu: X=USR($8F85,$9500,$7000) - i muzyka gra nam od początku. Uwaga! $7000 to opcja ustawiona w przykładach. Ponadto trzeba pamiętać, że w obecnej wersji odtwarzacze RMT prawidłowo obsługują tylko muzyczki odgrywane 1 raz na ramkę. Proponuję potestować - albo wgrywając playery według receptury zawartej w opisie albo podmieniając pliki z muzyczkami na dyskietce. Jeżeli korzystamy z podanego przeze mnie programu testowego, wszystko musi się znajdować w katalogu zamapowanym jako "D:" (czyli po prostu w stacji numer jeden).
Programy tutaj. Mile widziane raportowanie błędów!
Kaz 2009-06-30 08:56:44
Brawo Marok! Teraz mamy mozliwosc normalnego wykorzystania muzyczek RMT w programach w Basicu. To przelom. Na to wiele osob czekalo, bo obecnie malo ktory muzyk chce sie bawic w CMC, wszyscy wola Raster Music Trackera. "Nadejszla wiekompomna chwila..." :)
larek 2009-06-30 12:20:34
Ładnie, ładnie! Choć ustalenie na sztywno adresów jest małą rozrzutnością, to dla bawiących się programowaniem w Basicu powinno być w zupełności wystarczające. Dobra robota!
Ja w chwili obecnej testuję sobie Eclipse + WUDSN + MADS (wspomiał o tym Mono w tym wątku Forum Atarum:
http://atarionline.pl/forum/comments.php?DiscussionID=83 )
Dziwne, że przeszło to trochę bez echa, bo testy są bardzo obiecujące! Całość tworzy zintegrowany system do edycji, kompilacji i uruchomienia programów w asemblerze, łącznie z uruchomieniem kodu na emulatorze!. Taki nowoczesny QA! Wydaje się, że jest to TO!
Wracając do tematu - korzystając z powyższego pakietu każdy chyba będzie potrafił skomilować sobie kod umieszczając go dowolnie w pamięci - wedle swoich potrzeb. Jak zapoznam się dokładnie z pakietem, to może coś na ten temat więcej napiszę.
marok 2009-06-30 13:46:14
Chcialbym chociaz zeby procedura USR nie byla przywiazana do stalego adresu (z tym przeslaniem byla tez pisana), ale problemem jest stablicowanie do zmiennej jej zawartosci a potem mozliwosc nagrania tak przygotowanej zmiennej na nosnik zewnetrzny.
Dopiero wowczas procedure bedzie mozna wykorzystac pod wbudowanym basic'iem, a przynajmniej bedzie to prostrze (nie wiem dokladnie ktora z wersji jest prawdziwa).
sikor 2009-06-30 14:18:59
marok: tą wersję procedury którą zaproponowałem też można wykorzystać pod Basiciem. Tak czy inaczej musisz wczytać player i muzyczkę, a "przywiązałem" ją na stałe, aby mniej wprawne osoby miały łatwiejszą możliwość wczytania całości. Poza tym - jest to w miarę bezpieczny adres (szósta strona odpadła po kompilacji Turbo Basica).
Wprawniejszy programista i tak sobie przekompiluje sam na własne problemy, ale dla początkujących - łopatologia jak najbardziej wskazana. A tak wiadomo, że od adresu $8F85 do końca playera ma nic nie być (choć wprawny programista kilka bajtów pomiędzy procką USR a właściwym playerem prawie zawsze znajdzie). I tak dzięki za wielką robotę ;)
larek 2009-06-30 15:42:44
Sikor, o co chodzi z 6 stroną po kompilacji w TB? Wspominasz o tym po raz kolejny i nie bardzo wiem, co jest grane :(
Czyżby TB po kompilacji nie pozwalał używać 6 strony? Dziwi mnie to, bo - tak mi się przynajmniej wydaje - pisałem już programy, które mają coś na 6 stronie i po kompilacji działały bez problemu!
sikor 2009-06-30 17:25:03
Tak, część szóstej strony zajmuje bodajże runtime oraz chyba któryś init. W niesprzyjających warunkach po kompilacji i zlinkowaniu z biblioteką potrafi to zawiesić program.
Szybki podgląd w dowolny program po kompilacji i zlinkowaniu:
$0600-$06bd DATA
$0624 INIT
$0695 RUN
Tak przynajmniej pokazuje Super Packer. Część z tego da się "zadeptać", ale niestety procka MAROKA już tam nie wchodzi. W niesprzyjających warunkach po kompilacji i zlinkowaniu (RUNTIME2.EXE) po prostu program się wykrzaczy (o ile w nieskompilowanym TB działa O.K., nie sprawdzałem jak w skompilowanym, ale bez dołączonych bibliotek).
sikor 2009-06-30 17:42:41
Hmm, wygląda na to, że to linker coś dodaje, bo sam runtime ma inne adresy niż po zlinkowaniu...
larek 2009-06-30 17:52:06
Czegoż to się człowiek na stare lata dowiaduje ;)
Tak sobie myślę, że może dlatego nie spotkałem się z tym problemem, bo raczej tworzę programy, które wczytują dane PO uruchomieniu się, a nie PRZED. Być może dlatego uniknąłem takiego konfilktu. W przypadku programów jednoplikowych (w kompilownym TB), faktycznie dane trzeba załadować na początku, bo później wczytuje się runtime, program i wszystko się uruchamia, więc na załadowanie danych nie ma już czasu...
Wychodzi na to, że taką cechę programu jednoplikowego można uznać za mniej lub bardziej, ale poważną wadę. Rozwiązaniem tego jest program wieloplikowy, który doczytuje dane już po uruchomieniu programu głównego.
miker 2009-06-30 18:58:35
Ewentualnie przenieść dane z innego miejsca na szóstą stronę, która po uruchomieniu się runtime'a, staje się na powrót dostępna. :)
larek 2009-06-30 20:06:23
tak jest :)
sikor 2009-07-01 08:52:54
Zapominacie Panowie w tym wszystkim o jednym: o ile Larek, Miker, Sikor, parę innych osób przeniesie to sobie bez problemu, o tyle początkuujący programista w Turbo Basicu ma nawet problem ze stworzeniem sobie wersji FILE programu (vide wątek o RMT Playerze na atariage), więc - jak napisałem wcześniej - dla niekumatych i początkujących napisałem "na sztywno". O ile ja assemblera nie znam, o tyle poradzę sobie z przekompilowaniem, tego na nowo. Ale wierzcie mi lub nie c- początkujący programista tego nie zrobi, bo najnormalniej w świecie nie będzie potrafił. Dla większości takich osób już dużym ułatwieniem jest to, że da się użyć całości jak przy playerze CMC, nie wnikając w kod całości (tylko wgranie danych i odpalenie całości lub części utworu).
JAC! 2009-07-26 19:56:31
Hi there,
WUDSN IDE 1.3.2 is out now and it now supports also MADS and Mac OS X. SO maybe it's interesting for you.
Have fun, Peter.
Kaz 2009-08-12 02:54:18
Jac - thanks for update info!
Grevlen 2010-12-27 06:29:20
Im using the MTMONO.PLY to play rmt music in Turbo Basic and it works great, But How do i stop it again in Turbo basic ?
A game would need to start and Stop music also..
is there anyway to stop the Music playing with the MTMONO.PLY
in Turbo Basic ?
Brawo Marok! Teraz mamy mozliwosc normalnego wykorzystania muzyczek RMT w programach w Basicu. To przelom. Na to wiele osob czekalo, bo obecnie malo ktory muzyk chce sie bawic w CMC, wszyscy wola Raster Music Trackera. "Nadejszla wiekompomna chwila..." :)
larek 2009-06-30 12:20:34
Ładnie, ładnie! Choć ustalenie na sztywno adresów jest małą rozrzutnością, to dla bawiących się programowaniem w Basicu powinno być w zupełności wystarczające. Dobra robota!
Ja w chwili obecnej testuję sobie Eclipse + WUDSN + MADS (wspomiał o tym Mono w tym wątku Forum Atarum:
http://atarionline.pl/forum/comments.php?DiscussionID=83 )
Dziwne, że przeszło to trochę bez echa, bo testy są bardzo obiecujące! Całość tworzy zintegrowany system do edycji, kompilacji i uruchomienia programów w asemblerze, łącznie z uruchomieniem kodu na emulatorze!. Taki nowoczesny QA! Wydaje się, że jest to TO!
Wracając do tematu - korzystając z powyższego pakietu każdy chyba będzie potrafił skomilować sobie kod umieszczając go dowolnie w pamięci - wedle swoich potrzeb. Jak zapoznam się dokładnie z pakietem, to może coś na ten temat więcej napiszę.
marok 2009-06-30 13:46:14
Chcialbym chociaz zeby procedura USR nie byla przywiazana do stalego adresu (z tym przeslaniem byla tez pisana), ale problemem jest stablicowanie do zmiennej jej zawartosci a potem mozliwosc nagrania tak przygotowanej zmiennej na nosnik zewnetrzny.
Dopiero wowczas procedure bedzie mozna wykorzystac pod wbudowanym basic'iem, a przynajmniej bedzie to prostrze (nie wiem dokladnie ktora z wersji jest prawdziwa).
sikor 2009-06-30 14:18:59
marok: tą wersję procedury którą zaproponowałem też można wykorzystać pod Basiciem. Tak czy inaczej musisz wczytać player i muzyczkę, a "przywiązałem" ją na stałe, aby mniej wprawne osoby miały łatwiejszą możliwość wczytania całości. Poza tym - jest to w miarę bezpieczny adres (szósta strona odpadła po kompilacji Turbo Basica).
Wprawniejszy programista i tak sobie przekompiluje sam na własne problemy, ale dla początkujących - łopatologia jak najbardziej wskazana. A tak wiadomo, że od adresu $8F85 do końca playera ma nic nie być (choć wprawny programista kilka bajtów pomiędzy procką USR a właściwym playerem prawie zawsze znajdzie). I tak dzięki za wielką robotę ;)
larek 2009-06-30 15:42:44
Sikor, o co chodzi z 6 stroną po kompilacji w TB? Wspominasz o tym po raz kolejny i nie bardzo wiem, co jest grane :(
Czyżby TB po kompilacji nie pozwalał używać 6 strony? Dziwi mnie to, bo - tak mi się przynajmniej wydaje - pisałem już programy, które mają coś na 6 stronie i po kompilacji działały bez problemu!
sikor 2009-06-30 17:25:03
Tak, część szóstej strony zajmuje bodajże runtime oraz chyba któryś init. W niesprzyjających warunkach po kompilacji i zlinkowaniu z biblioteką potrafi to zawiesić program.
Szybki podgląd w dowolny program po kompilacji i zlinkowaniu:
$0600-$06bd DATA
$0624 INIT
$0695 RUN
Tak przynajmniej pokazuje Super Packer. Część z tego da się "zadeptać", ale niestety procka MAROKA już tam nie wchodzi. W niesprzyjających warunkach po kompilacji i zlinkowaniu (RUNTIME2.EXE) po prostu program się wykrzaczy (o ile w nieskompilowanym TB działa O.K., nie sprawdzałem jak w skompilowanym, ale bez dołączonych bibliotek).
sikor 2009-06-30 17:42:41
Hmm, wygląda na to, że to linker coś dodaje, bo sam runtime ma inne adresy niż po zlinkowaniu...
larek 2009-06-30 17:52:06
Czegoż to się człowiek na stare lata dowiaduje ;)
Tak sobie myślę, że może dlatego nie spotkałem się z tym problemem, bo raczej tworzę programy, które wczytują dane PO uruchomieniu się, a nie PRZED. Być może dlatego uniknąłem takiego konfilktu. W przypadku programów jednoplikowych (w kompilownym TB), faktycznie dane trzeba załadować na początku, bo później wczytuje się runtime, program i wszystko się uruchamia, więc na załadowanie danych nie ma już czasu...
Wychodzi na to, że taką cechę programu jednoplikowego można uznać za mniej lub bardziej, ale poważną wadę. Rozwiązaniem tego jest program wieloplikowy, który doczytuje dane już po uruchomieniu programu głównego.
miker 2009-06-30 18:58:35
Ewentualnie przenieść dane z innego miejsca na szóstą stronę, która po uruchomieniu się runtime'a, staje się na powrót dostępna. :)
larek 2009-06-30 20:06:23
tak jest :)
sikor 2009-07-01 08:52:54
Zapominacie Panowie w tym wszystkim o jednym: o ile Larek, Miker, Sikor, parę innych osób przeniesie to sobie bez problemu, o tyle początkuujący programista w Turbo Basicu ma nawet problem ze stworzeniem sobie wersji FILE programu (vide wątek o RMT Playerze na atariage), więc - jak napisałem wcześniej - dla niekumatych i początkujących napisałem "na sztywno". O ile ja assemblera nie znam, o tyle poradzę sobie z przekompilowaniem, tego na nowo. Ale wierzcie mi lub nie c- początkujący programista tego nie zrobi, bo najnormalniej w świecie nie będzie potrafił. Dla większości takich osób już dużym ułatwieniem jest to, że da się użyć całości jak przy playerze CMC, nie wnikając w kod całości (tylko wgranie danych i odpalenie całości lub części utworu).
JAC! 2009-07-26 19:56:31
Hi there,
WUDSN IDE 1.3.2 is out now and it now supports also MADS and Mac OS X. SO maybe it's interesting for you.
Have fun, Peter.
Kaz 2009-08-12 02:54:18
Jac - thanks for update info!
Grevlen 2010-12-27 06:29:20
Im using the MTMONO.PLY to play rmt music in Turbo Basic and it works great, But How do i stop it again in Turbo basic ?
A game would need to start and Stop music also..
is there anyway to stop the Music playing with the MTMONO.PLY
in Turbo Basic ?