Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
atari.area forum » Programowanie - 8 bit » TBXL - miejsce na dane
Zaloguj się lub zarejestruj by napisać odpowiedź
Witam.
Program w Turbo Basicu XL. Gdzie w miarę bezpiecznie można ulokować dane (ciągłe) - od adres do adres - około 3 do 5 kilobajtów?
Pozdr.
w zmiennej tekstowej, np A$ lub innej
a bez zmiennej tekstowej? np chce procką wczytać dane w podany zakres pamięci tak by mi tego nie zjadło. bez zmiennych tekstowych.
cos na kształt DATA - READ - POKE.
A biorąc pod uwagę adres fizyczny, to jeżeli program nie sięga nie wiadomo jak daleko, można spróbować od $8000. W zależności od użytego trybu graficznego wolna pamięć jest do $a035 (tryb 8 lub 15) lub $bc1f (tryb 0 lub 12). Innych w tej chwili nie pamiętam. Aha, najlepiej przed wrzuceniem tam danych sprawdź, czy koniec programu się nie "zadeptuje" tymi danymi (czyli najlepiej zrób wczesniej jego kopię bezpieczeństwa, a nawet kilka).
dzieki, no to próbujemy ;)
najprosciej jest przez zmienna tekstowa przez DIM ZMIENNA$(ROZMIAR), wtedy mamy wolny obszar od ADR(ZMIENNA$) do ADR(ZMIENNA$)+ROZMIAR
sposob miker'a tez zadziala, ale nie daje Ci gwarancji, ze dane nie zostana nadpisane...
o ile dobrze pamietam to rezerowalo sie obszar pamieci w BASIC'u tak:
POKE 106,PEEK(106)-ROZMIAR:GRAPHICS 0:AD=PEEK(106)i teraz masz wolny obasz od adresu AD do AD+(ROZMIAR*256)
pamietaj o instukcji GRAPHICS, jesli tego nie zrobisz adres ekranu bedzie wskazywac na wolny obszar, ktory wlasnie "zadeklarowales"...
Do pierwszego resetu oczywiscie...
Ja stosowalem inna metode, ladowalem bezposrednio ponizej pamieci ekranu. Malo skuteczne, gdy zmieniasz tryby graficzne ;)
A gdyby "driver" w kodzie maszynowym umieścić na stronie szóstej, a reszta w pamięci dodatkowej lub pod ROMem? Zamiast PEEK/POKE używałbyś USR i nawet nie wiem czy byłoby wolniejsze...
Hej!
Może coś bredzę ale czy Turbo BASIC nie wykorzystuje pamięci pod ROM-em?
Metoda z obniżeniem RAMTOP, podana przez Probe-a wydaje się najrozsądniejsza i najbezpieczniejsza :)
pozdrawiam
Seban
Najbezpieczniejsza i najrozsadniejsza to jest zmienna tekstowa ;)
Zastanawiam sie skad awersja do tej metody ?
A poza tym, bardzo łatwo w zmiennej tekstowej przesuwać dane w lewo i prawo, no i odnajdywać poszukiwany ciąg.
Najbezpieczniejsza i najrozsadniejsza to jest zmienna tekstowa ;) Zastanawiam sie skad awersja do tej metody ?
No ja zawsze się bawiłem z RAM-TOP-em :) Ta metoda zawsze wydawała mi się fajna w szczególności iż w Turbo Basic-u miałem BGET, BPUT oraz MOVE które operowały na podanym adresie pamięci... w przypadku zmiennej TXT cięzko np. byłoby załadować do niej font lub obrazek i umieśić go tak aby to pasowało ANTIC-owi :)
No ale to była tylko moje skromna opinia i być może złe przyzwyczajenie :D Zmiennych tekstowych przechowujących dane binarne praktycznie nie używałem :)
Seban
Dane grafiki i fonty najwygodniej zapakować nad ekran, przesuwając ramtop.
Rzeczy typu bufora do kopiowania - przez zmienną tekstową.
Można też bawić się w umieszczanie w dowolnym miejscu w pamięci, wtedy cały zakres od DPEEK($90) do DPEEK($230)-%1 jest twój, tylko trzeba pamiętać, że DPEEK($90) zmienia się w czasie wykonywania programu, a DPEEK($230) zależy od trybu graficznego.
Zastanawiam sie skad awersja do tej metody ?
Z nieumiejętności używania zmiennych tekstowych w BASIC-u.
Hint: DIM A$(8192) nie rezerwuje 8k, tworzy tylko zmienną. Wczytanie przez BGET czegokolwiek pod ADR(A$) posyła dane do pustej pamięci, gdzie zostaną napisane przy najbliższej okazji. Przedtem trzeba zrobić A$(8192)="x", to nadaje zmiennej długość.
Wyróżnienie za propozycję tygodnia należy się jednak laoo ;)
Wyróżnienie za propozycję tygodnia należy się jednak laoo ;)
Czepiasz się. Laoo używa TBXL4SD32 nawet pod loaderem szumnie, a nie wiedzieć czemu, zwanym DOS-em w wersji 6.4 i pamięć pod ROM-em ma wolną. ;)
Napisałem o pamięci dodatkowej i ewentualnie o pamięci pod ROMem, a TBXLa nigdy nie używałem i w moim Atari BASICu zawsze tam było wolne :) A rozwiązanie jest wg mnie interesujące, bo można sobie nawet kopiować bloki pomiędzy pamięcią dodatkową, a zmiennymi tekstowymi
No pewnie, że się czepiam :P TBXL jednak siedzi pod ROM-em, a poza tym najpierw dobrze byłoby wykorzystać normalną pamięć RAM, wolne jest chyba ze 34k.
PS. To chyba jedyny od paru tygodni konkretny wątek o programowaniu :D Ostatnio plomba jest bogiem, a styropian jej prorokiem.
dobra, a teraz z tej samej beczki tylko od denka ;)
w celu wielkokrotnego przerzucania różnych ciągów danych z jednego miejsca pamięci (tego zarezerwowanego na dane) w inne, o ile szybsza (?) będzie metoda z obniżeniem RAMTOPU i używania POKE,MOVE itp. od metody zastosowania zmiennych tekstowych? (cały czas mowa of course o TBXL).
Bedzie tak samo szybko. W koncu zmienna tekstowa sluzy Ci tylko jako rezerwacja pamieci, odwolywac sie do niej bedziesz przy pomocy POKE,MOVE jak pisales.
Dokladnie tak samo jak do inaczej rezerwowanej pamieci, a wygoda sporo wieksza.
Zreszta zobaczylbys jak fajnie wygladalyby Twoje dane pod MEMTOPem, jakbys przy pomocy QMEGa cos chcial wydrukowac ;) (chodzi mi o QMEG 3.2 z oryginalna procedura drukowanie graficznie tekstu z Atari). Oczywiscie przypadek dosc szczegolny, ale.... nie wiadomo jak uzytkownik programu zadziala :)
Jeśli A$(X) to jeden zarezerwowany obszar, a B$(X) drugi, to kopiowanie: LET B$=A$ wydaje się być szybsze od MOVE ADR(A$),ADR(B$),X
"Wydaje się", czy rzeczywiście "jest"? Jeśli dane przechowywane są w zmiennej tekstowej, to warto zapamiętać jej adres w jakiejś zmiennej (np. A=ADR(A$)) niż za każdym razem wywoływać funkcję.
Osobiście obniżyłbym RAMTOP i w tak uzyskanej pamięci przechowywał dane. Odwołanie do zmiennej jest wolniejsze niż bezpośrednio do pamięci. Do tego dochodzi jeszcze ograniczona liczba zmiennych.
i właśnie o to chodziło mi :) a czy ktoś potrafi powiedzieć ile więcej cykli zajmuje let b$=a$ od równoważnej i tożsamej w wyniku instrukcji move? /poprawiłem literówke ;)/
Liczbą zmiennych, to bym się nie martwił. W TBXL może ich być 256 (Atari Basic ma ich max 128). Ja w swoich programikach też zawsze obniżam RAMTOP i tam przechowuję dane. Jednak należy wziąć pod uwagę fakt, że RAMTOPU nie można ustawić dowolnie. Musi to być wielokrotność strony i w zależności od trybu graficznego trzeba ustawić RAMTOP na takiej wartości, żeby obraz wyświetlał się prawidłowo - wielokrotność 1KB lub nawet 4KB. Czasami danych nie ma tak dużo, żeby zajmowały tak duży obszar i takie rezerwowanie mija się z celem. Jeśli dane mamy w zmiennej i znamy jej adres (ADRES=ADR(A$)), to spokojnie można również korzystać z POKE, MOVE, które to odnosić się będą do danych w tej zmiennej a i zrobienie LET B$=A$ będzie możliwe.
Ile cykli? Nie mam pojęcia ;) Chyba przy pisaniu programów w TBXL ilość cykli ma najmniejsze znaczenie...
Hej!
A może warto samemu sprawdzić by było? To naprawdę nie zajmie dużo czasu i pozwoli mieć chwilę radochy :)
10 CLR :MEMTOP=PEEK(106):POKE 106,MEMTOP-(8192/256):BUFF=PEEK(106)
20 GRAPHICS 0
30 DIM A$(4096),B$(4096)
40 A$(4096)=CHR$(0):B$(4096)=CHR$(0)
50 POKE 559,0
60 DPOKE 19,0:FOR I=0 TO 15:B$=A$:NEXT I:T1=PEEK(20)+256*PEEK(19)
70 DPOKE 19,0:FOR I=0 TO 15:MOVE BUFF,BUFF+$0400,$1000:NEXT I:T2=PEEK(20)+256*PEEK(19)
80 POKE 106,MEMTOP:GRAPHICS 0
90 ? :? "EXECUTION TIMES:":?
91 ? "STRING COPY=";T1*(1/50);" SEC."
92 ? "MEMORY MOVE=";T2*(1/50);" SEC."wynik działania z emulatora:
przy 16 przebiegach różnicy nie ma, przy większej ilości powtórzeń B$=A$ wysuwa się minimalnie na prowadzenie :) Ale to zapewne przez zapis MOVE BUFF,BUFF+$0400,$1000. W pętli mamy dodatkowo dwa odwołania do zmiennej BUFF, dodawanie oraz konwersja HEX->Floating Point. Zapis typu MOVE $A000,$B000,$1000 jest szybszy od B$=A$. (9.48 sek. vs 9.78 sek.).
Nie znam się na tyle na działaniu tego interpretera i nie mam czasu na dłubanie w nim aby określić jakich procedur używa TBXL do przepisania zawartości zmiennych i jak wygląda MOVE, ale myślę iż najwięcej w tej sprawie zapewne mógłby powiedzieć drac030 bo on ma pewnie sporą wiedzą o działaniu interpreterów BASIC-a ze względu na zaangażowanie w ich analizowanie i pracę nad własną wersją (Multi BASIC).
pozdrawiam
Seban
Seban, dyskusja dotyczy TurboBasica:
10 CLR :MEMTOP=PEEK(106):POKE 106,MEMTOP-192:B=PEEK(106)
20 GRAPHICS %0
30 DIM A$(4096),B$(4096)
40 A$(4096)=CHR$(%0):B$(4096)=CHR$(%0)
50 POKE 559,%0
60 T1=TIME:FOR I=%0 TO 15:B$=A$:NEXT I:T1=TIME-T1
70 C=B+$1000:T2=TIME:FOR I=%0 TO 15:MOVE B,C,$1000:NEXT I:T2=TIME-T2
80 POKE 106,MEMTOP:GRAPHICS %0
90 ? :? "EXECUTION TIMES:":?
91 ? "STRING COPY=";T1;" SEC."
92 ? "MEMORY MOVE=";T2;" SEC."Na szybkość wykonywania programu ma też wpływ długość nazw zmiennych, więc używanie długiej nazwy BUFF (w porównaniu z krótkim A$) spowalnia wykonanie MOVE.
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Programowanie - 8 bit » TBXL - miejsce na dane
Wygenerowano w 0.024 sekund, wykonano 65 zapytań