atarionline.pl Action! - co robie źle ? - 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:
       
      CommentAuthorjhusak
    • CommentTime27 Jun 2024 zmieniony
     
    Ojtam ojtam. Translatory w koło, a poza tym angielski jest fajny, warto się uczyć. Łatwo się go uczyć przez skojarzenia: I have done this = Ja mam to zrobione. :D I lecisz, jak po polsku, z drobnymi wyjątkami. Bliższy nam język, niż np. niemiecki.

    A miejsce jest jedno z głównych.
    • 2: CommentAuthortatko74
    • CommentTime16 Aug 2024 zmieniony
     
    I znowu pytanko:

    Znalazłem taki oto fajny art:

    ->link<-

    I zastanawiam się czy można jakość obejść/pominąć procedure przeszukiwania pamięci za początkiem podprogramu.
    Z góry ustalić "bezpieczny" adres i zastosować coś jak np niżej:

    PROC Graj=$708 () ; oczywiście addr z czapy
    .
    .
    RETURN


    Tylko nie wiem jak to zrobić, jak określić taki adres przed kompilacją.
    • 3: CommentAuthorbob_er
    • CommentTime16 Aug 2024
     
    Ogólnie pamięć XE ma kilka (w miarę) bezpiecznych obszarów, np. strona 6 (start od adresu $0600), lub coś tuż przed pamięcią ekranu (i DL).
    Jednakże nie wiem, jak w Action! zrobić tak, by dana funkcja została skompilowana pod określony adres np. na ową 6tą stronę.
    Więc wg mojej wiedzy (być może błędnej), musiałbyś wybrane funkcje kompilować osobno, ustawiając inny adres kompilacji (lub np. w ASM je napisać), a potem w swoim programie głównym już do nich się odwoływać.
    • 4:
       
      CommentAuthorjhusak
    • CommentTime19 Aug 2024 zmieniony
     
    Daje się to zrobić. Jednak nie próbowałem 2 x ustawiać set 14=adres i set $491=adres. Poza tym jest jeszcze myk z gwiazdką a potem pisanie ciała funkcji. Trzeba obadać jak to dokładnie działa.

    proc a=*()
    printe("hello")
    return

    proc a=$600()
    printe("hello600")
    return


    O ile pierwsze zadziała (i nie będzie jmp do funkcji, która jest w następnym rozkazie na początku), to drugie skompiluje pod bieżącym adresem, ale wywołanie a() będzie skakać pod $600, czyli nie zadziała.

    A poniższe działa, ale po =* trzeba dodawać stricte [$60] zamiast return, bo jeśli damy return, to generuje kod $60 pod $1000 zamiast dolepić pod $6xx. Dziwne.

    SET 14=$600
    SET $491=$600 ; te 2 sety ustawiają adres kompilacji

    PROC A=*( ) ; a będzie pod adresem $600 i można pominąć =*, wtedy będzie dodatkowy jmp na początku.
    PRINTE("HELO")
    [$60] ; to wygeneruje rts na końcu
    ; RETURN ; a to by wygenerowało ZA poniższym setem, czyli pod $1000

    SET 14=$1000
    SET $491=$1000 ; ustawiamy adres kompilacji na $1000

    PROC B=*() ; i tu już normalnie (ale oszczędzamy jmp do następnego rozkazu)
    A() ; przykładowo
    RETURN ; no i tu return jest generowane prawidłowo.



    Teraz już wiem, dlaczego Tdc wpisywał [$60] zamiast return zawsze. To żeby zaoszczędzić 3 bajty (brak jmp) na każdej procedurze. A nie dlatego, żeby skrócić kod źródłowy.
    • 5: CommentAuthortatko74
    • CommentTime19 Aug 2024
     
    @jhusak - możesz to obkomentować - bo nie wiem co tam zasadniczo zachodzi :/ Jakieś czary XD
    • 6:
       
      CommentAuthorjhusak
    • CommentTime19 Aug 2024 zmieniony
     
    Generalnie pod emulatorem disassembler w monitorze twoim przyjacielem :)

    A tak naprawdę to pytasz o konstrukcję wywołania podprogramu z określonego adresu, który np. napisałeś w asemblerze (albo jest to procka RMT)

    Wtedy:

    proc graj=$600(byte a, x, y) ; w a,x,y przesyłasz parametry, które wpiszą się do akumulatora, rejestru x i y)
    • 7: CommentAuthortatko74
    • CommentTime6 Sep 2024
     
    Witam ponownie
    Opanowałem kwestie adresu procedury na skróty, za radą jhusaka skorzystałem z debugera w altirze, poszukałem gdzie jest tablica procedur, wyliczyłem adres i działa :) oczywiście przy każdej zmianie muszę pamiętać by po kompilacji znów sprawdzić gdzie wywaliło te procedure i ten adres zmienić, no ale nie ma "letko" :)

    Procedura działa w przerwaniu, ale jest ale :/

    Ponieważ procedura korzysta z moveblock i sam program też z tego korzysta, zdarzają się przypadki gdy - takie mam wrażenie - dokładny czas wykonania ich się pokryje i bloki są przenoszone albo w złe miejsce albo z złą zawartością - tak jak by parametry się mieszały, między tym co w głównym wątku a tym w przerwaniach :/

    Można jakoś wymusić pauzowanie głównego wątku na czas wykonania tego z przerwania ?
    • 8:
       
      CommentAuthorjhusak
    • CommentTime6 Sep 2024 zmieniony
     
    Problem masz z czym innym. (przerwanie właśnie tak działa, jak chcesz, czyli zawiesza wątek główny i wykonuje prockę przerwania)

    Problem dotyczy tego, że na przerwaniu psujesz rejestry action.
    Do zapamiętania ich i odzyskania w przerwaniu służy para makr, zdefiniowanych gdzieś w bibliotekach (tych z dyskietki) Action!.

    W skrócie polega na zapamiętaniu rejestrów oraz szeregu bajtów ze strony zerowej na stosie (SAVETEMPS i GETTEMPS)

    O, tutaj:

    ->link<-
    • 9: CommentAuthortatko74
    • CommentTime6 Sep 2024
     
    O jak zwykle nieoceniony jhusak ;)
    Chyba faktycznie działa :)
    • 10:
       
      CommentAuthorjhusak
    • CommentTime6 Sep 2024
     
    No i nie wiem, czy zaakcentowałem. 6502 jest procesorem jednokorowym/jednordzeniowym, wykonuje jedną czynność na raz, nawet, jak to wygląda inaczej, a przełączanie kontekstu zajmuje czas i cykle.
    • 11: CommentAuthortatko74
    • CommentTime20 Sep 2024
     
    Można wymusić Fire joya?
    W sensie wywołać zdarzenie fire tak by procedura sprawdzająca stan joya to odczytała?
    Mam pętelkę która coś tam sobie robi czekając na reakcje użytkownika (joystick) , i procedure w przerwaniach która mogła by co jakiś czas wywoływać zdarzenie fire - tylko nie wiem jak... jakieś poke ?
    • 12:
       
      CommentAuthorPecus
    • CommentTime20 Sep 2024 zmieniony
     
    Jeśli Twoja procedura "na przerwaniach" chodzi na VBI to najprościej będzie zapisać odpowiednią wartość w rejestrze cieniu TRIG0S ($0284).
    Systemowa procedura VBI przepisze tam wartość z rejestru sprzętowego, a Twoja działająca na zakończeniu systemowej zmieni tę wartość na oczekiwaną przez Ciebie.

    Oczywiście to zadziała tylko wtedy, jeśli w głównym programie sprawdzasz stan przycisku czytając ten rejestr cień.
    • 13: CommentAuthortatko74
    • CommentTime20 Sep 2024 zmieniony
     
    Procedura używa przerwania TIMER2
    I próbowałem "pokować" tam ten rejestr na 0 - ale nie działa.
    To kwestia doboru przerwań ?
    Stan czytam "STrig(nr portu)"
    • 14: CommentAuthortatko74
    • CommentTime20 Sep 2024
     
    Ok - mam, działa - mój błąd :/