Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
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.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Programowanie - 8 bit » TBXL - miejsce na dane
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
seban: nie wiem, jak wygląda move w TBXL, nie analizowałem kodu tego interpretera, tylko zrewerse-engineerowałem go w Multi :) Ale użycie do przepisywania stringów tej samej procedury, co w MOVE wydaje się logiczne.
Lizard: długość nazw zmiennych nie ma wpływu na szybkość wykonywania programu, interpreter przy obliczeniach posługuje się tokenami zmiennych a nie ich nazwami.
Hej!
Lizard: No widzisz :) A kto powiedział że ja się super znam na Turbo Basicu :) O zmiennej TIME również zapomniało mi się po latach :) Pamiętałem jedynie o TIME$ która była dla mnie bezużyteczna :) Ale abym i ja mógł się do czegoś przyczepić (a co :P ) to z tym MEMTOP-192 to chyba przesadziłeś nieco :D Poza tym T1 i T2 wyjdą u Ciebie w ramkach nie w sekundach. :D trzeba by zmienić" SEC." na "frames" :D
Drac030: tak też sądziłem iż MOVE będzie tożsame z kopiowaniem stringów :D
Seban
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.
ROTFL miesiąca.
A gdyby "driver" w kodzie maszynowym umieścić na stronie szóstej, a reszta w pamięci dodatkowej
Zestaw wsatwek maszynowych do miąchania w dodatkowej pamięci za pomoca USR'a pod TBXL to byłoby coś... Nowa jakość dem w Basicu :)
Mam jakiś wycinek z IKSa pozwalający korzystać z dodatkowej pamięci w 130XE. Lizard napisał mi kiedyś USR'a przenoszącego dane ext. ram -> podstawowa pamięc, gdzieś się na dysku kurzy ta procka. Taka pełna biblioteka to byłaby fajna rzecz...
Mam właśnie taki problem z metodą , jaką opisywał wyżej larek. Ze względu na użyty tryb graficzny nie mogę dowolnie modyfikować RAMTOPem (muszę go zmieniać co 4KB) , a to co tam zarezerwowałem już mam wykorzytsane na 100%.
Pozostaje zatem zadeklarowanie tablicy np. A$ i korzystanie z niej (peek,poke) jak z fragmentu pamięci. Z deklaracją nie ma problemu (udaje się - ramu wystarcza), ale nie rozumiem jednej rzeczy.
Dlaczego dla:
? adr(a$)
? adr(a$(1))
x = adr(a$): ? x
x = adr(a$(1)): ? x
dostaję zupełnie inne wartości? zwłaszcza nie rozumiem dlaczego jak podstawiam wartość adresu do zmiennej dostaję co innego. oczywiście założenie jest takie, że zmienne już zadeklariowałem, użyłem wcześniej. czy rzeczywiście jest to bezpieczna metoda?
Ja dostaję takie same, przynajmniej w programie. Bierzesz pod uwagę, że wartości adr(a$) mogą się zmieniać w zależności od tego, czy program jest uruchomiony przez run, czy tylko robisz ? adr(a$) w trybie bezpośrednim, a również, oidp., w trakcie działania programu, jeśli zmieni się wielkość innych zmiennych łańcuchowych, pojawią się nowe zmienne w ogóle itp.?
PS. a$ jest zadeklarowana - ale czy jest zwymiarowana?
tak, zwymiarowana. zgodnie z zaleceniem podstawiam tam dowolną wartość pod ostatni znak w łańcuchu przed użyciem. przyznaję, że radośnie sobie to wylogowanie robię bezpośrednio (w ramach testów bo coś mi nie działa ), a nie prez run (muszę to wylogować bezpośredniow programie - może nie ma problemu). starałem się, aby wszytskie zmienne były już zadeklarowane (raz użyte) przed pobraniem adresu. jeszcze zatem posprawdzam, czy nie zrobiłem skify u siebie, skoro to powinno działać.
dzięki
Dla kompletu spróbuj jeszcze:
A=1: ? ADR(A$(A))Jeśli to piszesz w trybie bezpośrednim dostajesz różne adresy ze względu na to, że długość linii jest różna w każdej z podanych postaci a przecież tablica zmiennych indeksowanych znajduje się ZA KODEM PROGRAMU (linia w trybie bezpośrednim ma numer 32768 i zawsze jest częścią programu mimo, że BASIC jej nie pokazuje przy listowaniu; jest natomiast zapisywana przy CSAVE/SAVE i oczywiście ładowana przez CLOAD/LOAD). Tokeny indeksujące ciąg zajmują 2 bajty, liczba indeksująca ciąg zajmuje 6 bajtów, zmienna indeksująca zajmuje 1 bajt.
Przy wykonaniu tych samych instrukcji w kodzie programu niezależnie od postaci dostaniesz zawsze ten sam adres, ponieważ linia 32768 ma wtedy tylko token RUN.
Edit: W trakcie działania programu nie może się zmienić rozmiar zmiennych (nie można redeklarować zmiennych w BASICu), wszystkie zmienne deklarowane są w trakcie parsowania linii przy wprowadzaniu. W trakcie działania programu zatem zmienne się nie przesuwają w pamięci.
W trakcie działania programu nie może się zmienić rozmiar zmiennych (nie można redeklarować zmiennych w BASICu), wszystkie zmienne deklarowane są w trakcie parsowania linii przy wprowadzaniu. W trakcie działania programu zatem zmienne się nie przesuwają w pamięci.
Racja. Może się to zmienić jedynie w sytuacji (rzadkiej) kiedy program sam dodaje do siebie albo modyfikuje swój kawałek, np. jedną linię. Jest to bardzo rzadka sytuacja i trudno, żeby twórca programu o niej nie wiedział :)
Rzeczywiście. Sztuczka z POKE 842,13. Ale to chyba jedyny (poza USR i świadomym przesuwaniem programu w pamięci procedurami maszynowymi) sposób na samomodyfikację programu w BASICu?
Jedyny mi znany :)
czy te różnice między ADR(A$) i ADR(A$(1)) nie polegają na różnym interpretowaniu kodu przez edytor ?
ADR([zmienna]):
ADR(A$): zmienna = A$ - pobierz i zwróć adres przypisanej zmiennej
ADR(A$(1)): zmienna = A$(1) - ze zmiennej A$ pobierz pierwszy znak do "bufora", pobierz i zwróć adres przypisanej zmiennej -> adres bufora!
ADR zwraca adres w pamięci tego, co mu podamy. tak więc ADR(A$) to adres ciągu tekstowego (jego pierwszego bajtu/znaku), A$(N) adres n-tego znaku ciągu tekstowego. Samo ADR nie przypisuje nic niczemu.
"Bufor" który pewnie masz na myśli jest używany przez funkcje STR$ i CHR$ do tworzenia w locie nowych ciągów tekstowych i znajduje się pod adresem $5c0 dla CHR$ i $580 dla STR$ - zajmuje odpowiednio $40 i $80 bajtów, a więc ciąg tymczasowy powinien mieć co najwyżej 64 lub 128 znaków. Ponieważ nie jest on alokowany dynamicznie, jest to przyczyną błędnego działania konstrukcji
IF CHR$(34)=CHR$(35) THEN ? "ERROR!"i analogicznej z STR$ (porównanie w przypadku STR$ zwróci 1 tylko kiedy obydwa ciągi mają taką samą długość niezależnie od zawartości).
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Programowanie - 8 bit » TBXL - miejsce na dane
Wygenerowano w 0.032 sekund, wykonano 61 zapytań