atarionline.pl Assembler 6502 - odwapnianie mózgu :) - 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.

    4. Programowanie / Programming  »   Assembler 6502 - odwapnianie mózgu :)

    W dół

    Od 101 do 150 z 226

    1. <
    2. 1
    3. 2
    4. 3
    5. 4
    6. 5
    7. >
      • 1: CommentAuthorBrix
      • CommentTime23 Mar 2012 20:03
       
      @xxl: O! Tak się właśnie ostatnio nad tym zastanawiałem, choć do ewentualnego wykorzystania droga daleka. To mam dwa pytania: 1. Skąd to... ściągnąć? 2. Czy xBIOS używa pamięci na stronie zerowej?
      • 2:
         
        CommentAuthorjhusak
      • CommentTime23 Mar 2012 20:03
       
      @xxl, ty szaleńcze, gdzie to można zdownloadować, pod linkiem nie ma możliwości downloadu.

      A i nie jest dzisiaj pierwszy kwietnia.
      • 3: CommentAuthorxxl
      • CommentTime23 Mar 2012 21:03
       
      1. z mojego dysku <reklama>(wkrotce bedzie oficjalna prezentacja przy okazji publikacji gry)</reklama> a jesli chcesz poprobowac wersje beta to sciagnij SligtSIDPlayera (jest w .atr)
      2. NIE uzywa strony zero, nie uzywa OS, mozesz podczas ladowania wylaczyc OS i ladowac bezposrednio do RAM pod ROM itd. pod linkiem jest info.
      • 4:
         
        CommentAuthorxeen
      • CommentTime23 Mar 2012 21:03
       
      i to dopiero jest dobra wiadomość, XXL :)
      • 5:
         
        CommentAuthorjhusak
      • CommentTime23 Mar 2012 21:03 zmieniony
       
      @xxl, czy to tak działa, że doczytuje z dysku odpowiednie kawałki kodu?
      W sumie jak ładujemy plik, czy go otwieramy, czy cuś, to i tak z tym dyskiem mamy do czynienia. Co to za różnica doczytać 2-3 sektory.
      • 6: CommentAuthorxxl
      • CommentTime23 Mar 2012 21:03
       
      xbios nic nie doczytuje na swoje potrzeby. to zwykla biblioteka IO z funkcja inicjalizera :-)
      roznica jest taka, ze jesli chcesz czytac/zapisywac z dysku to albo sie godzisz na masakryczne wymagania dosa (pamiec od $2000, OS wlaczony itd.) ale masz dane pogrupowane w plikach albo robisz program calodyskowy i "sektory" albo laczysz zalete pierwszego rozwiazania (pliki) z zaletami drugiego (niskie wymagania) a to oznacza <reklama>xbiosa</reklama> ;-)
      • 7:
         
        CommentAuthorjhusak
      • CommentTime23 Mar 2012 21:03
       
      No dobra.
      Czyli jest w tym kilobajcie:
      xex loader ($180 bajtów)
      obsługa dysków niskopoziomowa (dajmy na to z 300 bajtów)
      jakieś szczątkowe przerwanie VBLANK? pewnie nie, bo jak się odłączy system, to co z wektorem przerwań na końcu pamięci? czyli musi być SEI i działać bez przerwań.
      obsługa jakiegoś filesystemu atarowskiego.
      Czy tak?

      A tak nawiasem mówiąc ten mój pomysł na dosa jest całkiem zacny :)
      Takie nakładkowanie :)
      Lata miną, zanim go zrobię :)
      • 8:
         
        CommentAuthormgr_inz_rafal
      • CommentTime23 Mar 2012 22:03 zmieniony
       

      0xF:

      @mgr_inz_rafal: zależy, jakiego rodzaju program piszesz.
      Na razie zrobiłem sobie DL i rysuję kreski, kropki, kwadraty... Docelowo ma to być gierka niepotrzebująca BASICa.

      Jeśli piszesz grę lub demo bez użycia OS, to możesz jechać po całej pamięci, oszczędzając tylko DOSa i zmienne OS podczas wczytywania.
      To jest właśnie mój przypadek. Czy mógłbyś napisać, które adresy powinienem omijać?

      W ogóle zadałem to pytanie dlatego, że przestałem rozumieć co się dzieje w moim dość prostym programie do rysowania linii w trybie $0b ANTICa. Rysowanie 100 linii powodowało kaszankę na ekranie, ale te same linie rozdzielone za pomocą "jsr $f24a" już rysowały się dobrze (choć trzeba było zużyć ENTER). Czasem zakomentowanie jednej z tych 100 linii pomagało, czasem nie :/ Zacząłem więc manewrować ekranem i org'iem, co doraźnie pomogło, ale chciałbym jednak zrozumieć dlaczego, bo nie jestem zwolennikiem techniki "shotgun bugfixing" :) A dlaczego jest to tak ważne? Na moim poziomie znajomości ASM nie mogę mieć pewności, że procedurę LINE napisałem dobrze (zawsze można zapomnieć jakiegoś sec przed sbc). Dlatego też zanim zacznę ją pisać od nowa, chciałbym z Waszą pomocą zweryfikować, czy nie popełniłem jakiegoś czeskiego błędu już w założeniach programu, np. umieszczając ekran nie tam gdzie trzeba lub też nie czyszcząc uprzednio pamięci.

      jhusak:

      dobrze najpierw zerować obszar, pod który właduje się gra, a potem ją tam władować (mechanizmami plików dosowych)

      Hę? Generalnie to idzie tak: piszę plik .asm, uruchamiam MADS i wychodzi mi .xex, który ładuję do emula lub komputa. W którym miejscu tego łańcuszka jest miejsce na wyczyszczenie pamięci?

      xxl:

      nie trzeba oszczedzac DOSa i zmiennych OS: przepis na szczescie i dostatek
      Kurde, naprawdę szacun :) Ludzie, Wy nie macie życia? :)

      Pozwolę sobie jeszcze raz poprosić o doprecyzowanie:
      Czy pisząc gierkę (ambitnie powiedziane), mogę spokojnie ustawić org na $2000, a ekran na $8000 uprzednio go czyszcząc? I czy powyższe ustawienia dadzą mi pewność, że jeśli na ekranie zobaczę krzaczory, to błąd jest gdzieś w moim kodzie?
      • 9: CommentAuthorbob_er
      • CommentTime23 Mar 2012 22:03
       
      co do robienia na złość sdx-owcom - no niestety, pod spartą memlo zwykle jest dużo niżej, niż w normalnym (innym) dosie. dla przykładu - ja w swojej konfiguracji:
      - ładuję wygaszac ekranu z tajemnic atari (plemnik),
      - mam bufory na otwartych max. 12 plików jednocześnie
      a memlo mam $16ca :P
      • 10:
         
        CommentAuthorjhusak
      • CommentTime23 Mar 2012 22:03 zmieniony
       
      Gdzieś pisałem at0micowi.

      pamięć ekranu musi mieścić się w granicach bloków 4kb, a pamięć display listy w granicach bloków 1 kb.

      Czyli przed zdefiniowaniem obszaru ekranu piszesz:
      align $1000
      potem robisz skip szeregu bajtów (bo 4096 nie dzieli się przez 40 :)

      a w przypadku dl robisz align $400.

      Ale. Można to połączyć. Display lista dla hires ma nieco ponad 200 bajtów, ale mniej niż 216. A więc w pierwszym bloku 4kB umieścimy display listę i (4096-216)/40 linii ekranu - czyli 97.:
      align $4000
       dlist:
       .by $70,$70,$70
       .by $4f ; lms
       .wo screenmem ; adres
       :96 .by $0f ; 96 linijek
       .by $4f ;lms
       .wo screenmem+97*40 ; adres dlist+$1000
       :94 .by $0f ; 94 linijki
       .by $41
       .wo dlist
      screenmem=dlist+216
        org screenmem
        :7680 .by 0 ; to jest dla ilustracji, nie jest potrzebne zapisywanie w exeku 7680 zer :)

      ; dalsza część kodu


      A czyszczenie pamięci na początku łańcuszka.

      czyli np.
      org $2000
       ; czyścimy czyścimy całą pamięć
       org $2000
       ; twój kod programu.

      ale to w wersji finalnej, bo nie wiadomo, co innym strzeli do łba.
      • 11: CommentAuthormono
      • CommentTime23 Mar 2012 22:03
       
      1. Jeśli używasz madsa zapoznaj się z makrami wbudowanymi typu sub, add itd. Nie będziesz musiał pamiętać o sec/clc :>
      2. Jeśli Twoja gra ma coś doładowywać z dysku lub wykorzystywać dodatkową pamięć pamiętaj, że blok pamięci dodatkowej włączany jest w obszarze $4000..$7fff więc jeśli tam będzie dlist i/lub pamięć ekranu to może Ci to mrugać podczas komunikacji (jeśli banki pamięci przełączane będą bez synchronizacji z plamką - VCOUNT lub RTCLOK lub VBLK).
      3. Inna rzecz (z gatunku "jestem super purystą językowym") - wiem, że na c64 używacie ADRESÓW rejestrów w programach; oczywiście nic nie stoi na przeszkodzie robić to dalej, ale dość czytelnie jest kiedy w kodzie widać nazwy rejestrów :) (ja przynajmniej wolę PORTB zamiast $D301). Tym bardziej, że na konsoli 5200 ten sam hardware co w XL/XE znajduje się gdzie indziej...
      4. Jeśli idzie o skrol, to może jutro wieczorem uda mi się przywołać efekt o którym mówiłem :)
      5. Osobiście bardzo nie lubię kiedy rejestry (hardwareowe lub cienie) zapisywane są za pomocą bloków pliku binarnego:
      org COLPF0
        .byte $10,$20,$30,$40,$0a
        org COLPF0S
        .byte $10,$20,$30,$40,$0a

      ponieważ nigdy nie wiadomo, jak i kiedy loader to będzie zapisywał. Efekt czasami jest taki, że ekran podczas ładowania zaczyna mrugać, bo loader zainicjalizował połowę adresu dlist (DLPTRS/DLPTR) przed wystąpieniem przerwania VBLK. Lepszym rozwiązaniem jest użyć krótkiego programiku, który sam zainicjalizuje odpowiednie rejestry np.:
      lda RTCLOK+2
      ?sync: cmp RTCLOK+2
        beq ?sync
        ldy #4
      ?loop: lda regs,y
        sta COLPF0,y
        sta COLPF0S,y
        dey
        bpl ?loop
        rts 
      regs: .byte $10,$20,$30,$40,$0a

      6. No i jeszcze rzecz związana z odwołaniami do OSa. Korzystaj z tablic rozpoczynających się od $e400. Mieszczą się tam wektory oraz skoki do procedur systemowych. Unikaj jak ognia skoków w konkretne miejsca ROMu (jeśli korzystasz z OSa), bo w Atari masz kilka wersji ROM (zarówno OS, jak i BASIC) więc Twój program może potem nie zadziałać na różnych wersjach komputera. Najczęściej wykorzystywaną częścią OSu są chyba procedury ustawiania wektorów (JSETVBLV) oraz CIO.
      • 12: CommentAuthorxxl
      • CommentTime23 Mar 2012 22:03
       
      bob_er dodaj, ze masz atari z rozszerzona pamiecia i pewnie jakis kardridge z dosem. no i ciagle to jest $16ca i przymus wylaczonego OS podczas IO (podczas gdy wiekszosc loaderow ma memlo nizej o ponad 2,5 kb). bedziesz wymagal od userow tych rozszerzen?

      @jhusak, przerwania nie sa zajete, SEI jest tylko na czas komunikacji SIO.
    13.  

      jhusak:

      A czyszczenie pamięci na początku łańcuszka.
      org $2000
      ...
      org $2000
      Heh, najciemniej pod latarnią :) Parafrazując Kudłatego z Killera: Sto lat bym myślał i bym nie wymyślił :)

      mono:

      Jeśli używasz madsa zapoznaj się z makrami wbudowanymi typu sub, add itd. Nie będziesz musiał pamiętać o sec/clc
      Nie miałem pojęcia o istnieniu takich makr :) Pewnie dlatego, że jestem z gatunku tych, co to najpierw kombinują, a potem czytają instrukcje i manuale ;) W ogólnym rozrachunku to może nie być takie złe, bo jak się kiedyś przesiądę na Quick Assemblera na prawdziwej Atarynce, to przyda się pamiętanie o CLC :)

      Jeśli Twoja gra ma coś doładowywać z dysku lub wykorzystywać dodatkową pamięć
      Nie... Nic z tych rzeczy nie planuję. To ma być zwykłe rysowanie, zmazywanie + jakiś duszek snujący się po ekranie. Tak na początek...

      Inna rzecz (z gatunku "jestem super purystą językowym") - wiem, że na c64 używacie ADRESÓW rejestrów w programach; oczywiście nic nie stoi na przeszkodzie robić to dalej, ale dość czytelnie jest kiedy w kodzie widać nazwy rejestrów :)
      Ogólnie też wolę typedefy niż studwudziestoośmioznakowenazwytypówiteratorówwstl :) Aha, na C64 nigdy nie programowałem, ani też za bardzo nie miałem z nim styczności. Kiedyś u kolegi grałem na nim w Monopoly :)

      Korzystaj z tablic rozpoczynających się od $e400. Mieszczą się tam wektory oraz skoki do procedur systemowych. Unikaj jak ognia skoków w konkretne miejsca ROMu
      Czy chodzi o to, że "jsr $f24a" jest złe, bo mogę nie trafić w dobre miejsce na innym OS? W takim razie jak poprawnie zrobić GETCHAR korzystając z tablic $e400?

      PS. Zabieram się za kolorowanie rysowanych przeze mnie linii, ale Google na hasło "GTIA KOLORY" zwraca "Tabela kolorów rajstop firmy Gatta" ;-)
      • 14: CommentAuthorBrix
      • CommentTime23 Mar 2012 23:03
       
      @mgr: Ponieważ widocznie sam jestem początkujący i z obszernej (szacun :) ) wypowiedzi mono chyba sam niewiele rozumiem ( ;) ;) ;) ), to:

      Jak wywalisz OS i pamięć ROM, masz wszystko do swojej własnej dyspozycji (ograniczonej tylko wyobraźnią i ograniczonym sprzętem), pomijając pamięć rejestrów, czyli $D000-$D7FF. No i miejsce gdzie będzie ewentualnie xBIOS :)

      Problemy z antikiem mogą wynikać z różnych przyczyn, także tu wyjaśnionych.

      Zerowanie pamięci nie zawsze jest potrzebne, to zależy. Jeśli robisz coś, co wymaga "czystej" pamięci ( i która była zarezerwowana np. przez .ds ), najlepiej ją wyzerować (np. pamięć duszków). Ale przy depaku danych jest to kompletnie niepotrzebne, tudzież przy użyciu org, gdy pod dany adres są ładowane jakieś konkretne dane (zawarte np. w liniach dta)
      • 15: CommentAuthorbob_er
      • CommentTime23 Mar 2012 23:03
       
      xxl: ano mam i rozszerzoną pamięć, mam i carta z dosem.
      wiem, że loadery memlo mają całkiem nisko - bo to czasem wykorzystuję sam dla siebie. ale pamiętaj, że loadery nie dają takiej funkcjonalności jak sdx (mówię głównie o symbolach - z których korzystam najczęściej).
      ale to już chyba lekki ot się zrobił :).
      co do sedna sprawy: to może pomoże: ->link<- interesujące rejestry mają nazwy COL*.
      • 16: CommentAuthormono
      • CommentTime23 Mar 2012 23:03
       
      Ojej - pomyliłem Cię z Atomicem w innym wątku (sory).
      Poprawny EGETCH to standardowy odczyt znaku z CIO - zakładając, że nie zamykasz edytora to po odpaleniu programu jest on otwarty w kanale 0:
      ldx #0
      lda #GETBT
      sta ICCMD
      stx ICBUFL
      stx ICBUFL+1
      jsr JCIOMAIN
      bmi error

      Po wyjściu z CIO znacznik N oznacza błąd a wtedy w Y masz kod błędu, wpp w A dostaniesz kod odczytanego znaku.
    17.  
      Kurde, ustawiłem $0b ANTICa i chcę kolory zmieniać...

      No nic, jutro zmiana na $0d i próba przepisania procki rysującej linie :)
    18.  
      Hej,
      Jeszcze jedno krótkie (tzn. początkowo miało być krótkie...), bo czegoś nie czaję :)

      Zmodyfikowałem moją prockę LINE, aby działała w $0d. Działa, rysuje kolorowe kreski, itp.

      Ale...
      W ramach pisania test-case chciałem sobie poziomymi liniami (hline) wypełnić cały ekran, napisałem więc cały szereg takich komend:
      hline #0, #159, #0, #$ff ; od 0 do 159, wiersz 0, kolor $ff
      hline #0, #159, #1, #$ff ; od 0 do 159, wiersz 1, kolor $ff
      hline #0, #159, #2, #$ff
      hline #0, #159, #3, #$ff
      Itd.
      Wszystko ładnie pięknie, aż dojechałem do
      hline #0, #159, #73, #$ff

      (Albo coś około #73, nie pamiętam już dokładnie...)

      W tym momencie na ekranie pojawiają się krzaki, psuje się DL, itp. Po usunięciu linii #73, jest OK.

      Myślę sobie, coś w algorytmie rysowania jest pierdyknięte, że powyżej #72 zaczyna mazać gdzieś po RAM, ale... jeśli zakomentuję parę pierwszych linii (np. #0, #1 i #2) to mogę już narysować #73, #74 i #75... Czyli procka jest OK :/

      Jeśli między każdą linię wstawię sobie w ramach debugu "jsr $f24a", to rysowanie psuje się już przy ok. #40-ej linii.

      Wykonałem jeszcze jedną próbę, tzn. zamiast pisać 88 razy hline napisałem prostą pętlę, która wywołuje mi tę prockę zwiększając współrzędną poziomą. Działa wyśmienicie i bez problemu wypełnia cały ekran :)

      Mój chłopski rozum podpowiada więc, że przyczyną problemów jest jakby "ilość" wywołań procki w sensie jeden "hline" pod drugim kilkadziesiąt razy.

      Czy na podstawie powyższego opisu uda się komuś wyjaśnić takie zachowanie i wskazać, czego i w jakim artykule nie doczytałem? :)
      • 19: CommentAuthorBrix
      • CommentTime24 Mar 2012 23:03
       
      Te hline to makro?

      Pierwsze co przychodzi mi na myśl, to sprawdź długość programu, czy po prostu gdy staje się za długi, to nie wchodzi na jakieś wrażliwe dane czy pamięć rejestrów.
      • 20: CommentAuthorepi
      • CommentTime24 Mar 2012 23:03 zmieniony
       
      Powiedz swojemu asemblerowi, żeby wypluł listing i zobacz, jaki jest po zasemblowaniu adres początku i końca display listy.
      Jeśli display listę wpisujesz w dta i jest ona umieszczona za kodem, to może się zdarzyć, że (zależnie od objętości kodu) DL wypadnie na granicy kilobajtów, skutkiem czego ANTIC w którymś miejscu zacznie czytać od początku tego samego kilobajta, gdzie zapewne jest kod dla 6502, który po zinterpretowaniu jako DL ma szanse wyglądać jak śmieci.
      Nad położeniem display listy w pamięci warto mieć pełną kontrolę, dlatego wygodnie umieścić ją zaraz po org. Można też poprosić asembler, żeby sprawdzał, czy DL jest w bezpiecznym miejscu:
      DisplayList
       dta ......
       ert [[*+1]^DisplayList]&$fc00  ; blad asemblacji, jesli
                                      ; przekroczona granica 1KB
       ert *>$C000     ; blad asemblacji, jesli kod/dane
                       ; wpadaja w obszar zajety przez ROM
      • 21: CommentAuthorEagle
      • CommentTime24 Mar 2012 23:03
       
      Jeśli DList nie ma ustalonego adresu i po prostu jest na końcu Twojego programu a macro hline zajmuje sporo miejsca to być może DList przesunął się na załamanie 4kb bloku.
      Zamieszałem ale chyba wiadomo o co chodzi :)
      Czyli ustaw org dla dlist w jednym miejscu.
      Przypuszczam że raczej o to chodzi.
      • 22: CommentAuthorEagle
      • CommentTime24 Mar 2012 23:03
       
      @epi: zawsze myślałem że chodzi o 4kb :)
      • 23: CommentAuthorepi
      • CommentTime24 Mar 2012 23:03 zmieniony
       
      4KB to na dane ekranu. :)

      I jeszcze w kwestii formalnej: 4kb to 4 kilobity, czyli 4000 bitów, czyli 500 bajtów. :)
      • 24: CommentAuthorEagle
      • CommentTime24 Mar 2012 23:03
       
      Rzeczywiście granica kilobajta nie wiem czemu przekonany byłem że czterech.
      Z reguły mam adres dla DL więc nie zwróciłem na to uwagi ale człowiek uczy się całe życie.
      Dane ekranu to oczywista oczywistość a kilobity przemilczę :]
      • 25: CommentAuthormono
      • CommentTime24 Mar 2012 23:03
       
      A 4tb to 4 trylobity :)
    26.  

      Brix:

      Te hline to makro?
      Jest to procka:
      .proc	line(.byte s1,s2,y,col) .var

      Pierwsze co przychodzi mi na myśl, to sprawdź długość programu
      Chyba jeszcze jest OK. W końcu to tylko jedna procka + te liczne wywołania, a siedzi od $2000. Plik xex ma przy tym 2kB, więc do $7ff jeszcze trochę brakuje.

      epi:

      Powiedz swojemu asemblerowi, żeby wypluł listing i zobacz, jaki jest po zasemblowaniu adres początku i końca display listy.
      Zatem tak: w przypadku gdy dojdę do line #72 i program jeszcze działa, DL umieszczona jest między $27A0 i $2802. Gdy dopiszę kolejną linię (#73) obraz zaczyna się kaszanić, a DL ląduje między i $27B7 i $2819.

      Wygląda więc na to, że i w pierwszym i w drugim przypadku przełamuje granice 1kB. Natomiast jeśli usunę również linię #72, to nie przekracza granicy ($2789-$27eb). Może więc jak dam #72 to już DL jest pokaszaniona, ale jeszcze nie ma to odzwierciedlenia na ekranie...

      --- EDIT ---
      Acha, w sumie nie wiem, czy dobrze liczę zakończenie DL. Na końcu jest 3-bajtowe JVB, więc jeśli odjąć te trzy bajty to przy #72 mamy DL od $27A0 do $27ff i na styk nie przechodzimy przez granicę :)
      --- EDIT ---

      Jeśli display listę wpisujesz w dta i jest ona umieszczona za kodem
      Dokładnie tak mam. Wzięte z tutoriala w necie.
      dlatego wygodnie umieścić ją zaraz po org
      Bingo! To pomogło :)

      Eagle:

      Przypuszczam że raczej o to chodzi.
      Dokładnie - dobra intuicja :)

      Wielkie dzięki po raz już któryś tam! :)
      • 27:
         
        CommentAuthorjhusak
      • CommentTime25 Mar 2012 01:03 zmieniony
       
      DL umieszczona jest między $27A0 i $2802. Gdy dopiszę kolejną linię (#73) obraz zaczyna się kaszanić, a DL ląduje między i $27B7 i $2819.


      No przecież Ci piszę, że dl nie może wyjść z bloku 1 kb. a u Ciebie w pierwszym przypadku wychodzi o 3 bajty. W drugim znacznie więcej.

      Pytanie - dlaczego w pierwszym przypadku działa?
      Bo przerwanie pionowe nadpisze początek dl dobrą wartością braną z rejestrów - cieni.

      Taki przykład klepałem i się namęczyłem - poczułem się zignorowany ...
      Jakoś się pozbieram.
    28.  
      @jhusak,
      Uczymy się stopniowo (tzn. przynajmniej ja) :)
      W momencie jak podawałeś swój przykład to akurat z DL nie miałem problemu, więc przeczytałem, a hipokamp odfiltrował :)

      Ja nawet wiedziałem o tej granicy 1kB już na początku "brania się" za ASM, jak czytałem materiały o DL. Ale wziąłem kod z tutoriala, działało, więc nie wnikałem głębiej i zająłem się rysowaniem linii (bez tutoriali), co kosztowało mnie sporo wyrzeczeń :)

      Podobnie teraz: piszesz o przerwaniu pionowym i przepisywaniu z rejestrów cieni. Nie wiem o co chodzi, więc pewnie nie zapamiętam i może za 3 tygodnie znowu zapytam, dlaczego DL działa jak wylatuje o 3 bajty za daleko :)

      Ogólnie, to podobnie jest z większością Waszych przykładów w tym wątku - wylatują o dużo dalej niż 3 bajty poza mój bieżący stan wiedzy :) Poczytam, owszem, bo chociaż poznam słownictwo, ale skorzystam na nich na razie tak, jak pies z kalkulatora :)
      • 29:
         
        CommentAuthorjhusak
      • CommentTime25 Mar 2012 12:03 zmieniony
       
      Ależ to proste. Rejestry cienie służą do pamiętania przez SO wartości wpisanych do rejestrów hardware tylko do zapisu (w przeważającej większości)

      Np. kolory. Nie można ich odczytać z rejestrów hardware.

      Display list (adres) mieści się w komórkach $230,$231 (560,561) i jest co przerwanie pionowe wpisywany do rejestrów hardware.

      Przerwanie pionowe to "rytm serca" systemu operacyjnego. Wykonuje się 50/60 razy na sekundę (PAL/NTSC) i zajmuje się: obsługą czasu (komórki 18,19,20) trybem "screensaver" - attract mode, obsługą odczytu klawiatury i zamianą na tryb klawiaturowy, przepisaniem rejestrów cieni do ich hardware'owych odpowiedników, i jeszcze parę innych (W Zientara- podstawowe procedury systemu operacyjnego - przerwania systemowe ->link<- )

      Dlatego w przypadku używania SO adres skoku $41 na końcu display listy nie jest brany pod uwagę, bo i tak zostanie nadpisany.

      A jak by wyłączyć SO (czy po prostu wyłączyć uaktualnianie wektora DL) to można tryby interlace robić bez udziału procesora (dwie display listy wzajemnie do siebie skaczące). Procesor tylko powinien zmieniać kolory co przerwanie pionowe, aby taki interlace miał sens.

      PS.

      Pies Antoni? ;P
      • 30:
         
        CommentAuthorjhusak
      • CommentTime28 Mar 2012 16:03
       
      Ale zastój...
      • 31: CommentAuthorMaciek
      • CommentTime28 Mar 2012 18:03
       
      Chyba w ruch poszedł jakiś podręcznik ;P
      Albo słońce zrobiło swoje i Rafał zniknie na jakiś czas...
    32.  
      Fakt, ostatnie dwa weekendy przy grillu zamiast przy kompie :) Zresztą podobno nie tylko ja :)

      Ale co wieczór trochę czasu dłubię. Kolorowe kreski już mam - wkrótce biorę się za $278 i pierwszą próbę animacji brzucha dżojstikiem :)

      Dlaczego brzucha? Na razie tajemnica, bo nie chcę zapeszać :>
      • 33: CommentAuthorat0mic
      • CommentTime28 Mar 2012 23:03 zmieniony
       
      odgrzewam kotlety i słucham:



      pocieszam się po przegranej:


      Atari 65 XE BCM (2224034172)
      Zakończona (śro 28 mar 2012 21:19:07 CEST)
      Najwyższa oferta: k...1 (224)
      Ofert:
      10
      Cena:
      Moje maksimum:
      132,50 zł
      130,00 zł


      jakiś k.... przebił mnie o 2,50 ...
      co za k.... koleś!!!!!

      zaraz chyba zdezasembluję your body k.....olo!
      lepiej się nie przyznaj że jesteś na AOL!

      Panowie - czy skończy się na emulatorze ?
      kurka siwa! i tak jest za każdym razem...
      • 34:
         
        CommentAuthorjhusak
      • CommentTime29 Mar 2012 00:03 zmieniony
       
      Ha.
      Skąd jesteś?
      Na Atari poluje się tak, że się poluje, ale nic na siłę.
      Pamiętaj: do Atari SIO2PC - 40 zł SIO2USB - 50 zł SIO2SD -130 zł, i jeszcze wyżej (SIDE, MYIDE, inne)

      Na pewno Ci się uda kupić Atari 65 XE za 40-50 zł.
      Ale widzę, że wysoko celujesz (pudełko Ci się marzy :)
      Z magnetofonem i działający (sprawdzony) 65 XE - 130zł to normalna cena.
      Podejdź do tego tak: jak Ci się znudzi, to sprzedasz. Tylko trzeba trochę oszczędzać, żeby się nie "zużył".

      Pocieszę Cię. Właśnie na serwisie aukcyjnym kupiłem XE GS za 270 zł. I niestety, ale rom mu już padł, ale jeszcze self test działa. Rom wymienię i komputerek jak ta lala. Pamięć RAm ma wporządku, tylko ten drugi bank ROM.

      Kupiłem też okazyjnie 130XE (bo nigdy nie miałem) i to działa bez pudła, ale pudło jest.

      A pomyśl tak. Kupił i na pewno ma padnięty GTIA. i POKEY nie działa. A magnetofon ma sparciałą gumkę...
      • 35: CommentAuthorat0mic
      • CommentTime29 Mar 2012 08:03
       
      no dobra - mieszkam w Otwocku 30km od W-wy i poznam kolegę który ma podobne hobby tzn. programowanie starych komputerów w assemblerze. u którego można pograć na Atari i potestować programy napisane z pomocą współczesnych komputerów.

      Tak naprawdę to tu gdzie mieszkam nawet nie wiem z kim pogadać o Atari albo Commodore. Z braku laku sobie PS1/PS2 kupię i zacznę rozgryzać.
      • 36:
         
        CommentAuthorlarek
      • CommentTime29 Mar 2012 08:03
       
      Tu masz "kup teraz" za 130zł ->link<-
      • 37: CommentAuthorat0mic
      • CommentTime29 Mar 2012 08:03
       
      za drogo, tamten miał magnet, nie był pożółkły i miał kardridge Turbo Blizzard.

      70 zł komp
      30 zł kardridge
      30 zł magnet

      kommodorka C64c + cart + magnet kupiłem za 75

      10 kart
      30 zł magnet
      35 zł komp - jak nówka - nie jest pożółkły od słońca (okazało się że SID walnięty)

      Atari cenię wyżej ale bez przesady
    38.  
      To ja mam jednak farta :) Skupiłem ostatnio z Allegro chyba ze cztery 800XL (żeby mieć dawców, jakby co), w tym jedno super-zadbane, za które zapłaciłem dość dużo. Ale pozostała trójka tanich, choć niektóre śmierdziały piwnicą albo strychem i były pożółkłe, poza spryskaniem klawiatury Kontaktem-S (co zresztą polecił jhusak) nie wymagały specjalnych prac :)

      I nawet działa w nich GTIA.

      PS. Teraz już wszystkie są zadbane :)

      PS2. Na pocieszenie dodam, że w poprzedniej firmie mieliśmy przy recepcji kontenerek na zużyte sprzęty. Pewnego dnia (parę lat temu) idę, patrzę, a tam 65XE... Więc ja go ciach i do domu. Nie muszę dodawać, że całkiem sprawny :)

      PS3. Gorzej z magnetami - tylko jeden z trzech mam całkiem sprawny. No ale SIO2SD jest nie do wykoszenia :)
      • 39: CommentAuthorat0mic
      • CommentTime29 Mar 2012 09:03
       
      kurka @mgr to skup jeszcze kolejne cztery - i powiem że wcale nie podnosisz ceny tym nadmiarowym popytem... :/
    40.  
      Inwestycja :) Za 20 lat może jeszcze na nich zarobię :D

      PS. Chciałbym mieć takie moce, żeby regulować ceny kompów na aukcjach :)
      • 41: CommentAuthorat0mic
      • CommentTime29 Mar 2012 10:03 zmieniony
       
      więc jednak emulator pozostaje
      • 42: CommentAuthorMaciek
      • CommentTime29 Mar 2012 21:03
       
      Spekulanci... Przysługuje po jednym Atari na głowę! No chyba że trzymacie jeszcze jeden egzemplarz dla syna jak podrośnie (albo córki, w posag, żeby za programowanie zabrał się zięć)

      Ja swoje oryginalne Atari z dzieciństwa rozwaliłem, potem kupiłem zadbane 130 XE z kartonem, wszystko jak nowe za 270 złoty. GTIA było zwalone, dodatkowy koszt 50 zł. Potem 800 XL za jakąś stówkę, potem SIO2SD za jakąś stówkę (wtedy jeszcze można było za stówkę mieć SIO2SD z kablem SIO, teraz widzę patrząc na allegro, że kabel stał się rarytasem wartym dodatkowe 30 zł, co za głupota). Potem przygotowałem ok 800 zł na VBXE i próbowałem je zdobyć przez kilkanaście miesięcy, wówczas nie wiedziałem, że wystarczy 300 i znajomości. Po drodzę dokupiłem spektrusia gumiaka za 200, telewizory kineskopowe za jakieś 200, trochę konsol 16stobitowych z flashcartami do programowania (ok 500 zł), a potem się ożeniłem i już długo sobie nic nie kupię.
      • 43:
         
        CommentAuthorjhusak
      • CommentTime29 Mar 2012 22:03
       
      @at0mic - no widzisz, a ja w Łomiankach, rzut beretem.

      Jakbyś coś zakupił i nie działało to coś może by się wykombinowało/wygrzebało.

      Tak nawiasem mowiąc to w Otwocku mieszka Krzyś Stec, ale teraz to on pewnie starszy pan jest.
      • 44: CommentAuthorat0mic
      • CommentTime30 Mar 2012 07:03 zmieniony
       
      ten inż. Krzysztof Stec który jest informatykiem w szpitalu i zakłada ludziom internet ?

      @jhusak

      jadąc Wałem Miedzeszyńskim to około 40 km mam do Ciebie - 47-65 minut drogi samochodem jak na warszawskie możliwości korkowe i światłowe nie jest źle bo myslałem że prędzej Cię spotkać na szlaku w górach :P

      a tu proszę blisko Dziekanów Leśny:


      kawał drogi masz do pracy... ile czasu Ci to zajmuje ?
      • 45:
         
        CommentAuthorjhusak
      • CommentTime30 Mar 2012 08:03 zmieniony
       
      Tak ten Stec.

      A pracuję w domu :) Otwieram oczy, biorę macbooka, pracuję, odkładam macbooka, idę spać. I tak codziennie (no, w oooooooolbrzymim skrócie).

      A tak na marginesie to jeszcze spotykamy się -od-czasu-do-czasu- na sztabach atarowskich. Info o sztabie z reguły dostarcza Gzynio na atari.org.pl i tutaj też :)

      Sztab to form(uł)a spotkania przy napojach rozluźniających i dyskusje o tym i owym.
      • 46: CommentAuthorat0mic
      • CommentTime30 Mar 2012 08:03
       
      wracając do tematu prania mózgu asemblerem:

      robię powiedzmy "symulację" spadania kamieni - narazie w basic ale trzeba f7 wciskać żeby przyspieszyć więc miło by było w asm tylko nie chce mi się pisać zbyt długo więc pytanko jak w asm zrobić GR.X ?

      podejrzewam że LDA#$ coś i JSR$ gdzieś ale nie wiem gdzie i szkoda czasu na szukanie jeśli ktoś wie i będzie chciał odpisać to z góry dziękuję.
    47.  

      at0mic:

      jak w asm zrobić GR.X ?

      Trzeba "ręcznie" utworzyć sobie Display Listę, czyli program dla ANTICa.

      Trochę informacji tutaj:
      ->link<-
      • 48: CommentAuthorat0mic
      • CommentTime30 Mar 2012 10:03
       
      tak to potrafię już
      • 49: CommentAuthormono
      • CommentTime30 Mar 2012 10:03
        
      grx: ldx #IOCB1  ;$10
        lda #OPEN ;3
        sta ICCOMD,x
        lda #<sname
        sta ICBUFA,x
        lda #>sname
        sta ICBUFA+1,x
        lda #%1100    ;b2=odczyt,b3=zapis,b4=brak okna tekstowego,b5=nie czyszczenie pamięci ekranu
        sta ICAX1,x
        lda #MODE     ;nr trybu graficznego
        sta ICAX2,x
        jsr JCIOV
        bmi error
        ...
      sname: .db 'S:',EOL ;$9b

      Oczywiście ekran otwierany jest procedurą OSa a więc tuż pod RAMTOP.
      • 50:
         
        CommentAuthorKaz
      • CommentTime30 Mar 2012 13:03 zmieniony
       

      atomic:

      za drogo, tamten miał magnet, nie był pożółkły i miał kardridge Turbo Blizzard.

      70 zł komp
      30 zł kardridge
      30 zł magnet

      kommodorka C64c + cart + magnet kupiłem za 75

      10 kart
      30 zł magnet
      35 zł komp - jak nówka - nie jest pożółkły od słońca (okazało się że SID walnięty)

      Atari cenię wyżej ale bez przesady


      Ale Atari jest wyceniane wyzej nie dlatego, ze ludzie sa pazerni czy ze nastapila jakas zmowa, tylko dlatego, ze jest ich ZNACZNIE mniej na rynku. Pewnie nie raz slyszales, ze C-64 byl najlepiej sprzedajacym sie 8-bitowcem. Natluczono tego kilkanascie milionow egzemplarzy (Wiki podaje 17 milionow) i dlatego jego wartosc jest taka, a nie inna. 8-bitowego Atari wyprodukowano znacznie mniej, a z tego sporo sprzetu to seria 400/800, a nie XL/XE, o ktora Ci chodzi. Sam wiec rozumiesz...

      PS. Starego Jaguara tez nie dostaniesz w takiej samej cenie jak starego Fiacika 126p :), wszystko kwestia dostepnosci.

    Od 101 do 150 z 226

    1. <
    2. 1
    3. 2
    4. 3
    5. 4
    6. 5
    7. >