atarionline.pl Scramble in Action! - 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: CommentAuthorzbyti
    • CommentTime15 May 2020
     
    No to już @Kaz się nie wykpisz tej kolorystyki, poszło:

    git status

    On branch master
    Your branch is up to date with 'origin/master'.

    Changes not staged for commit:

    modified: src/ANTIC.ACT
    modified: src/MAIN.ACT


    ~/a8-action-scramble$ git commit -am "new look proposal by Kaz"

    [master 7f80966] new look proposal by Kaz
    2 files changed, 9 insertions(+), 10 deletions(-)

    ~/a8-action-scramble$ git push

    Counting objects: 5, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (5/5), done.
    Writing objects: 100% (5/5), 513 bytes | 513.00 KiB/s, done.
    Total 5 (delta 4), reused 0 (delta 0)
    remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
    To ->link<-
    d5bea53..7f80966 master -> master
    • 2:
       
      CommentAuthorpirx
    • CommentTime15 May 2020
     
    mozesz te bary zmiękczyć takim trykersem
    • 3: CommentAuthorzbyti
    • CommentTime16 May 2020 zmieniony
     
    @pirx o! świetny pomysł, dzięki! zaraz zakoduję! :]

    EDIT: zapytałem chłopaków na live ile na ten bajer może pójść CPU. Jeżeli to przełamane będzie jako druga linia a nie przedostatnia w wierszu to mogę sobie chyba na takie szastanie cyklami pozwolić ;)

    BYTE ARRAY
    DL=[
    $70 ; EMPTY ROW
    $42 $97 CBMSB ; FIRST TEXT ROW (GR.0)
    $D2 0 0 ; STARTSCREEN (GR.0) WITH HSCROL AND DLI
    $12 $92 $12 $92 $12 $92 $12 $92 $12 $92 $12 $12
    $12 $12 $12 $12 $12 $92 $92 $92 $92 $92 $92 $92 2
    $70 ; EMPTY ROW
    $41 $00 CBMSB ; JUMP TO BEGINNING OF DL
    ],
    DLIA=[
    PHA
    LDAI $8A WSYNC
    STA $18 $D0 CLC ADCI 2 WSYNC
    STA $18 $D0 LDA $28 CBMSB WSYNC
    STA $18 $D0 DEC $28 CBMSB DEC $28 CBMSB
    CMPI $80 BNE $17 LDAI $66 STA 0 2 LDAI CBMSB STA 1 2 LDAI $8A STA $28 CBMSB LDAI 0 WSYNC
    STA $18 $D0
    PLA RTI
    ],
    DLIB=[
    PHA
    LDAI $E WSYNC
    STA $17 $D0 DEC $68 CBMSB DEC $68 CBMSB
    CMPI $2 BNE $17 LDAI $26 STA 0 2 LDAI CBMSB STA 1 2 LDAI $E STA $68 CBMSB LDAI $E WSYNC
    STA $17 $D0
    PLA RTI
    ]


    git commit -am "new look proposal by Pirx"
    [master 6d58e40] new look proposal by Pirx
    3 files changed, 14 insertions(+), 8 deletions(-)

    Efekt zmian na zrzucie.
    • 4: CommentAuthorzbyti
    • CommentTime16 May 2020 zmieniony
     
    NOTKA

    Dyrektywa SET $E może być użyta w programie wielokrotnie przez co mamy jakąś kontrolę na etapie kompilacji gdzie mają być położone wybrane składowe części programu.
    • 5:
       
      CommentAuthorMq
    • CommentTime16 May 2020
     
    zapytałem chłopaków na live ile na ten bajer może pójść CPU. Jeżeli to przełamane będzie jako druga linia a nie przedostatnia w wierszu to mogę sobie chyba na takie szastanie cyklami pozwolić ;)


    Od jakiegoś czasu pracuję sobie w wolnych chwilach nad własnym warsztatem, którego celem jest również zrobienie gry:-)
    Ponieważ w moim projekcie również akurat występuje niebo i również bawię się DLI, to zbiegiem okoliczności jakiś miesiąc temu wpadłem niezależnie na niemal identyczny pomysł tego zmiękczenia barów:-).
    Z resztą pewnie on się nasuwa wielu osobom, i zapewne wielokrotnie był wykorzystywany, ja w swoim przypadku bawiąc się DLI i robiąc niebo pomyślałem jednocześnie o gradiencie i ditheringu, co w oczywisty sposób zaowocowało takim pomysłem.

    Ale mniejsza o to. Chciałem o czymś innym: otóż akurat ja bawię się w Mad Pascalu w połączeniu z assemblerem, ale to też nieistotne, chodzi mi o to, że dokładając kolejne przerwania i kolejne zmiany w liniach natknąłem się dokładnie na ten problem, który masz tu na myśli mówiąc o przełamaniu jako np. druga linia, a nie dalej. Żeby w trybie znakowym zmienić kolor przykładowo w ostatniej lub przedostatniej linii danego wiersza znakowego, trzeba wykonać kilka wsync-ów, żeby odczekać na tą linię. Faktycznie zauważyłem, że jak się naładuje takich wsync-ów kilka, to program zaczyna się mulić. Z tego co logicznie sobie wydumałem, wynikało by, że wsync powoduje całkowite zatrzymanie robienia czegokolwiek, co skutkuje całkowitym zmarnowaniem wszystkich cykli całych linii za każdym wsyncem. Jak załadujemy wsync-ami wszystkie linie ekranu, to praktycznie komputer może działać tylko w trakcie powrotu plamki czyli w czasie vblank.
    Z tego powodu wydumałem sobie, że w przerwaniach DLI najlepiej jest robić cokolwiek zawsze od początku nowej linii znakowej i tak projektować program, żeby w miarę możliwości unikać używania wsync.

    Pytanie jest takie: czy dobrze rozumuję i czy dokładnie tak działa wsync?
    I pytanie drugie, czy jest jakaś inna metoda policzenia linii i zsynchronizowania się np. z ostatnią linią danego wiersza znakowego bez wykorzystania tych wszystkich wsync po drodze? Podejrzewam, że nie, bo przerwanie DLI może występować tylko w liniach zmiany trybu, czyli przy pełnym znaku (w sensie pierwszej linii wiersza znakowego), ale może jest jakaś metoda na wywołanie tego lub innego przerwania przy np. dowolnej innej linii ekranu?
    • 6: CommentAuthorzbyti
    • CommentTime16 May 2020 zmieniony
     
    @Mq na podstawie wiedzy przekazanej na warsztatach przez @tdc i na afterkach przez @mono mogę tylko powiedzieć:

    Twoje wnioski na temat DLI i WSYNC są słuszne.

    Jak nie chcesz używać DLI ale trafiać w linię i robić WSYNC najpóźniej jak się da to jedyną znaną mi metodą jest użycie:

    VCOUNT $D40B

    Najbardziej hardcorowe podejście to cyklowanie całości kodu i rezygnacja z przerwań w ogóle.

    Może ktoś bardziej kompetentny dorzuci jeszcze trochę wiedzy na ten temat w tym wątku.

    Tyle ode mnie :]
    • 7:
       
      CommentAuthorMq
    • CommentTime16 May 2020
     
    Dzięki za hint. Nie bawiłem się jeszcze vcount - muszę z tym poeksperymentować. W zasadzie w wypadku gdy nie potrzebujemy precyzji (np. zmieniamy jakiś kolor, ale przez kilka linii nie jest on używany), to może warto skorzystać z tego licznika i nawet w głównym kodzie walnąć jakieś porównanie z vcount i coś tam sobie w oparciu o to zmienić? Muszę spróbować jak będę miał chwilę czasu i następną sesję zabawową z Atari:-)
    • 8: CommentAuthorzbyti
    • CommentTime16 May 2020 zmieniony
     
    TUTORIAL 3.0: Action! to XEX

    Potrzebne mi procedury z RUNTIME skopiowałem sobie do TOOLS. Jak ktoś używa procedur bibliotecznych to niech zrobi tak jak ja albo dołącza RUNTIME.

    ---------------------------------------------------------------------------

    Monitor Action!

    1. C "H6:MAIN.ACT"

    2. ? MAIN zwróci nam adres procedury, który zapamiętujemy (u mnie jest to ostatni procedura, czyli startowa)



    Atari800

    1. Wejście do monitora F8

    2. Wczytanie zasobów w przewidziane przez nas miejsce

    read /home/zbyti/Atari8HDD/SCRAMBLE.FNT 2800 400

    4. Zgranie pamięci do XEX

    write XEX 1000 2bff 1af2

    gdzie: 1af2 to zapamiętany wcześniej adres startowy, $1000 to CODEBASE, 2bff to koniec mojego zestawu znaków a tym samym zasobów i używanej przeze mnie pamięci, która musi zostać zgrana.

    ---------------------------------------------------------------------------

    Całość można spakować za pomocą Exomizera.

    exomizer sfx sys -n -t 168 -o SCRAMBLE.XEX memdump.dat

    • 9:
       
      CommentAuthorDracon
    • CommentTime16 May 2020
     
    Zbyti, możesz zapodać tutorial na używanie powyższego debuggera?
    • 10: CommentAuthorzbyti
    • CommentTime16 May 2020 zmieniony
     
    @Dracon niestety, dopiero się go uczę i poza odpaleniem niewiele w nim potrafię.

    ---------------------------------------------------------------------------

    Action! pod lupą

    Na podstawie obserwacji pacy Scramble w debuggerze wnoszę, że jak się nie korzysta z RUNTIME to można o wiele więcej wygospodarować dla siebie na stronie zerowej.

    Pracują tylko komórki ręcznie użyte przeze mnie i te wykorzystywane przez PEEK/POKE, całkiem sporo wydaje się leżeć przy takim podejściu odłogiem :]
    • 11: CommentAuthorpaw
    • CommentTime16 May 2020
     
    @Zbyti, strasznie podoba się to jak podchodzisz do zdobywania wiedzy i staram się śledzić twoje postępy, bo czasem sposób dochodzenia do rozwiązania daje dużo więcej  niż oglądanie gotowego produktu.
    I  jeżeli do porównań przydałaby się wersja napisana bezpośrednio w asemblerze to mogę spróbować ją stworzyć. 
    • 12: CommentAuthorzbyti
    • CommentTime16 May 2020 zmieniony
     
    @paw dzięki za miłe słowa a wersja w ASM mile widziana, więc działaj! :]
    • 13: CommentAuthorpaw
    • CommentTime17 May 2020
     
    Działam już od pewnego czasu,
    deklarację złożyłem jak uznałem że uda mi się odwzorować choć obecny stan programu. I z grubsza to się udało.
    Niektórych rozwiązań nie rozumiem, część zrobiłbym zupełnie inaczej - niekoniecznie lepiej, więc na razie nic nie zmieniam tylko powielam.
    Kody źródłowe udostępnię jak tylko uporam się z github-em.
    • 14: CommentAuthorMADRAFi
    • CommentTime17 May 2020
     
    Fajnie. bedzie ciekawie :)
    Ja nadganiam za zbytim :)
    • 15: CommentAuthorzbyti
    • CommentTime17 May 2020 zmieniony
     
    @paw odpaliłem, obejrzałem pod debuggerem - super!

    Fajnie, że dołączyłeś do Scramblujących ;)

    Czekam na GitHub :]
    • 16: CommentAuthorzbyti
    • CommentTime17 May 2020 zmieniony
     
    Co prawda swojego kodu nie optymalizowałem jeszcze ale z drugiej strony nie ma tam wielu zbędnych rzeczy, więc porównanie wydaje mi się na miejscu :]

    Kod @paw w ASM bez zestawu znaków: $2B1.
    Kod @zbyti w Action! bez zestawu znaków: $B53.

    Co tylko potwierdza rozwlekłość generowanego przez Action! kodu, który jest ~4x większy od analogicznego w ASM.

    Może jakbym mocno pokombinował to zszedłbym do kodu 3,5x mniejszego ;)

    @paw dobra robota! Chociażby po wielkości kodu widać, że to przemyślana i Twoja autorska robota :]
    • 17: CommentAuthorzbyti
    • CommentTime17 May 2020 zmieniony
     
    @paw a może to ja coś podpatrzę? ;)
    • 18: CommentAuthorpaw
    • CommentTime17 May 2020
     
    Na github-a trzeba poczekać bo "Your account has been flagged.", dla niecierpliwych źródła w załączeniu.

    Nie czuję się autorem tego kodu,
    bardziej białkowym kompilatorem bo linijka po linijce przepisywałem twój kod w action.
    Tylko wstawki w asm (dli) zrobiłem "po swojemu".
    • 19: CommentAuthorzbyti
    • CommentTime17 May 2020
     
    @paw tak zauważyłem, że zamiast DLI który sam przelicza kolory zrobiłeś sobie tablicę :]

    Tablica zazwyczaj jest szybsza ale moja metoda ma przynajmniej jedną zaletę w obecnej sytuacji:

    - mogę dać dowolny kolor bazowy na start i gradient się sam zrobi, ty musiałbyś uzupełnić całą tablicę.

    Tak czy inaczej pokazałeś wyższość ASM na polu użycia pamięci co mi się niesamowicie podoba! :]
    • 20:
       
      CommentAuthorKaz
    • CommentTime17 May 2020
     

    Paw:

    (...) białkowym kompilatorem


    Dobre, podoba mi się to sformułowanie :D

    Mq:

    zbiegiem okoliczności jakiś miesiąc temu wpadłem niezależnie na niemal identyczny pomysł tego zmiękczenia barów:-).
    Z resztą pewnie on się nasuwa wielu osobom, i zapewne wielokrotnie był wykorzystywany, ja w swoim przypadku bawiąc się DLI i robiąc niebo pomyślałem jednocześnie o gradiencie i ditheringu, co w oczywisty sposób zaowocowało takim pomysłem.


    Tak, to prawda, ten gradient jest akurat najprostszy i dobrze wygląda, gdy bary są wąskie (jak na ekranie tytułowym "Alberta"). Gdy bary są szersze, warto pomyśleć o rozszerzeniu tego pomysłu, a jest wiele sposobów "rozmiękczania" tych kolorów. Aby podpatrzeć różne rozwiązania warto przejrzeć obrazki G2F, szczególnie Rockyego (na warsztatach G2F było o obrazku z balonami, gdzie jest właśnie taki ciekawy gradient), ale nie tylko.

    Na stronie G2F jest trochę tych obrazków:

    ->link<-
    • 21: CommentAuthorpaw
    • CommentTime17 May 2020
     
    zaktualizowałem do obecnego stanu,
    dli już też jest bardziej "po twojemu"

    a staram się od początku minimalizować użycie pamięci bo się boleśnie przekonałem, że pisanie na Atari bardziej rozbudowanych programów bardzo szybko zmienia się w walkę o zwolnienie choć kilku bajtów pamięci ...
    • 22: CommentAuthorzbyti
    • CommentTime17 May 2020 zmieniony
     
    @paw to skoro dociągnąłeś swój kod do obecnego stanu mojego to nie mam wyjścia muszę coś w moim dokodować nowego :D

    Bardzo mi się podobają Twoje źródła, znając logikę programu łatwo mi się to czyta i mogę się uczyć dzięki temu ASM od Ciebie :]

    EDIT: to jeszcze podrzucę Twoją wersję w postaci XEX

    Nawet "zrobiłem" z Twojej i mojej wersji wersję Arcade na "dwa telewizory" ;)

    Jakby skomunikować dwie Atarki po jakimś kablu to można by coś takiego zrobić naprawdę :D
    • 23: CommentAuthorzbyti
    • CommentTime17 May 2020 zmieniony
     
    Kolejna Action! sztuczka, która pozwala mi kompilować program z relokacją zasobów i zgrywać XEX z poziomu monitora za pomocą W "H1:GAME.XEX" bez potrzeby późniejszego dogrywania czegokolwiek.

    Słowem, kompilujesz i masz od razu gotowca! Można moje tutoriale 1.0, 2.0 i 3.0 wyrzucić do kosza :]

    A tak na poważnie Tutorial 3.0 przyda się tylko jeżeli będziemy chcieli wrzucać zasoby w miejsce zajęte podczas kompilacji przez cartridge Action! lub ROM.

    Stworzyłem pliki ASSETS.ACT a w środku:

    BYTE ARRAY
    SET $E=CHARSET
    FONTS=[...]

    Taka konstrukcja pozwala mi umieszczać fonty pod adresem zadeklarowanym w DEFINE pod kluczem CHARSET.

    Wszystko dzięki ponownemu użyciu dyrektywy SET $E.

    Oczywiście wymagało to przygotowania SCRAMBLE.FNT w formacie blokowym co w praktyce oznaczało dodanie $ przed każdym bajtem.

    Osiągnąłem to co w ASM i innych współczesnych cross-compilatorach jest naturalne: relokację kodu.

    Bez żalu pożegnałem:

    ;---------------------------------------------------------------
    ; LOAD (OR SAVE) BINARY DATA TO THE INDICATED ADDRESS
    ; M=4 LOAD, M=8 SAVE
    ;---------------------------------------------------------------
    PROC LOAD(CARD FILE,STARTADDR,NBYTES BYTE M)
    CLOSE(2) OPEN(2,FILE,M,128)
    IF M=4 THEN POKE($362,7)
    ELSE POKE($362,11) FI
    POKEC($364,STARTADDR) POKEC($368,NBYTES)
    [$A2$20$20$56$E4$85$A3] CLOSE(2)
    RETURN
  1.  
    na drugim wątku, podzieliłem się narzędziem do przygotowania plików pod powyższą`metodę Zbytiego` ->link<-
    • 25: CommentAuthorzbyti
    • CommentTime18 May 2020 zmieniony
     
    @mkolodziejski dziękuję, pozwoliłem sobie wrzucić to narzędzie do folderu 'misc' w moim projekcie.

    ---------------------------------------------------------------------------

    Dorzuciłem sobie w kodzie:

    DEFINE
    RASTERBARON="$A9$E$8D$0A$D4$8D$1A$D0",
    RASTERBAROFF="$A9$0$8D$1A$D0"

    Procedura rysująca teren jest wywoływana co 4-tą ramkę (stąd mruganie) i na ten moment nie zajmuje wiele czasu procesora :]
    • 26: CommentAuthorMADRAFi
    • CommentTime18 May 2020 zmieniony
     
    a staram się od początku minimalizować użycie pamięci bo się boleśnie przekonałem, że pisanie na Atari bardziej rozbudowanych programów bardzo szybko zmienia się w walkę o zwolnienie choć kilku bajtów pamięci ...

    Oj tak.
    Szczegolnie jak piszesz przy uzyciu jezyka wyzszego poziomu.
    • 27: CommentAuthorzbyti
    • CommentTime18 May 2020 zmieniony
     
    Strona zerowa używana przez edytor Action! Wydaje się, że poza $A0-$AF mogę użyć pozostałe.

    ;----------------
    ; Page Zero defs
    ;----------------
    ; Alloc/Free defs, also used by compiler
    AFBASE = $80
    AFLAST = $82
    AFCUR = $84
    AFSIZE = $86
    AFBEST = $88
    AFBSZE = $8A
    ;
    SP = $8C
    CHOFF = $8D
    LNUM = $8E
    CURPROC = $8E ; 2 bytes
    DIRTY = $8F
    TOP = $90 ; -> top line
    BOT = $92 ; -> bottom line
    CUR = $94 ; -> current line
    X = $96 ; don't use in comp.
    Y = $97 ; don't use in comp.
    NLINES = $98
    CHAN = $98 ; current input file
    YTOP = $99
    INDENT = $9A
    BUF = $9B ; -> edit buf
    INSERT = $9D ; insert/replace flag
    DELNXT = $9E ; ->, USED BY LEX
    ;
    ARGS = $A0
    ARG0 = $A0
    ARG1 = $A1
    ARG2 = $A2
    ARG3 = $A3
    ARG4 = $A4
    ARG5 = $A5
    ARG6 = $A6
    ARG7 = $A7
    ARG8 = $A8
    ARG9 = $A9
    ARG10 = $AA
    ARG11 = $AB
    ARG12 = $AC
    ARG13 = $AD
    ARG14 = $AE
    ARG15 = $AF
    ;
    DIRTYF = $C3
    ;

    ->link<-
    • 28: CommentAuthorzbyti
    • CommentTime18 May 2020 zmieniony
     
    Walka z RND na A8 to nierówna walka :D

    Poniższe to najlepsze na co mnie aktualnie stać by wyglądało to na ekranie w miarę sensownie, do tego nie wykonuje się jakoś mega długo:

    PROC DRAWSHIP()
    BYTE SHIPTYPE

    SHIPTYPE=RANDOM&30
    IF SHIPTYPE>8 THEN RET FI
    ROCKETBODY=SHIPSTABLE(SHIPTYPE)
    ROCKETHEAD=SHIPSTABLE(SHIPTYPE+1)
    RET

    Może na końcu prac skorzystam z wiedzy zawartej w artykule jaki zalinkował kiedyś @tebe ->link<-

    Nawiązując do liczb Mersenne’a którymi epatuje @tdc na warsztatach to chodzi o to by wynik uzyskany z RANDOM maskować zawsze: %1, %11, %111, %1111 itd. jeżeli interesują nas liczby z jakiegoś zakresu.

    Tą metodą można też łatwo uzyskać liczby parzyste gasząc w masce pierwszy bit.
    • 29:
       
      CommentAuthorCOR/ira4
    • CommentTime18 May 2020
     
    @zbyti
    Gratuluje kodowania własnej gry!
    gdzie dzieje się akcja tej gry ?
    Lecimy nad planetą ?
    tak pomyślałem że mógłbyś umieścić "zakopane" w ziemi ufa,może jakiegoś szaraczka,to były by takie punkty nawigacyjne wprowadzające nie tylko urozmaicenie wizualne,ale stanowiące punkt odniesienia dla gracza-"stary do tej zakopanej czachy obcego doleciałem" ;),pomyślałem też że na koniec levelu można by zrobić bazę -dolatujemy do dużej fortecy która atakuje nas rakietami które musimy omijać-bazy powinny być różne na poszczególnych etapach gry.
    • 30: CommentAuthorzbyti
    • CommentTime18 May 2020 zmieniony
     
    @IRATA4 gra jak nazwa wątku wskazuje bazuje na klasyku z arcade.

    Inspirowała mnie konkretna wersja z Vectrex bo to był mój pierwszy kontakt i do tej konwersji mam największy sentyment.

    Co do reszty proponowanych bajerów to jak silnik gry będzie kompletny to mogę dodać co tylko Pan @Kaz zechce narysować ;)

    Mechanikę bossów (o ile będą) podpatrzę zapewne w grze @tdc Tomcat.

    Chciałbym przypomnieć, że gra jest/będzie efektem ubocznym mojej nauki hardware i technik programistycznych, na to kładę teraz nacisk. Także o ile dla postronnych postęp w pracach może być nie dość szybki jednak sporo się uczę każdego dnia o Atari.

    Jak już posiądę niezbędne minimum, wtedy siędę do autorskiej gry i ukończenie jej będzie celem.
    • 31: CommentAuthorzbyti
    • CommentTime18 May 2020 zmieniony
     
    ACTION! BUG SHEET #3 ->link<-

    Warto przeczytać. Na podstawie tego zestawienia zmieniłem deklarację wielkości tablicy z liczby hex na dziesiętną itd.

    W praktyce trzeba wiedzieć z tego artykułu 3-4 rzeczy by posługiwać się Action! 3.6 - nie jest źle! :]
    • 32:
       
      CommentAuthorCOR/ira4
    • CommentTime18 May 2020 zmieniony
     
    zamiast bosów latających można narysować dużą fortece która strzela rakietami z otwieranych silosów,i jakieś fajne animacje zrobić,myślę że forteca bardziej by pasowała do tej gry niż standardowi bossowie.
    myślę że Kaz się zgodzi,chyba że ma inną wizję .
    • 33: CommentAuthorzbyti
    • CommentTime18 May 2020 zmieniony
     
    Plugin Michała zmienia programowanie w coś przyjemnego :] ->link<-
  2.  
    @zbyti - dzięki, dobrze wiesz jak dużo do poprawy jeszcze jest :)

    natomiast ciekawi mnie Twoja opinia o konwerterze - dzisiaj nie dałem rady - ale asap wrzucę to na GitHub :)
    • 35: CommentAuthorzbyti
    • CommentTime19 May 2020 zmieniony
     
    @mkolodziejski jeszcze nie miałem okazji użyć ale przeczytałem kod i wydaje się być tym czego potrzebowałem :]

    ---------------------------------------------------------------------------

    Otrzymałem wczoraj od @mono krótki ale pouczający wykład na temat ANTIC'a i zrozumiałem, że rejestr cień SDMCTL służy do czegoś więcej niż gaszenia światła ;)

    NMIEN=$C0         ; TURN ON NON MASKABLE INTERRUPT %110XXXXX
    SDMCTL=$2E ; TURN ON ANTIC %XX101110

    W grze będą używane sprite-y, więc domyślną wartość SDMCTL=$22 przestawiłem na $2E tym samym włączając DMA dla P/MG.

    Efekt mam na razie taki, że pieczołowicie ustawiony Pirx-owy "trykers" zaczął drgać.

    Ciekawe o co chodzi?
    • 36:
       
      CommentAuthorDracon
    • CommentTime19 May 2020
     
    Może drganie związane jest z rejestrami koloru, czy duszki nie mają jakiś rejestrów dzielonych z innymi?
    • 37: CommentAuthorxxl
    • CommentTime19 May 2020 zmieniony
     
    wlaczenie dma dla pm skaraca czas dla dli, w liniach trybu tekstowego przy tzw. bad lines moze sie nie wyrabiac.
    sprawa 2: sprawdz zakres danych ladowanych do rejestru hscroll a szczegolnie jak robisz to na dli a suerszczegolnie na liniach trybu tekstowego
    • 38: CommentAuthorzbyti
    • CommentTime19 May 2020 zmieniony
     
    @xxl powiedz mi jak ignorować twoje istnienie jednocześnie nie ignorując twojej wiedzy?

    Według udzielonej porady możliwe, że ten kod:

    SET $E=DLIAADDR
    DLIA=[
    PHA
    LDAZ $56 WSYNC
    STA $18 $D0 PHA CLC ADCI 2 WSYNC
    STA $18 $D0 PLA WSYNC
    STA $18 $D0 DECZ $56 DECZ $56 CMPI $80 BNE $16
    LDAI $E STAZ $56 LDAI $A0 STA 0 2 LDAI DLIMSB STA 1 2 LDAI 0 WSYNC
    STA $18 $D0
    PLA RTI
    ]

    się nie wyrabia, skoro włącznie DMA dla P/MG miało skrócić czas dla DLI.



    Uproszczę kod i zobaczę co się stanie.
    • 39: CommentAuthorxxl
    • CommentTime19 May 2020 zmieniony
     
    PLA i PHA no... nie, tak nie.

    napisz tak i bedzie dzialac ;-)

    PHA
    LDA $56
    STA $D40A
    STA $D018
    CLC
    ADC #$02
    STA $D40A
    STA $D018
    LDA $56
    STA $D40A
    reszta tak samo

    tez nienajlepiej ale to sa minimalne zmiany zeby ruszylo.
    • 40: CommentAuthorzbyti
    • CommentTime19 May 2020 zmieniony
     
    @xxl thx!

    SET $E=DLIAADDR
    DLIA=[
    PHA
    LDAZ $56 WSYNC
    STA $18 $D0 CLC ADCI 2 WSYNC
    STA $18 $D0 LDAZ $56 WSYNC
    STA $18 $D0 DECZ $56 DECZ $56 CMPI $80 BNE $16
    LDAI $E STAZ $56 LDAI $A0 STA 0 2 LDAI DLIMSB STA 1 2 LDAI 0 WSYNC
    STA $18 $D0
    PLA RTI
    ]

    Faktycznie, problem ustąpił :]

    Może jeszcze to usprawnię przy okazji, bo chyba przeniosę DL i DLI z tablic do procedur aby relokacja była jeszcze prostsza.
    • 41:
       
      CommentAuthorCOR/ira4
    • CommentTime19 May 2020
     
    @zbyti
    trzeba teraz sprawdzić czy z Ultimate rusza ;)
    • 42: CommentAuthorzbyti
    • CommentTime19 May 2020 zmieniony
     
    @IRATA4 normalnie doceniłbym dowcip ale wczoraj @mono mimowolnie mi uzmysłowił bym dał na luz w "świętej wojnie" ;)
    • 43: CommentAuthorzbyti
    • CommentTime19 May 2020 zmieniony
     
    Action! Display Lists

    Kolejne moje samodzielne odkrycie. Tak się pisze DL w Action!:

    DEFINE
    DLADDR="$5000",
    STARTSCREEN="$8000",
    RET="[69]"

    BYTE ARRAY
    SCREEN=STARTSCREEN,
    TEXT(48)

    CARD SDLSTL=$230

    SET $E=DLADDR
    PROC DL=*()
    [
    $70 ; EMPTY ROW
    $42 TEXT ; FIRST TEXT ROW (GR.0)
    $D2 SCREEN^ ; STARTSCREEN (GR.0) WITH HSCROL AND DLI
    $12 $92 $12 $92 $12 $92 $12 $92 $12 $92 $12 $12
    $12 $12 $12 $12 $12 $92 $92 $92 $92 $92 $92 $92
    $70 $70 ; TWO EMPTY ROWS
    $41 DL ; JUMP TO BEGINNING OF DL
    ]

    PROC INIT()
    SDLSTL=DL
    RET

    SET $E=DLADDR używamy by mieć pewność, że DL nie wypadnie na granicy licznika.
    • 44: CommentAuthorzbyti
    • CommentTime19 May 2020 zmieniony
     
    No to do kompletu DLI:

    DEFINE
    DLIAADDR="$8850",
    DLIBADDR="$88A0"

    CARD VDSLST=$200

    SET $E=DLIAADDR
    PROC DLIA=*()[
    PHA
    LDAZ $56 WSYNC
    STA $18 $D0 CLC ADCI 2 WSYNC
    STA $18 $D0 LDAZ $56 WSYNC
    STA $18 $D0 DECZ $56 DECZ $56 CMPI $80 BNE $16
    LDAI $E STAZ $56
    ] VDSLST=DLIBADDR [
    LDAI 0 WSYNC STA $18 $D0
    PLA RTI
    ]

    SET $E=DLIBADDR
    PROC DLIB=*()[
    PHA
    LDAZ $56 WSYNC
    STA $17 $D0 DECZ $56 DECZ $56
    CMPI $2 BNE $16 LDAI $8A STAZ $56
    ] VDSLST=DLIAADDR [
    LDAI $E WSYNC STA $17 $D0
    PLA RTI
    ]
    • 45: CommentAuthorzbyti
    • CommentTime19 May 2020 zmieniony
     
    Kolejna sztuczka w Action! przydatna szczególnie jeżeli jakaś procedura jest wywoływana w "długiej pętli".

    Jeżeli procedura nie posiada zmiennych lokalnych, do tego nie przyjmuje parametrów lub przykazujemy parametry przez rejestry to warto deklarować procedurę za pomocą =*.

    Oszczędzi nam to wywoływania JMP który jest "produkowany" na początku każdej procedury w ML i skacze do następnego po sobie adresu. Zyskujemy na tym 3 cykle na iterację pętli.

    Oczywiście tak zdeklarowana procedura mogła by przyjmować parametry o łącznej "wadze" przekraczającej 3 bajty bo wtedy szukamy ich na stronie zerowej. Pewnie także zmienna lokalna zadeklarowana w sposób absolutny nie ląduje w pamięci przed właściwym kodem procedury ale to niech każdy już obada sam.
    • 46: CommentAuthorxxl
    • CommentTime19 May 2020 zmieniony
     
    taka dobra rada, jak chcesz optymalizowac pod wzledem szybkosci to nie uzywaj wartosc 0,1,2,3 w rejestrze HSCROL, zmien procke zeby uzywac wartosci z konca przedzialu np. C D E F - nawet ta Twoja pierwotna procka DLI powinna sie wtedy wyrobic i bedzie pracowac stabilnie.
    ale tu jest pulapka bo jesli jakis nikifor elektroniki nie rozumie specyfikacji i zaprojektuje popularna modyfikacje to moze sie okazac ze te wartosci nie beda dzialac ;-)
    • 47: CommentAuthorVidol
    • CommentTime19 May 2020
     
    A dlaczego na koncu przed skokiem na poczatek DL dajesz te dwa puste wiersze $70?
    • 48: CommentAuthorzbyti
    • CommentTime19 May 2020
     
    @xxl zrobię tak jak radzisz chwilę po tym jak to zrozumiem ;) Właśnie czytam na ten temat.

    @Vidol bo to kod testowy, czasem dodawałem wiersz, czasem odejmowałem, a zanim zrobiłem "relokujące się" DL i DLI, do tego nie wiedziałem jeszcze, że można sterować kompilatorem tak jak teraz, to każda zmiana o bajt w DL zmieniała mi adresy w innych miejscach. Docelowo tego nie będzie. W sumie to już mogę skasować te zbędne $70 bo viewport został już ustalony. Dzięki za uwagę :]
    • 49: CommentAuthorzbyti
    • CommentTime19 May 2020 zmieniony
     
    Wyciągnąłem jeszcze 4 cykle na DLI wyrzucając CLC i 2x DEC:

    SET $E=DLIAADDR
    PROC DLIA=*()[
    PHA
    LDAZ $56 WSYNC
    STA $18 $D0 ADCI 2 WSYNC
    STA $18 $D0 LDAZ $56 WSYNC
    STA $18 $D0 SEC SBCI 2 STAZ $56 CMPI $7E BNE $16
    LDAI $E STAZ $56
    ] VDSLST=DLIBADDR [
    LDAI 0 WSYNC STA $18 $D0
    PLA RTI
    ]

    Nie udało mi się znaleźć dlaczego schodzenie w HSCROL z $F->$C jest szybsze niż od 3->0.

    %1111 %0011
    %1110 %0010
    %1101 %0001
    %1100 %0000


    Ale chyba rozumiem, to specyfika GR.0. Jadąc od 3 do 0 ruszam tym czego i tak w tym trybie nie widać?

    Ok wrzucam od $F do $C może mieć to sens ale nie znam tak dobrze hardware by wiedzieć to na pewno.
    • 50:
       
      CommentAuthorMq
    • CommentTime19 May 2020 zmieniony
     
    Czy moglibyście (xxl?) wytłumaczyć łopatologicznie i bez skrótów myślowych na czym polega optymalizacja w wypadku użycia wartości wyższych niż 0-3 w hscroll? Rozumiem jakie wartości tam można wpisywać i na czym polega wtedy przesuw, ale nie kumem kompletnie dlaczego ma to niby działać wtedy szybciej, a ryjąc internet znajduję w zasadzie tylko dogmaty na ten temat.

    Edit: aha, w sumie głównie interesuje mnie tu tryb antic 4, a w niniejszym wątku gr 0, ale odpowiedź ogólna dotycząca wszystkich trybów by się przydała w tym temacie.