atarionline.pl Player RMT - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1:
       
      CommentAuthorxeen
    • CommentTime14 Oct 2010 zmieniony
     
    odgrzewam temat zupełnie banalnym pytaniem.
    w jaki sposób zatrzymać już odpaloną muzyczkę w programie?

    edit:
    nie było pytania - wystarczy jeden argument:) sorry
    • 2:
       
      CommentAuthorbooker
    • CommentTime15 Oct 2010
     
    Fśyśko est w doku ;)
    • 3:
       
      CommentAuthorxeen
    • CommentTime9 Nov 2010
     
    znowu odgrzewam temat, znowu absolutnie banalną dla wtajemniczonych prośbą o pomoc.
    potrzebuję przekompilować playerek dla 4 kanałowych plików monofonicznych przygotowany przez maroka do wykorzystania w tbxl.
    Zależy mi na tym aby adres USR zaczynał się od $a400, a adres playera odpowiednio za usr ($a500?)

    pomożecie? lamersko nie wiem nawet jak do tego się zabrać
    dzięki
    • 4: CommentAuthormarok
    • CommentTime10 Nov 2010
     
    xeen: niewiele już dziś pamiętam

    Pamiętam że procedura USR ma zawsze jednakową postać po kompilacji - niezalażnie od wybranego adresu (oryginalnie $600 ale skompiluje tak samo jakby miało to być $a400).

    Ta procedura USR nie jest playerem a rodzajem nakładki która pozwala na działanie oryginalnego playera RMT w środowisku basica. Konkretnie to chodzi o dzielenie się dostępem do tych samych obszarów strony zerowej z których korzysta zarówno player RMT (na czas przerwania) jak i basic.

    Jeśli przenieść ją do zmiennej to można nie znając nawet konkretnego adresu (tak mi się wydaje) z niej korzystać poprzez wywołanie funkcji USR.

    Można ją przenieść do programu jako zmienną poprzez procedurę w basicu którą podawałem, ale chyba są i inne sposoby (to już inni muszą pomóc).

    Oryginalny player RMT trzeba za to skompilować już pod konkretny adres. Zakładając że chcesz go powyżej adresu $a400, to etykieta PLAYER musi być równa adresowi $a800 (zawsze musi to być granica strony i trzeba pozostawić miejsce na dane które kompilują się przed nominalnym adresem playera, dla muzyczek w mono pierwszy wolny bajt przed playerem jest mniejszy o $320 bajty od adresu wyznaczonego dla etykiety PLAYER; w Twoim wypadku pierwszy bajt playera rozpoczynałby się od adresu $a4e0).

    Na teraz tyle. Z pewnością może to być niewystarczające co napisałem.
    • 5:
       
      CommentAuthorxeen
    • CommentTime10 Nov 2010
     
    wiem że to głupie pytanie, ale gdzie są źródła na których można polegać i które można kompilować, próbować?
    • 6: CommentAuthormarok
    • CommentTime10 Nov 2010 zmieniony
     
    W komentarzu #20. jest jak mi się wydaje właściwe źródło procedury USR (trzeba tylko poprawić "tis equ 205" na "tis equ 206".

    Co do playera RMT to jest w pakiecie z tym że należy odnaleźć i poprawić zapis: " org 206 ;bylo 203
    p_tis"

    Player RMT powinien mieć skonfigurowany pod konkretną muzyczkę plik pomocniczy rmt_feat.a65 (File/Export As...).
    Trzeba skopiować zawartość tekstową z okienka i zapisać pod tą właśnie nazwę. Później już można kompilować właściwy plyer RMT.
    • 7:
       
      CommentAuthorxeen
    • CommentTime10 Nov 2010
     
    dziękuję za pomoc, chyba (?) się udało i gra
    testuję...
    • 8:
       
      CommentAuthorxeen
    • CommentTime11 Nov 2010 zmieniony
     
    napotkałem na kolejny problem z playerem.
    w takiej oto lokalizacji jest opisana procedurka PMG do wykorzystania:

    ->link<-

    procedura jest odpowidzialna za wyświetlanie grafiki graczy i pocisków i ma sygnaturę:
    A = USR(PMMOVE,PLAYER#,SHAPE,SIZE,X,Y)
    PMMOVE - adres procki - sama procka jest załadowana do tablicy znaków, player - numer gracza, shape - adres kształtu (u mnie adres tabliy znaków), size (wysokośc w pionie), x i y wiadomo

    problem polega na tym, że sama procka gryzie się z playerem opisanym w tym wątku i zupełnie nie wiem dlaczego
    z tego co widzę procka bardzo szybko kopiuje kształt ducha do obszaru pamięci na duchy i tego ducha wyświetla.
    po uruchomieniu muzyczki - jest git, ale wywołanie procki kaszani wszystko (np kształt duchów).
    jestem przekonany (albo zwariowałem), że procedura USR maroka, player i muza jest w obszarze pamięci innym niż stuff dotyczący PMG.
    sprawa jest o tyle dziwna, że wywołanie procki PMG i muzy działa (taka kolejność). Nie działa wywołanie muzy (wiadomo ładuję na początku) a potem samej procki.
    Jaka może być przyczyna takiego zachowania?
    z góry dziękuję za pomoc.
    • 9:
       
      CommentAuthorjhusak
    • CommentTime11 Nov 2010
     
    Na 100% używają tych samych adresów na stronie 0.
    • 10:
       
      CommentAuthorxeen
    • CommentTime11 Nov 2010
     
    z tego co mono pisał, na stronie zerowej można wykorzystać jakieś różne adresy (np bufor drukarki) itp - komentarz#19. Czy przepisanie procki z komentarza #20 jest realne i możliwe tak, aby korzystała z nieco innych adresów na stronie zerowej. Co trzeba ewentualnie tam zmienić? (jestem noga z asma).
    A zależy mi na wykorzystaniu pmtoolkita i playera razem pod tbxl.

    znowu z góry dziękuję za pomoc, nawet jeśli to co powyżej napisałem nie ma za bardzo sensu:)
    marok wspomniał o współdzieleniu adresów na czas przerwania, boję się że pmtoolkit robi coś podobnego i mamy trzech graczy do jednego zasobu, przez co od strony samej procki maroka jakiekolwiek ruchy niewiele pomogą.
    czy dobrze to rozumiem?
    • 11: CommentAuthormarok
    • CommentTime11 Nov 2010 zmieniony
     
    "sprawa jest o tyle dziwna, że wywołanie procki PMG i muzy działa (taka kolejność). Nie działa wywołanie muzy (wiadomo ładuję na początku) a potem samej procki."

    Najprawdopobniej więc procka PMG ładuje pod wektor 2. fazy przerwania vblank ($224-$225) czyli ten sam z którego korzysta procka do obsługi playera RMT, swój adres a dotychczasową zawartość ignoruje (zakładając że jest tam oryginalna zawartość do procedury w romie).

    Żeby to zmienić należałoby zaingerować w prockę do PMG.

    Albo raczej to inny problem, bo chyba jednak procka PMG nie musi korzystać z przerwań.
    • 12: CommentAuthormarok
    • CommentTime12 Nov 2010
     
    Mam sugestię aby procedurę z komentarza #20 uzupełnić na samym końcu o 19. bajtów (mogą być zera).

    Niekoniecznie to pomoże ale warto sprawdzić.
    • 13:
       
      CommentAuthorxeen
    • CommentTime12 Nov 2010
     
    oczywiście że sprawdzę, mimo że nie rozumiem
    znowu lamerskie pytanie:
    tak po prostu zera w kodzie + rekompilacja?
    jaka ma być długość oczekiwana?
    • 14: CommentAuthormarok
    • CommentTime12 Nov 2010
     
    Może być w kodzie przy kompilacji a można już po dodać na końcu odpowiednią liczbę zer.

    Jeśli przy kompilacji to ostatnia linijka kodu powinna wyglądać tak:
    :19 dta b(0)
    • 15:
       
      CommentAuthorxeen
    • CommentTime12 Nov 2010
     
    niestety, bez zmian :((

    czy istnieje jakiś skrypcik do zamiany kodu w postaci linii data (liczby, w sensie) do mnemoników asma?
    ta procka nie jest taka wielka, mieści się w zmiennej o długości 202 bajty, a procka pomocnicza to zaledwie 48 bajtów.
    po wywołaniu procki pomocniczej (bardzo szybko wypełnia zerami daną ilość stron pamięci od określonego adresu)
    muza też nie trybi. może źle szukam....
    • 16:
       
      CommentAuthorKaz
    • CommentTime16 Nov 2010
     
    Z tego co wiem to problem juz rozwiazany, uwazam, ze warto sie podzielic rozwiazaniem.