Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
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"...
Ostatnio edytowany przez pr0be (2008-02-04 22:23:55)
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
Ostatnio edytowany przez seban (2008-02-05 11:08:16)
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 ;)/
Ostatnio edytowany przez Muffy (2008-02-06 09:27:58)
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
Ostatnio edytowany przez seban (2008-02-06 11:00:00)
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ź
[ Wygenerowano w 0.094 sekund, wykonano 12 zapytań ]