atarionline.pl 130XE - napad na banki - 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  »   130XE - napad na banki

    W dół

    Od 1 do 25 z 25

    1.  
      • 1:
         
        CommentAuthormgr_inz_rafal
      • CommentTime21 Sep 2013 01:09 zmieniony
       
      Zatem siedzę sobie i knuję, jak tu wczytać coś do pamięci rozszerzonej. Sprawa wydaje się prosta: wrzucam do PORTB taką wartość:
      %10000011
      Ładuję pliki pod $4000, następnie do PORTB wrzucam
      %10110011
      I już mam z powrotem pamięć bazową.

      Wszystko działa dobrze i właściwie mógłbym już od jakiegoś czasu spać... ale:

      Robię próbę z drugim bankiem: %10000111 - tu też działa dobrze.

      Podobnie z trzecim: %10001011 - też wszystko jest OK.

      No to zostaje jeszcze czwarty: %10001111 - i tutaj ZONK. Bank się podmienia, ładuję plik, przywracam pamięć bazową, ale potem już nie mogę odczytać innych plików (wykonanie OPEN na CIO leci w kosmos).

      Myślę sobie, mniejsza o to, nie potrzebuję czwartego banku. Ale czytam dalej i widzę, że MADS ładnie pomaga w obsłudze banków. Wołam więc JSR @MEM_DETECT i w A dostaję 4 - so far so good.

      Próbuję zatem "uruchomić" czysty bank:
      ldy #0
      lda @TAB_MEM_BANKS+1,y
      sta PORTB

      Ładuję do niego poprawnie plik, ale znowu po powrocie do pamięci bazowej CIO przestaje działać :/

      Okazuje się, że MADS pod indexem 0 trzyma bank #4 ($EF = 11101111). Zmieniam więc w powyższym kodzie ldy #0 na ldy #1, co powoduje wybranie banku #3 ($EB = 11101011). I znowu wszystko działa :)

      Niby mogę iść spać, ale coś mi nie daje spokoju, więc mówię - napiszę na forum. Może ktoś wytłumaczy co może mieć wspólnego włączenie i wyłączenie banku %11 z późniejszą obsługą CIO :)

      PS. Zmiana bitu 5 nie zmienia powyższego zachowania.
      PS2. Próbę robię na Altirze, emulującej 130XE
      PS3. Napadami na banki zajmuję się dopiero od 2 godzin, wybaczcie jeśli popełniłem powyżej jakieś herezje :)
      • 2: CommentAuthormuffy
      • CommentTime21 Sep 2013 02:09 zmieniony
       
      a nie wyłączasz czasem ROMu ? No bo jak OPEN ma potem zadziałać?
      -------
      edit: albo na masz pozamienianą kolejność w sparcie :)
      • 3: CommentAuthorxxl
      • CommentTime21 Sep 2013 08:09
       
      heh. dzieje sie tak poniewaz uzywasz sparta dos, ktory prawdopodobnie tak zostal u Ciebie skonfigurowany, ze alokuje bank rozszerzenia pamieci. a poniewaz na atari nie ma standardu rozszerzenia pamieci, dodatkowo konfig sparty moze byc rozny musisz napisac sobie procke ktora z listy dostepnych bankow rozszerzonej pamieci usunie banki (nie koniecznie jeden) ktore zajmuje sparta. dopiero ta informacja pozwoli dobrze podmieniac banki - ale nie w sposob ktory pokazales bo to tez niestety nie musi dobrze dzialac pod sparta i niektorych konfigach. jesli ta rada okazala sie pomocna i z niej skorzystasz to wiedz, ze uzalezniles dzialanie swojego programu juz nie tylko od filesystemu ale takze od wersji samego dosa.

      mam nadzieje zabawa z "systemem" nie zabije w Tobie ducha i skonczysz ta gre :-)
      • 4: CommentAuthortebe
      • CommentTime21 Sep 2013 09:09 zmieniony
       
      BIBLIOTECZKA KODERA ->link<-

      detekcja banku zajmowanego przez SDX
      ->link<-
      • 5: CommentAuthorwieczor
      • CommentTime21 Sep 2013 10:09
       
      uzalezniles dzialanie swojego programu juz nie tylko od filesystemu ale takze od wersji samego dosa


      "Uzależniłeś od" a "dostosowałeś do" to jest pewna różnica. Przy umiejętnym dostosowaniu będzie działać jak trzeba - wszędzie ;-)

      mam nadzieje zabawa z "systemem" nie zabije w Tobie ducha i skonczysz ta gre :-)


      Duch upada gdy się próbuje często bezskutecznie zrobić coś, bez uprzedniego studiowania dokumentacji ;-)
      • 6:
         
        CommentAuthormgr_inz_rafal
      • CommentTime21 Sep 2013 14:09 zmieniony
       
      Dzięki, link od Tebe rozwiązał problem.

      Iście Spartańskie warunki do kodowania :)

      xxl:

      ale nie w sposob ktory pokazales bo to tez niestety nie musi dobrze dzialac
      Jaki sposób jest lepszy?

      xxl:

      mam nadzieje zabawa z "systemem" nie zabije w Tobie ducha i skonczysz ta gre :-)
      No problem, gra przecież będzie działać i bez tych dodatkowych banków. Pełnią one tutaj rolę taką jak majonez przy frytkach - przydatny, ale można się bez niego obejść (objeść).

      wieczor:

      Duch upada gdy się próbuje często bezskutecznie zrobić coś, bez uprzedniego studiowania dokumentacji ;-)
      Jak będę czytał dokumentację zamiast tworzyć, to zostanę mega teoretykiem bez dorobku gierkowego :) Wolę jednak eksperymentować i czasami podpytać na forum o konkretne rzeczy.

      I na koniec jeszcze pytanie ogólne:
      Nie ma chyba dobrego sposobu na te banki, nie? Teraz akurat wykluczam z listy dostępnych banków ten zajmowany przez Spartę, ale przecież tam może równie dobrze być jakiś ramdysk, czy coś... Albo ktoś skonfiguruje Spartę, żeby zajmowała siedem banków :/

      Jeśli dobrze rozumiem, to w tym przypadku xBios może być dobrym lekarstwem? Bo nie ma OSa (nic więc nie siedzi w bankach), a jest I/O.

      Alternatywnie, czy przed grą trzeba zrobić jakiś setup z wybieraczką banków? To byłaby tragedia dla normalnych userów :)

      Albo może jeszcze metoda na młotek? Tzn. napisać w wymaganiach gry, że potrzebny jest bank 0 i 1 i jak ktoś chce pograć, to musi sobie odpowiednio przekonfigurować OSa :)

      Co o tym myślicie?
      • 7: CommentAuthormuffy
      • CommentTime21 Sep 2013 15:09
       
      Najprostsze rozwiązanie: napisz tak by działało na każdym atari z 64 kb i ani grama więcej :D
      Po uruchomieniu wywal rom, nadpisuj sobie na DOSa itp.
      W końcu to będzie gra a nie program użytkowy ;)
      Jak brakuje pamięci to sobie popakuj co trzeba, wtedy mieści się wszystko nawet w jednej binarce, którą raz załadujesz z dowolnego (prawie) dosa.
      • 8: CommentAuthorwieczor
      • CommentTime21 Sep 2013 15:09
       
      Albo może jeszcze metoda na młotek? Tzn. napisać w wymaganiach gry, że potrzebny jest bank 0 i 1 i jak ktoś chce pograć, to musi sobie odpowiednio przekonfigurować OSa :)

      Co o tym myślicie?


      To - oprócz wybieraczki banków, zauważ że jest to wymaganie na compo dla każdego dema które używa exta - też jest dobre rozwiązanie. Albo wymaganie, że Sparta ma nie używać banków. Spokojnie można je postawić.
    9.  
      OK, w takim razie na chwilę obecną pozostanę przy tym rozwiązaniu, które zrobiłem.

      Wieczorem zamieszczę filmik pokazujący jak gra działa na 130XE. Przyspieszenie, mierzone zegarkiem Montana, jest niemal trzykrotne.

      Wiem, że teoretycznie powinno być dużo większe, jednak ja nie buforuję w RAMie leveli (te nadal są doczytywane), tylko pewne elementy służące do ich zbudowania. Dzięki temu właściwie jeden bank ext-ramu wystarczy, żeby szybko działać nawet z ogromną ilością plansz.
      • 10:
         
        CommentAuthortdc
      • CommentTime21 Sep 2013 17:09
       
      Odnośnie tego wątku i innych to programiści mają swoje ulubione DOSy, sparta do nich nie należy. To znaczy jest bardzo fajna ma memlo fajne i ogólnie jest niegłupia, ale właśnie kombinuje z bankami pamięci. Jednym słowem wymusza konkretne zachowanie jeśli chcemy korzystać z dodatkowej pamięci.

      Z drugiej strony przy programowaniu gier czy ich używaniu tak duży DOS nie jest nikomu potrzebny, dlatego można od razu porzucić armatę i użyć pistoletu. Tak wielu koderów robi i za nic mają zalecenia sparty. Nie jest może to zachowanie, które należy chwalić, no ale właśnie taka jest praktyka.

      Dosem po który często się sięga (i wiele kodu w nim powstało) jest DOSa II+/D v6.4, jednak ma on wiele błędów pod tym względem jest dużo gorszy od sparty. Zaletą jego jest niewielki rozmiar, szybkie bootowanie, fantastyczne skróty, które nawet sparta może pozazdrościć i kilka drobnych unikalnych fjuczerów.
      • 11: CommentAuthorwieczor
      • CommentTime21 Sep 2013 17:09
       
      Mała poprawka - oczywiście nic takiego nie ma miejsca jeśli poprawnie napiszemy config DOSa. Sparta po prostu ma tę możliwość aby użyć pamięci rozszerzonej do swoich procedur, ale oczywiście nie ma takiego przymusu. Polecam ten oto manual

      ->link<-

      (uwaga, jest parę literówek) i już wszystko się zachowuje jak sobie życzymy.
      • 12: CommentAuthorbob_er
      • CommentTime21 Sep 2013 19:09
       
      pozwolicie, że się wtrącę:
      1. Coponiektórzy uważają mnie za kodera, i przyznam szczerze - sparta jest moim ulubionym dosem. właśnie dlatego, że memlo niskie i kilka bajerów. Wiec prośba do coponiektórych - proszę nie uogólniać. Napiszę więcej - jak ktoś chce coś pisać pod OS, to sparta jest bardzo dobrym wyborem dla kodera: ze względu na proste I/O, symbole i parę funkcji bibliotecznych.
      2. 130xe - przypominam, że dema wymagające 128k ramu _NIE_MAJĄ_ bank selectora (albo przynajmniej takiego nie kojarzę). 128k jest _STANDARDEM_ i tu nie ma co filozofować.
      3. A nie wystarczy na dysku dać dosa od BeweSofta - on chyba z ext ramu nie korzysta, i nie przejmować się że coś bank zajmie?
      4. W ramach świętych wojen i punktu 1: ->link<- - sparta only :D
    13.  
      Spartę wybrałem ze względu na fajny system plików (dyskutowany w innym wątku). Nie korzystam z żadnych specyficznych dla Sparty funkcji (np. wyszukiwania w pliku). Docelowo gra będzie dostarczona na dyskietce wraz z DOSem - albo Spartą albo BeWe. Zobaczymy :)
      • 14: CommentAuthorbob_er
      • CommentTime21 Sep 2013 20:09
       
      Czytałem, kojarzę tamten wątek. Stąd właśnie punkt 3. Być może właśnie BeweDos (czy jak on tam się zwie) będzie ok. Ramdyski powywalasz, a system plików i urządzenie D: masz. Jak program kulturalny, to z innym dosem zadziała, a jak zrobisz z tego jeden (cało)dysk to dla większości userów/graczy i tak będzie przeźroczyste, co tam pod spodem siedzi.
    15.  
      Na końcu tego posta obiecany filmik z gierki, w której dodałem preload niektórych danych do pamięci rozszerzonej. Blackouty między planszami zostały zredukowane mniej więcej do tych z gry Ninja. Dodatkowo nie trzeba też czekać na I/O w momencie "badania" rzeczy, np. spłuczki.

      Takie przyspieszenie udało się uzyskać buforując tylko nieco ponad 2kb danych (dokładnie 2035 bajtów).

      Pozwala to na zrobienie naprawdę ogromnej gry... Niestety wymagającej pewnej cierpliwości od graczy ze stock 64kb.

      • 16: CommentAuthorxxl
      • CommentTime22 Sep 2013 08:09
       
      Takie przyspieszenie udało się uzyskać buforując tylko nieco ponad 2kb danych (dokładnie 2035 bajtów).


      to jest mniej niz 2kb (2048). moze jednak wystarczy atari 64k a te 2kb trzymaj w pamieci MapRAM :)

      a wlasnie... wykorzystujesz ram pod romem?
    17.  
      Bardzo ładna gra:-) . Nic dodać nic ująć .:-)
    18.  

      xxl:

      to jest mniej niz 2kb (2048)
      Racja. Sorry, późno było :)

      xxl:

      moze jednak wystarczy atari 64k a te 2kb trzymaj w pamieci MapRAM
      Do MapRAM potrzebna jest chyba lutownica, więc odpada :) Buforowanie na Atari 64k byłoby możliwe jeszcze przez chwilę, dopóki gra się nie rozrośnie. Później buforować będę więcej niż 2kb, ale raczej nie tyle, żeby przekroczyć jeden bank (no może dwa, jeśli zbuforuję fonty).

      xxl:

      a wlasnie... wykorzystujesz ram pod romem?
      Hmm, pewnie nie, bo nie wiem o co chodzi ;-)
      • 19: CommentAuthorwieczor
      • CommentTime22 Sep 2013 12:09
       
      Hmm, pewnie nie, bo nie wiem o co chodzi ;-)


      To zanim sięgniesz do banku, sprawdź kieszenie :) Chodzi o to czy wykorzystujesz 64k RAMU czy tylko 40-48 z pamięci podstawowej
      • 20: CommentAuthorbob_er
      • CommentTime22 Sep 2013 12:09
       
      Chodzi o obszar C000-CFFF oraz D800-FFFF. Jak wywalisz ROM, to masz tam RAM (to się robi w tym samm rejestrze co banki). Musisz tylko własne przerwania napisać, bo jak włączysz RAM, to już ich tam nie ma (procedur do obsługi).
      Więc nie 64k a 62 jak już.
      Dostęp do pozostałych 2k to już MapRAM.
    21.  
      Obecnie jadę od $2000 i chcę się zmieścić przed $C000 - czyli w 40kb. Jak zacznie mi brakować pamięci, to dopytam Was o ten "RAM pod ROM" :)
      • 22: CommentAuthorxxl
      • CommentTime22 Sep 2013 13:09
       
      jesli by byla taka mozliwosc to wykorzystaj ram pod rom zamiast banku 130xe.

      MIR korzysta z systemu wiec nie trzeba mu pisac obslugi przerwan, wystarczy na czas dostepu do tej pamieci wylaczyc przerwania a po pobraniu odpowiednich danych wlaczyc rom i odblokowac przerwania.

      sei
      lda #$00
      sta nmien
      lda #$fe
      sta portb

      teraz masz ram zamiast rom


      lda #$ff
      sta portb
      lda #$c0
      sta nmien
      cli

      i znowu rom

      mozna to napisac inaczej ale chodzi o sama idee.
      • 23:
         
        CommentAuthortdc
      • CommentTime22 Sep 2013 16:09
       
      xxl mądrze prawi, to jest taki myk z wyłączeniem przerwań niemaskowalnych (:D). Mimo że brzmi to dziwnie to właśnie na czas budowania levelu dajesz pierwszą część kodu (tą z sei) budujesz level a potem włączasz (to z cli) i normalnie uruchamiasz grę. Chodzi o to że podczas budowania levelu nie są tobie potrzebne przerwania odtwarzanie muzyki itp. więc wszystko się zgadza a dodatkowo masz więcej pamięci.
      • 24: CommentAuthormono
      • CommentTime23 Sep 2013 13:09
       
      Przerwania IRQ i flaga I to dwie różne bajki.
      Za fizyczne blokowanie przerwań IRQ odpowiadają rejestry:
      - IRQEN ($D20E)
      - PACTL ($D302)
      - PBCTL ($D303)
      Jeśli przerwanie IRQ wymaga obsługi i nie jest zablokowane, wtedy żądanie jego obsługi odnotowywane jest w rejestrze statusu:
      - IRQST ($D20E)
      - PACTL ($D302)
      - PBCTL ($D303)
      Dzieje się to NIEZALEŻNIE od stanu znacznika procesora I.
      Po ustawieniu I (sei) CPU po prostu chwilowo nie będzie reagował na żądania przerwań IRQ, ale odpowiednie flagi nadal będą ustawiane w rejestrach statusów IRQ. Po skasowaniu I (cli) jeśli w międzyczasie jakiekolwiek przerwanie IRQ nadeszło, CPU niezwłocznie przystąpi do jego obsługi. Może się więc okazać, że zaraz po cli wykona się seria procedur obsługujących przerwania, które w międzyczasie nadeszły (tak naprawdę praca na zakładkę powoduje, że między obsługą kolejnych przerwań CPU wykona zawsze jeden rozkaz programu).
      Żądania IRQ cechują się tym, że są sygnalizowane od momentu wystąpienia aż do chwili, kiedy program sam nie powie: - ok - obsłużyliśmy - możesz przestać sygnalizować żądanie obsługi przerwania (w IRQEN trzeba zablokować przerwanie IRQ po czym ponownie na nie zezwolić).
      Konkludując - prawdziwe zablokowanie IRQ odbywa się tylko w rejestrach, operowanie znacznikiem I powoduje tylko odroczenie obsługi.
      • 25: CommentAuthorxxl
      • CommentTime23 Sep 2013 15:09
       
      zgadza sie, ale buforowanie irq nie jest takie zle :-)

      jesli juz by byla taka potrzeba to chyba przed zezwoleniem na irq wolalbym wykasowac zgloszenia niz wczesniej blokowac a pozniej ustawiac.

    Od 1 do 25 z 25

    1.