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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorgreblus
   • CommentTime22 Jan 2013 12:01 zmieniony

    
   Witajcie.
   
   Mam pytanie z gatunku "jak to się robi?".
   
   Włączanie do programu Action! wstawek w blokach [ ] przetestowałem i rozumiem, natomiast zastanawia mnie jak w praktyce dołączyć do skompilowanego programu w Action większe procedury assemblerowe?
   
   Rozdział "Assembly language in Action!" z reference manuala daje fajny przykład użycia CIO (Zientara w Tajemnicach Atari też go użył) ale nie mogę nigdzie znaleźć przykładu jak stworzyć własną binarkę z dołączoną procedurą assemblerową? Domyślam się, że potrzebny jest jakiś "loader", który załaduje procedurki pod zadany adres, a potem odpali program w Action!.
2. • 2:
      
     CommentAuthorjhusak
   • CommentTime22 Jan 2013 13:01 zmieniony

    
   1. Piszesz własne procedury w asm. Najlepiej, jak na początku stworzysz tablicę skoków do procedur (jmp p1), którą umieszczasz pod stałym adresem.
   
   W Action wpisujesz po prostu (o ile się nie kopnąłem, ale mniej więcej o to chodzi), np:
   
   PROC p1=$600
   PROC p2(byte w card z)=$603
   
   etc, o ile wektor procedur umieściłeś pod $600.
   
   Wywołujesz p1() p2(5,1000).
   
   W przypadku przesyłania do 3 bajtów argumentów utykane są one po rejestrach, chyba kolejno a,y,x, ale to trzeba sprawdzić. W swoich procedurach zakładasz, że w nich są parametry.
   
   To tak mniej więcej.
3. • 3: CommentAuthorgreblus
   • CommentTime22 Jan 2013 14:01

    
   Dzięki Jakub, ale męczy mnie jak połączyć binarkę swojego programu w Action! z procedurami w asm, tak żeby mieć to w jednym wynikowym pliku binarnym?
4. • 4:
      
     CommentAuthorjhusak
   • CommentTime22 Jan 2013 14:01 zmieniony

    
   cat
   
   No dobra :)
   
   mając plik binarny dosowy i plik wykonywalny w Action sklejasz je razem ze sobą (np. przy pomocy kota, czyli cat, pod linuxem lub OSXem lub unixem)
5. • 5: CommentAuthorgreblus
   • CommentTime22 Jan 2013 14:01

    
   O! Nie przypuszczałem że to takie proste :) Dzięki wielkie.
6. • 6:
      
     CommentAuthorinsert
   • CommentTime23 Jan 2013 00:01

    
   wiem ze nie na temat, ale moze komus sie przyda, blog czlowieka, ktory rozpracowauje programowanie w action:
   
   ->link<-
7. • 7: CommentAuthorMaciek
   • CommentTime23 Jan 2013 20:01

    
   Z całego wątku najbardziej zainteresowało mnie "wsadzanie w blokach [ ]". Czy dobrze rozumiem, że chodziło o wstawienie gołego asm w kod Action?
   Czy jest to możliwe? I czy jest to możliwe na jakimś natywnym Action na Real Hardware, a nie na fikuśnym kompilatorze na PC? Bardzo proszę o krótkie wyjaśnienie, od dłuższego czasu zastanawiam się nad nauką Action, wiem że można wywołać z niego procedurę binarną, ale jeśli da się pchać goły asm prosto w Action i to na prawdziwym Atari to rzucam wszystko i uczę się Action!
8. • 8: CommentAuthorgreblus
   • CommentTime23 Jan 2013 21:01 zmieniony

    
   Zobacz tutaj:
   ->link<-
   
   Cała biblioteka uruchomieniowa Action jest tak zrobiona.
   
   Jest też pseudo assembler, który potencjalnie mógłby trochę ułatwić:
   
   ->link<-
   
   Ja póki co nie znam kodu maszynowego 6502, nawet wszystkich mnemoników asm jeszcze nie spamiętałem :), więc kopiowałem sobie to z listingu generowanego przez madsa, albo z hexeditora dis6502.
9. • 9:
      
     CommentAuthortdc
   • CommentTime24 Jan 2013 03:01 zmieniony

    
   @Maciek
   
   Tak, właśnie w Action! jest możliwe wstawienie nie tyle asemblera co faktycznie "goły" kod, co wiele osób uważa za wadę - choć wymagałoby to dodania dodatkowego banku pamięci ROM czyli koszt carta poszedłby do góry (coś za coś - jak to w życiu:P).
   
   Kiedyś na AOL omawialiśmy szybką procedurę Plot w Action! ale obecnie ten artykuł się nie otwiera z powodów problemów technicznych serwisu :/
   Tu link, jak zacznie kiedyś działać: ->link<-
   
   Nie trzeba peceta, wystarczy real Atari i można kodować (szczególnie że zacytowany tu kod pochodzi właśnie z czasów świetności Atari w PL).
   
   Co do nauki Action! to polecam to głównie w małych programach, do dużych to można mieć spore kłopoty, co sprawdziłem na sobie.
   
   

   Maciek:

   pchać goły asm prosto w Action i to na prawdziwym Atari to rzucam wszystko i uczę się Action!

   
   W mojej ocenie chyba bardziej chcesz się uczyć asma, bo co to będzie za Action! skoro będziesz ciągle wstawiał kody rozkazów procesora ?;)
   
   Powodzenia, w nauce, służymy pomocą.
10. • 10: CommentAuthorgreblus
    • CommentTime24 Jan 2013 10:01 zmieniony

     
    @tdc:
    
    Mógłbyś napisać coś więcej o tych kłopotach? Na co uważać i w czym jest problem? Teoretycznie nie powinno być przeciwwskazań do pisania w nim dużych rzeczy, ale coś w tym jest. Od 83 roku trochę czasu upłynęło a poza bardzo pozytywnymi recenzjami (i miłym pierwszym wrażeniem jak się człowiek zaciekawi tematem) mało co w Action! powstało.
    
    Update: Lista błędów nieco przeraża:
    ->link<-
    
    Pytanie na ile jest ona kompletna?
11. • 11: CommentAuthoruser removed
    • CommentTime24 Jan 2013 12:01

     
    To ja z innej beczki w czym sie pisze/pisalo duze gry typu Montezuma, dwie wieze czy miecze waldgira ?
    Czy to czysty ASM czy ACTION! czy cos innego ?
    Pozdrawiam
12. • 12: CommentAuthorVidol
    • CommentTime24 Jan 2013 14:01 zmieniony

     
    Miecze i Dwie wieze byly pisane w asm.
    W Action Problem Jasia, Super Fortuna.
    Byly tez gry w basicu jak Roderic. Warto jeszcze wspomniec o Klatwie i Wladcach ciemnosci ktore byly pisane w Forth.
13. • 13: CommentAuthoruser removed
    • CommentTime25 Jan 2013 13:01

     
    Taka ciekawostka
    ->link<-
14. • 14: CommentAuthorMaciek
    • CommentTime25 Jan 2013 21:01

     
    Chcę mieć po prostu opcję swobodnego przejścia na asm w newralgicznych momentach. Mówicie o tym asm w Action tak dookoła trochę więc podejrzewam, że nie jest to możliwe. Takie mam kompilatory do Segi Mega Drive, piszę w C lub basicu i mogę gdziekolwiek w kodzie wrzucać gołe mnemoniki M68K jeśli potrzebuję, marzy mi się coś takiego na Atari...
15. • 15: CommentAuthorgreblus
    • CommentTime28 Jan 2013 15:01 zmieniony

     
    Postanowiłem sprawdzić, czy można zamiast POKE i PEEK używać wskaźników. Poniższy kod działa z cartem, ale nie działa "standalone" jeśliby chcieć go skompilować z którymkolwiek runtime (najlepsze efekty daje runtime Jeffa Reistera, same zera zamiast display listy, a z pozostałymi emulator się krzaczy):
    
    INCLUDE "H1:RUNTIME.ACT"
    PROC MAIN()
    
    BYTE POINTER DL = 560^
    INT I=[1]
    
    GRAPHICS(0)
    PRINTE()
    
    DO
    PRINTF("%I ", DL^)
    I==+1
    DL==+1
    
    UNTIL I=40
    OD
    
    DO OD
    RETURN
    
    Jest jakiś znany babol w runtime związany ze wskaźnikami?
    Tak swoją drogą, zdziwiłem się że ^ działa nie tylko ze wskaźnikami...
    
    No i ciekawe że nie musi tam być czegoś w stylu:
    
    CARD DL1 = 560
    BYTE POINTER DL2 = DL1^
    
    Skąd kompilator wie, że w tej linii:
    
    BYTE POINTER DL = 560^
    
    chodzi o wartość adresu w dwóch bajtach pozostaje dla mnie tajemnicą :)
    
    UPDATE:
    
    Jeśli wskaźnik zdefiniuje w ten sposób:
    
    CARD DL=560
    BYTE POINTER DLP
    DLP=DL
    
    to działa po kompilacji z RT.
    
    BYTE POINTER DLP = DL nie może być...
    
    BYTE POINTER DLP = DL^ działa z cartem, nie działa (same zera) standalone.
16. • 16:
       
      CommentAuthortdc
    • CommentTime28 Jan 2013 17:01 zmieniony

     
    @greblus
    
    Nie wiem czy RT ma błędy we wskaźnikach, ale wiem:
    1. RT mają poważne błędy i wywołanie niektórych procedur z RT powoduje brak stabilności lub inne dziwne rzeczy (patrz przygotowanie uruchamialnej wersji Warsaw City, albo błąd w procedurze obsługującej dżojstik w RT - co zgłosił kiedyś Sikor w Panga Ponga, że błąd jest widoczny tylko na real Atari, a na emu jest wszystko ok).
    
    2. Kiedyś w Mirage dostaliśmy źródło jednego z potem wydanych programów, w którym była masa operacji na wskaźnikach. Mieliśmy dojść dlaczego program nie działa a następnie wydać go. Źródło było duże więc nikt nie doszedł do tego co było problemem, więc albo autorzy zrobili jakiś błąd albo już w samym Action! bez RT są jakieś trudne do wykrycia błędy ze wskaźnikami - ale podkreślam nikt z nas nie dał rady do tego dojść bo sprawdzanie cudzego źródła jest bardzo nieciekawym zajęciem.
    
    

    greblus:

    Tak swoją drogą, zdziwiłem się że ^ działa nie tylko ze wskaźnikami...

    
    To akurat zaleta, którą można fajnie wykorzystać.
    
    

    greblus:

    Skąd kompilator wie, że w tej linii:
    
    BYTE POINTER DL = 560^
    
    chodzi o wartość adresu w dwóch bajtach pozostaje dla mnie tajemnicą :)

    
    To naturalne dla wskaźników, bo tzw. zmienna wskaźnikowa nigdy nie przechowuje wartości, zawsze przechowuje adres i tylko adres (jest jeszcze typ).
17. • 17: CommentAuthorgreblus
    • CommentTime28 Jan 2013 21:01

     
    W takim razie szkoda, wskaźniki wyglądały obiecująco.
    
    Co do przykładu:
    CARD DL1 = 560
    BYTE POINTER DL2 = DL1^
    jest łatwiejsze w interpretacji: DL1 jest typu CARD więc wiadomo na co wskaźnik pokazuje, a w przypadku:
    BYTE POINTER DL = 560^ nie mam pojęcia dlaczego to działa, BYTE to BYTE...
    
    Wychodzi na to, że moja zabawa w kompilowanie z runtime ma sens - wiadomo potem czego unikać :)
    Wydawało mi się, że gdzieś trafiłem na program, który tworzy runtime na podstawie carta, ciekawe czy to by działało lepiej.
18. • 18: CommentAuthorBartoszP
    • CommentTime28 Jan 2013 22:01

     
    Może to pomoże: ->link<-
19. • 19: CommentAuthorgreblus
    • CommentTime1 Feb 2013 14:02

     
    Kolejny kamyczek do ogródka tajemniczości Action! Niech mi ktoś powie, dlaczego to nie działa po kompilacji z RT:
    
    include "H1:RUNTIME.ACT"
    proc main()
    int i,v
    card dlist=560
    byte array dltb=[ 112 112 112 66 96 159 72 112 158
    8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
    8 8 8 8 65 78 158 ]
    graphics(3)
    for i=0 to 32 do
    v=dltb(i)
    poke(dlist+i, v)
    od
    print("Action!")
    setcolor(2,4,6)
    color=1 plot(0,0) drawto(10,10)
    color=3 plot(12,12) drawto(19,0)
    do od
    return
    
    Kombinuję i kombinuje i nic...
20. • 20:
       
      CommentAuthorinsert
    • CommentTime1 Feb 2013 14:02

     
    ja wlasnie dla tego miliona zagadek odpuscilem sobie action :/ a szkoda bo ciekawy jezyk, tak samo szkoda effectusa :/
21. • 21: CommentAuthorwieczor
    • CommentTime1 Feb 2013 14:02

     
    Język jest tylko językiem. Kod wynikowy to kwestia kompilatora. Mógłby się ktoś podjąć napisania nowego kompilatora - nie wymagającego koniecznie carta (a np. rozszerzonej pamięci) i generującego kod standalone z tymi tylko elementami biblioteki, które są użyte w kodzie (bez konieczności targania ze sobą całego runtime library).
    
    Może nawet cross-platform (np. kompilator na PC)? Mogłoby powstać naprawdę fajne narzędzie do pisania super wydajnego kodu w języku wysokiego poziomu.
22. • 22: CommentAuthorgreblus
    • CommentTime1 Feb 2013 15:02

     
    A ja póki co nie chcę odpuszczać :). Jest mnóstwo ciekawych książek o Atari z przykładami w Basicu, które da się przetestować niemal 1:1 w Action! i jest to na pewno przyjemniejsze od robienia tego samego w asm. Kto wie, może będzie się kiedyś dało odpalić obraz carta Action! z U1MB (nadzieja matką wynalazców jak to mówią). Wiem, że to nie to samo co możliwość kompilacji i użycia bez carta, ale zawsze daje możliwość poznania i przetestowania na real hardware Atari...
    
    Carsten Strotmann jest dla mnie żywym dowodem że można używać Action! i może da się go jakoś "ogarnąć".
23. • 23: CommentAuthorwieczor
    • CommentTime1 Feb 2013 15:02

     
    Nie chodzi mi o to aby obraz carta pakować do ultimate - po co, Kuba opracował wersję dla SIC. Chodzi mi o zrobienie normalnego kompilatora. Takoż np. dla Basic XE.
24. • 24:
       
      CommentAuthorinsert
    • CommentTime1 Feb 2013 15:02

     
    wieczor. cos o czym piszesz juz dawno istnieje i nazywa sie Effectus :)
25. • 25: CommentAuthorgreblus
    • CommentTime1 Feb 2013 15:02

     
    Nie mam SIC a w U1MB jest sporo miejsca, które się marnuje :)
26. • 26:
       
      CommentAuthortdc
    • CommentTime1 Feb 2013 18:02 zmieniony

     

    greblus:

    include "H1:RUNTIME.ACT"
    proc main()
    int i,v
    card dlist=560
    byte array dltb=[ 112 112 112 66 96 159 72 112 158
    8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
    8 8 8 8 65 78 158 ]
    graphics(3)
    for i=0 to 32 do
    v=dltb(i)
    poke(dlist+i, v)
    od
    print("Action!")
    setcolor(2,4,6)
    color=1 plot(0,0) drawto(10,10)
    color=3 plot(12,12) drawto(19,0)
    do od
    return
    
    Kombinuję i kombinuje i nic...

    
    Bez większego wczytywania się w ten kod:
    1. Zależy którego RT używałeś, bo jeden z nich ma błąd w procedurze graphics() (oficjalnie, jest opisany itp.), więc to może ten błąd.
    
    2. Odradzam używania bibliotecznego "print()" on czasami się potrafi wykładać w różnych RT itp. Z mojego doświadczenia gdy się z kodu wywali: graphics(), printy, plot(), drawto() (może jeszcze locate()) to kod będzie ładnie działał ze wszystkimi odmianami RT. Jeśli nam baardzo zależy na którejś z tych procedur to należy najpierw sprawdzić jak się zachowuje np. dana odmiana print w danym wypadku, jak zadziała to można próbować lecieć dalej. Najlepiej zachowuje się print (choć nieidealnie) w czymś takim co się nazywa "Action library" jednak ten program dołącza całą bibliotekę Action! więc w większych programach traci się sporo wolnej pamięci.
    
    3. Atari w odróżnieniu od innych komputerów jest tak skonstruowane, że nie trzeba używać graphics.
    
    4. Skoro znasz się na dl to tym bardziej nie ma co w tym programie używać graphics, bo sam już wpisałeś kody dl i wystarczy je jedynie użyć (jeśli chcesz używać systemowych i bibliotecznych procedur rysujących to trzeba jeszcze ustawić systemowe adresy jak np. 88 itp.)
    
    5. Nie trzeba nic przepisywać w pętli pokami z "dltb" taką tablicę można od razu użyć (problemem może być jedynie jeśli skompilowany kod gdzie umieszczona zostanie ta tablica znajdzie się na skraju (wytrzymałości) adresowania ANTICa - wtedy do czasu przesunięcia się kodu zawartość obrazu nie będzie wyświetlana prawidłowo. Takie przesunięcia się w Action! często zdarzają bo kod źródłowy jest przed wygenerowanym kodem (po kompilacji) więc wystarczy wstawić kilka znaków w edytorze aby kod wygenerowany się przesunął; rozwiązaniem może być przykładowo użycie na początku programu dyrektywy SET która przesunie kod pod inny adres)
    
    6. i na koniec skoro "card dlist=560" to dlaczego "poke(dlist+i, v)" ??
    
    
    

    insert:

    wieczor. cos o czym piszesz juz dawno istnieje i nazywa sie Effectus :)

    
    Tak istnieje, ale podobnie jak inne podobne projekty nie jest jeszcze na tym etapie aby stanowić alternatywę.
27. • 27: CommentAuthorgreblus
    • CommentTime1 Feb 2013 19:02

     
    @tdc: dzięki! O taką motywację do zabawy Action! mi chodziło, bo niestety ma w necie wielu wskazówek pokazujących jak to się robi w Action!
28. • 28:
       
      CommentAuthortdc
    • CommentTime1 Feb 2013 19:02 zmieniony

     
    Tak język ten przez długi czas był niszowy i właściwe nadal jest;)
    
    Odnośnie motywacji Action! to proponuję abyś napisał własne procedury: graphics, print/position, plot i drawto (przynajmniej do trybów których masz zamiar używać), bo wtedy Action! dostaje porządnego kopa i zbliża się wydajnością do asm oraz wyprzedza wszystkie inne języki programowania na Atari i innych 8bitowcach.
    
    Jak się domyślasz te biblioteczne/systemowe procedury są bardzo powolne i pomimo tego że szybsze niż w Basicu to wiele się z nimi nie da zrobić.
29. • 29: CommentAuthorwieczor
    • CommentTime2 Feb 2013 05:02

     
    Nie wiedziałem o Effectusie - fajnie że powstaje to jako preprocesor do MADSa - połowa roboty z głowy no i możliwość ingerencji w assemblowany kod po drodze. Moim zdaniem z tego co widzę, jest dość zaawansowany i do stania się alternatywą aż tak dużo nie brakuje - o ile oczywiście ktoś nadal nad tym pracuje :? Ja bym może i się pobawił trochę, bo na parserach/kompilatorach trochę się znam ale są dwie przeszkody: za bardzo zapomniałem assembler Atari i sprzęt od środka - za słabo znam Action! Jednak perfekcyjna znajomość języka dla którego się pisze kompilator jest nieodzowna, zwłaszcza jeśli chce się (a trzeba) zachować pełną kompatybilność czyli odwzorować wszystkie kruczki, których nie znajdzie się w dokumentacji...
30. • 30: CommentAuthorgreblus
    • CommentTime3 Feb 2013 23:02 zmieniony

     
    Kombinując dalej doszedłem to wniosku, że problem niedziałania printów, plotów i drawto po zdefiniowaniu własnej dlisty wynika z faktu, że adres początku ekranu i początku tekstu zmienia się po "wyjęciu" cartridge Action (założenie jest takie, że binarka skompilowana z runtime ma działać bez carta).
    
    Wystarczy podać te adresy z displaylisty w tym przypadku w dwóch zmiennych (thnx tdc) i działa jak trzeba:
    
    include "H1:RUNTIME.ACT"
    proc main()
    byte key=764
    card savmsc=88 ; tu siedzi początek pamięci grafiki
    card textaddr=660 ; a tu początek pamięci tekstu
    byte array dltb=[ 112 112 112 66 96 159 72 112 158
    8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
    8 8 8 8 65 78 158 ]
    card dlist=560
    graphics(3)
    dlist=dltb ; użycie dlisty, o którym pisał tdc :)
    textaddr=40800 ; 159*256+96
    printe("Action!")
    savmsc=40560 ; 158*256+112
    setcolor(2,4,6)
    color=1 plot(0,0) drawto(10,10)
    color=3 plot(12,12) drawto(19,0)
    do
    until key=12
    od
    return
31. • 31:
       
      CommentAuthortdc
    • CommentTime8 Feb 2013 04:02

     
    Tak te adresy, trzeba zawsze ustawiać systemowym operacjom. Szkoda jednak że nie napisałeś w jaki sposób ten program nie działa, bo nie działa bo się zawiesił, a nie działa bo nie rysuje na ekranie to dwie różne sprawy :P
    
    Adres się zmienia, gdyż bez Action! oraz Atari Basica zwalniane jest miejsce (które zajmuje ROM) od adresu $A000. Jeśli używa się systemowych procedur rysującopiszących to one automatycznie ustawiają pamięć obrazu przed końcem wolnej pamięci - dlatego w zależności od tego w jakiej konfiguracji komputer używamy, pamięć obrazu może znajdować się w różnych miejscach.
    
    Dlatego nie tyle należy te wartości ustawić, co raczej dobrą zasadą powinno być sprawdzenie gdzie się w czasie uruchomienia naszego programu znajduje koniec pamięci, gdzie system ustawił adresy itp. Wstawianie tych wartości na sztywno jest nieeleganckie, a do tego będzie powodowało że Twój program z włączonym Atari Basicem nie uruchomi się (lub uruchomi, ale niewiele sensownych rzeczy będzie można w nim zrobić).
32. • 32: CommentAuthorgreblus
    • CommentTime8 Feb 2013 13:02

     
    Eh. Dużo jeszcze nocy przede mną na ogarnięcie podstaw. Ale w sumie najważniejsza jest dobra zabawa, która temu towarzyszy.
33. • 33:
       
      CommentAuthorjhusak
    • CommentTime9 Feb 2013 00:02 zmieniony

     
    textaddr=40800 ; 159*256+96

    
    
    textaddr=$9F60
    
    i bez komentarza się obejdzie ...
    
    Na Atari programując w asm czy action, TRZEBA się nauczyć myślenia w HEX, to strasznie ułatwia wszystko.
    
    Ponadto umieszczając dlistę w kodzie tak, jak to zrobiłeś, musisz się liczyć, że w końcu trafisz na granicę kilobajtowego bloku, i Ci dlista pójdzie w maliny. Bądź po prostu przygotowany na to.
34. • 34:
       
      CommentAuthortdc
    • CommentTime9 Feb 2013 01:02 zmieniony

     

    greblus:

    Eh. Dużo jeszcze nocy przede mną na ogarnięcie podstaw. Ale w sumie najważniejsza jest dobra zabawa, która temu towarzyszy.

    
    Podobno gonienie króliczka jest najprzyjemniejsze ;)
    
    
    Kuba ma rację, używając hexa od razu widać gdzie się kończą konkretne granice pamięci, czy to na duszki, dl, zestaw/y znaków itp. W systemie dziesiętnym tego nie widać na pierwszy rzut oka.
35. • 35: CommentAuthorgreblus
    • CommentTime9 Feb 2013 11:02 zmieniony

     
    Kuba, dzięki. To nie tak, że twoje poprzednie rady (przy okazji eksperymentów z asm) wsadziłem między bajki :). Cały czas o nich pamiętam, po prostu ciężko się przestawić na hexy, ale pracuje nad tym... A dlistę w kodzie zdefiniowałem w ten sposób bo o ile dobrze rozumiem Reference Manual tablicę można umieścić pod konkretnym adresem, ale wtedy trzeba poszczególne elementy definiować pojedynczo, nie da się napisać:
    
    byte array barr = $addr [ <dane> ].
    
    Można by też pewnie zdefiniować pustą tablicę pod konkretnym adresem, a dane skopiować np. moveblock, ale to mi się nie podoba...
36. • 36:
       
      CommentAuthorjhusak
    • CommentTime9 Feb 2013 16:02

     
    Dlatego nie piszę, że to błąd, tylko jeśli coś Ci się przestanie wyświetlać, to wiadomo gdzie szukać.
    
    A co do HEX: trzeba wyrzucić myślenie w dec co do adresów. Nie musisz ich dodawać, ani mnożyć.
    
    Musisz wiedzieć, że:
    $100 = 1/4 kB
    $400 = 1 KB
    $1000 = 4 KB
    $4000 = 16 kB
    
    DList musi być pod adresami podzielnymi przez $400, pamięć ekranu pod $X000 (x=0-F)
    $4000-$7FFF to blok do podmiany w komputerach z rozszerzoną pamięcią
    $A000-$BFFF - obszar cartridge (a czasem też $8000-$9fff)
    
    Adresy rejestrów: widać dokładnie do jakiego układu należy adres :) - każdy ma swoją stronę pamięci.
    
    Reszta sama wyjdzie.
    
    
    pamięć sięga do $A000 jeśli cart on, do $C000, jeśli off.
    
    Pod $D000 do $D800 masz rejestry.
37. • 37: CommentAuthorgreblus
    • CommentTime9 Feb 2013 18:02

     
    Jakub, jeszcze raz dzięki za cierpliwość i wyjaśnienia.
    
    Co do pamięci rozszerzonej to ostatnio napisałem notkę na ten temat w kontekście eksperymentów z U1MB i Action!:
    
    ->link<-
    
    Może się komuś przyda.
38. • 38: CommentAuthormono
    • CommentTime9 Feb 2013 18:02

     
    Drobna poprawka. Pamięć ekranu i dlista może być ulokowana pod dowolnym adresem (generator znaków i pamięć sprajtów już niestety nie). Zawijają się tylko na granicy odpowiednio 4kb i 1kb. Generator znaków musi być natomiast ulokowany na początku 1kb (jeśli korzystasz z trybów 128 znakowych), lub 512b (jeśli korzystasz z trybów 64 znakowych). Pamięć sprajtów na granicy 2kb (w trybie 1 liniowym) lub 1kb (w trybie dwuliniowym).
39. • 39:
       
      CommentAuthorjhusak
    • CommentTime9 Feb 2013 22:02

     
    Oj tak, to był taki skrót myślowy, teraz widzę, że zbyt duży.