A nie jest tak, że w obszarze tym jest lokowany program w TBXL? Jeśli tak, to przełączenie banku może spowodować zwis kompa. Należałoby zadbać o to, aby w $4000-$7fff nie było programu, a tylko np. dane.
Tak sobie tylko głośno myślę, więc mogę się mylić... ;)
To jednak trochę trudne kiedy nie wiadomo czy kawałek kodu, który właśnie odpalamy nie jest ulokowany właśnie w obszarze banku pamięci :/ Teoretycznie (niech mnie poprawi ktoś, kto zna TBXL) taki test można wykonać sprawdzając adres stałej tekstowej (która zapisana jest bezpośrednio w kodzie programu - tak to robi w każdym razie Atari BASIC):
10REM tu ma być zdefiniowana procedura sięgająca do XRAM ... 100IFADR("") > 16384THENREM procka sięgająca do xram jest w obszarze XRAM
Jeżeli zamierzamy przepisać kawałek pamięci gdzie indziej, należałoby zadbać o to, żeby obszar docelowy również nie pokrywał się z xram. Jeśli np. chcielibyśmy przepisać kawał pamięci do zmiennej tekstowej, to można taki test zrobić tak:
100DIM A$(1000) 110 A=ADR(A$) 120IF A+1000 > 16384AND A < 32768THENREM zmienna nakłada się na XRAM 130GOSUB przepisanie obszaru z XRAM do A$
Sama procedura przepisująca (pewnie da się zrobić znacznie lepszą w TBXL) w Atari BASIC może wyglądać tak:
10POKE54017,BANK 20FOR A=0TOSTOP-START 30POKE CEL+A,PEEK(START+A) 40NEXT A 50POKE54017,255: REM bank podstawowy (dla Atari Basic ma być 253) 60RETURN
START i STOP to odpowiednio adresy początku i końca przepisywanego obszaru, CEL to adres docelowy. BANK to numer banku z którego przepisujemy. Przełączać banki można też w pętli - wtedy obszar docelowy może pokrywać się z obszarem banku; w żadnym wypadku jednak procedura przepisująca nie może nachodzić na obszar banku.
W Turbo Basicu jest oczywiscie rozkaz: MOVE skad,dokad,ile oraz -MOVE skad,dokad,ile
Ten drugi przepisuje blok od konca (przydatne kiedy przepisywane bloki na siebie zachodza - wtedy w zaleznoci ktory z blokow jest wczesniej wybieramy odpowiednia wersje MOVE).
Dzięki za odpowiedzi. Wymyśliłem sobie tak: ponieważ czy to TB, czy AB, oba potrzebują dużo czasu na przepisanie data-setów w odpowiedni obszar pamięci, wobec tego lepiej jest i odpowiednio przygotowane procedury maszynowe, i zestawy znaków, i inne "ozdobinki" - ładować w pamięć rozszerzoną - poprawcie mnie, jeśli się mylę, ale przy 320kB "standardzie" mam do wykorzystania 16 bloków pamięci EXT dodatkowo, co do wszystkiego powinno wystarczyć...
//EDIT: i jeszcze jedno pytanie: czy da się zrobić tak, by móc korzystać naraz z dwóch niezależnych bloków ? Tzn. podmapowywać w dwa różne miejsca ?
W C= mają tak rozwiązane rozszerzenia pamięci, co umożliwia im łatwe przepisywanie procesorem pamięci między blokami. W Atari tak nie mamy :( - blok jest zawsze mapowany w obszar $4000..$7fff.
MaW.... instrukcja MOVE Turbo Basica jest prawie tak samo szybka jak kod maszynowy.... nie wiem skąd u Ciebie przekonanie co do jej powolności. Kiedyś za jej pomocą animowało się w pionie duszki i nie było problemów z szybkością.
Pecuś, nie chodzi mi o MOVE, ale o same wartości DATA z basic-a - ja stary magnetofonowiec jestem, przyzwyczajony do tego, że na końcu programu wpisywało się zawsze nieskończoną liczbę linii data...
A jeśli chodzi o same move, to nie obsłuży ona wypełnienia bloku pamięci ze skokiem W w ilości kroków H - czyli jak chcesz szybko nakładać dane na pamięć obrazu to bez procedurki w asm nie da się.
Skoro potrzebna jest i tak procedura w asm, to nie ma żadnych obostrzeń dotyczących pamięci dodatkowej i położenia programu w basicu. Byle procedura w asm nie leżała w obszarze banku pamięci $4000..$7fff.
Edit: Ktoś zrobił taką procedurkę niedawno - poszukaj MaW na którymś z forów. Uwzględniało skok i rodzaj operacji (and,xor,mov, może jeszcze inne).
