Niezalogowany (Zaloguj się)

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

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

Uciążliwości BASICa

Od 1 do 50 z 72

- 1: CommentAuthormono
- CommentTime16 Nov 2009
Interesuje mnie jakie uciążliwości funduje BASIC przy pisaniu większych programów:
1. Za mało pamięci dla działania programu (grafika, muzyka, stos BASICa).
2. Za mało pamięci dla samego programu w BASICu.
3. Za mało zmiennych.
4. Coś innego.
Prosiłbym o informacje ze wskazaniem na wersję interpretera (ATARI BASIC, Turbo BASIC XL, itp).
- 2: CommentAuthorurborg
- CommentTime16 Nov 2009
Oczywiście pomijam mniejszą szybkość działania niż kod maszynowy.

Na podstawie doświadczeń z Kolony 2106 stwierdzam, że największym minusem jest brak pamięci. Każda liczba czy to stała czy zmienna to 8 bajtów gdyż jest ona traktowana jako liczba zmiennoprzecinkowa. Przechowanie dużej ilości parametrów w pamięci wymaga czasem absurdalnie dużo RAM-u. Żeby zaoszczędzić RAM, niektóre wartości w K2106 przechowywane są w łańcuchach tekstowych.

To że WSZYSTKIE wartości liczbowe traktowane są jako zmiennoprzecinkowe ma tez oczywisty wpływ na szybkość działania, bo BASIC aby obliczyć 1+1 używa pakietu zmiennoprzecinkowego, ale to już inna bajka.
- 3:
  
  CommentAuthorKaz
- CommentTime16 Nov 2009
mnie draznila cecha z punktu 4 - cos innego :)
A to mianowicie, ze trzeba numerowac linie. Wole tak jak jest w rozwinieciu TBXL-a na platformy 16-bitowe czyli w GFA Basic.
- 4:
  
  CommentAuthorlarek
- CommentTime16 Nov 2009
Punkty 1,2 i 4 to chyba nie tylko w Basicu, ale generalnie w standardowym Atari XL/XE ;)

Polecam oczywiście Turbo-Basic XL, jeżeli mamy tylko taki wybór. TBXL pozwala na używanie 2 razy większej ilości zmiennych niż Atari Basic, jest szybszy od Atari Basic, ma wiele przydatnych instruckcji, których nie ma Atari Basic i choć trzeba numerować linie, to wcale nie ma potrzeby odnosić sie później do tych numerów.
- 5: CommentAuthormono
- CommentTime16 Nov 2009
Numeracja linii wynika chyba z tego, że mamy edytor ekranowy, a nie całoekranowy (jak w action) i po prostu interpreter przy wprowadzaniu programu musi się jakoś zorientować co i gdzie należy wstawić.
- 6: CommentAuthorurborg
- CommentTime16 Nov 2009
Turbo Basic pozwala na używanie procedur. Jest to pod każdym względem lepsze rozwiązanie niż skoki goto/gosub w Atari Basicu. Po pierwsze skok do procedury i powrót jest szybszy niż skok goto/gosub bo interpreter nie przeszukuje programu w poszukiwaniu linijki z odpowiednim numerem. Po drugie samo wywołanie zajmuje zaledwie 3 bajty pamięci, bo nie trzeba podawać numeru linii który juz sam z siebie zajmuje 8 bajtów.
- 7: CommentAuthormuffy
- CommentTime16 Nov 2009
z tego co pamiętam to w TBXL np %0, %1 zajmuje mniej miejsca niż zwykłe zero, jeden itp
- 8: CommentAuthormono
- CommentTime16 Nov 2009 zmieniony
Zacznijmy więc od takich spraw:
1. Przyspieszenie skoków.
2. Dodanie pamięci na kod programu i dla działania programu.

Ad 1: Można to usprawnić 2 metodami:

a) W momencie uruchamiania programu można przelecieć się po programie i znaleźć wszystkie skoki podane literalnie (jako liczba - skoki wyliczane przez zmienną niestety trzeba by robić po staremu), zapisać i w trakcie wykonywania programu już nie szukać niczego tylko skakać.

b) Można to wyszukiwanie adresów wierszy robić w trakcie działania programu - tzn. przy skoku szukać w tablicy zachowanych adresów linii czy jest adres dla żądanej linii, a jak nie to szukać w programie po czym zapisać wynik w tablicy; ta metoda potrafiłaby przyspieszać skoki wyliczane w trakcie pracy programu.

Do interpretera wprowadzilibyśmy dodatkową tablicę - tablicę adresów linii. To oczywiście zajmie nam trochę ramu.

Ad 2: Co by było gdyby interpreter korzystał dodatkowo z pamięci pod romem (24kb) dla składowania programu? Zalety rozwiązania widzę następujące:

a) więcej pamięci dla kodu programu daje nam więcej pamięci dla uruchamiania programu (kod trzymany pod romem zwalnia pamięć niską ram, w której do tej pory był trzymany); w pamięci niskiej kod jest zapisywany w momencie gdy pod romem się już nie mieści,

b) program w basicu przeżywa zimny start i zwisy komputera (oczywiście ta część, która trzymana jest pod romem, bo ta pamięć nie jest podczas startu komputera zerowana - niski ram niestety jest :(); ponowne załadowanie poprawionego interpretera odzyskiwałoby program

Oczywiście całość byłaby kompatybilna w obydwie strony (wstecz i wprzód - kod uruchamiany takim basicem da się uruchomić bez straty funkcjonalności na normalnym basicu) z oryginalnym basicem - to tylko jego usprawnienie. Poprawka korzystałaby w maksymalnym możliwym stopniu z procedur basica w romie.

Pomyślałem sobie czy nie można by trochę naszego basica usprawnić, bo ostatnio zobaczyłem napis:
"60671 bytes free"
na Commodore +4!!! Trochę mi się smutno zrobiło z naszym 37902 ;)

Nic nie stoi na przeszkodzie, żeby korzystać z dodatkowej pamięci (rozszerzonej).
- 9:
  
  CommentAuthorKaz
- CommentTime16 Nov 2009
No dobrze, ? FRE (0) w Atari Basic pokazuje po starcie 37902 bajty wolne, zas Turbo Basic 32418 (wersja 1.5) i 31782 (wersja 2.0), bez DOS-u nawet wiecej, 34021. Czyli jakies 3-4 KB mniej niz Atari Basic przy wiekszej funkcjonalnosci. Moze wiec lepiej skoncentrowac sie na udostepnieniu wiekszej pamieci w TBXL niz w Atari Basic?
- 10: CommentAuthormono
- CommentTime16 Nov 2009 zmieniony
Być może, być może :) A są gdzieś źródła? Czy jednak TBXL nie wykorzystuje pamięci pod romem właśnie na własny kod dla dodatkowych poleceń?
Poprawka dla błędu "10 DIM: DIM" jest bardzo prosta - w tablicy składni dla DIM potrzebny jest jeden bajt dodatkowo; REM i DATA można zoptymalizować, bo składniowo niczym się nie różnią - udało mi się na razie skrócić ją o 2 bajty przy zachowaniu pełnej funkcjonalności (niestety u Zientary jest błąd w opisie tej tablicy no i nie doszukał się jednego z łańcuchów składniowych).
- 11:
  
  CommentAuthorlarek
- CommentTime16 Nov 2009
Kaz:
FRE (0) w Atari Basic pokazuje po starcie 37902 bajty wolne

Ale to chyba bez DOS-u, bo np. z DOS II+/D pokazuje 31502.
Natomiast Turbo-Basic XL z tym samym DOS-em pozostawia 34021 bajtów!
TBXL zabiera pamięć pod ROM (być może nie wszystko) i dlatego np. nie działa z Atari 800.
- 12:
  
  CommentAuthormiker
- CommentTime16 Nov 2009
A może kwestią jest "rozwalenie" runtime'a i wyrzucenie stamtąd wszystkich nie używanych akurat funkcji (mam świadomość, że może to być dość trudne, bo może ktoś zechce użyć jednyej z _akurat tych wyrzuconych_, ale może iść w tym kierunku). I to pozwoli na wykorzystanie części w ten sposób zwolnionego "podromu", nie wiem...
- 13: CommentAuthormono
- CommentTime16 Nov 2009
@miker: Mówisz o TBXL? Może w takim razie lepiej iść w kierunku wykorzystania pamięci dodatkowej? Dla Atari BASIC jest sens (chyba) o ten "podrom" walczyć, bo to 24kb dla programu (lub danych, stosu - jak tam sobie zamarzymy).
- 14:
  
  CommentAuthorlarek
- CommentTime16 Nov 2009 zmieniony
Można trochę podpatrzeć BASIC XE, który potrafi przecież wykorzystać dodatkową pamięć w 130XE do swoich celów i daje więcej wolnego dla programu.

A tak ogólnie to wydaje mi się, że nie ma co mieszać. TBXL jaki jest taki jest, a i programy powstają na nim całkiem przyzwoite.
- 15: CommentAuthormono
- CommentTime17 Nov 2009
To prawda, ale ja akurat mam sentyment do tego Basica z romu :) Każda zmiana na lepsze chyba jest dobra, czyż nie?
- 16:
  
  CommentAuthorlarek
- CommentTime17 Nov 2009
Ale ten Basic z romu to tylko 8KB. TBXL zajmuje aż 16KB, ale potrafi więcej, a dla użytkownika pozostawia w zasadzie tyle samo miejsca co Atari Basic. Trudno będzie napisać nowy interpreter lub zmieniać stary, bo 8KB to kurcze trochę jednak mało jest.
- 17: CommentAuthormono
- CommentTime17 Nov 2009 zmieniony
To fakt. Ale ja nie chcę pisać nowego interpretera. Planuję zrobić łatkę powiedzmy 2kb usprawniającą działanie basica z romu i wykorzystać 8kb z romu, który mamy i tak za darmo.

Edit: A póki co można sobie potestować wpisywanie wszystkiego z inverse lub małymi literami i co się stanie po wpisaniu "10 DIM". Prawdziwych programów na tym odpalać jeszcze nie można, bo po niektórych konstrukcjach sterowanie przechodzi do basica w romie (objawia się to np. zaprzestaniem rozumienia poleceń pisanych małymi literami).
Ja to uruchamiam z dos 2.5.

Edit 2: A no i kod się nie relokuje tylko ładuje pod $3000.
- basx1.obx
- 18: CommentAuthormono
- CommentTime17 Nov 2009
W ramach ciekawostki (albo i nie - ja o tym nie wiedziałem dotąd) - wiecie, że nry linii w basicu można wprowadzać w notacji naukowej?
np.
1e1 DIM a$(1)
- 19:
  
  CommentAuthorKaz
- CommentTime17 Nov 2009 zmieniony
A ja wroce do pierwszego Twojego postu: czy wiesz, dlaczego w C+4 bylo az 60KB wolnego miejsca na programy w Basicu? Bo przeciez w C64 (Basic 2.0) jest podobnie jak w Atari. Wiki podpowiada, ze chodzi o zmiane adresowania... czego/gdzie?

Przy okazji znalazlem opis roznic miedzy tymi Basicami:
->link<-

I ciekawa historie:
->link<-
- 20: CommentAuthormono
- CommentTime17 Nov 2009 zmieniony
Faktycznie ciekawe. Nie mam pojęcia o co chodzić może z tą zmianą adresowania pamięci - może o przełączanie banków (dla układu graficznego?). W komodorach można odłączyć wszystkie romy i układy wejścia wyjścia dzięki czemu jest dostępny ram, który leży pod nimi (bez 2 bajtów na stronie zerowej, którymi pamięć się konfiguruje).
Po odjęciu tych 60671 od 64kb zostaje 4865 - całkiem rozsądnie zmieszczą się w tym i rejestry systemowe, i ekran tekstowy, i pewnie jakiś kod obsługujący przełączanie romów (w c64 memlo jest na $800 a więc niżej niż w połowie tego obszaru; ekran jest w $400).
- 21:
  
  CommentAuthorKaz
- CommentTime17 Nov 2009 zmieniony
To ja zacytuje Twoj mail z wczoraj, bo pewnie niektorym sie przejasni, do czego zmierzaja Twoje pytania :)

Grzebię sobie ostatnio w atari basic w celu udostępnienia trochę większej ilości ram dla interpretera.
Nie wiem czy coś z tego wyjdzie - założyłem sobie, że kod przerobionego basica (korzystającego mocno z oryginalnego - to tylko łatka ma być) powinien się zmieścić w 1KB, ale już widzę, że tego założenia nie spełnię bo trzeba przepisać masę procedur - właściwie całe parsowanie składni.
(...) jak zobaczyłem, że na C+4 basic pisze "60671 bytes free" to mi szczęka opadła. No i zastanawiałem się czy nie dałoby się basicowi w Atari udostępnić ram pod romem (24k w końcu) i przy okazji poprawić parę błędów (te z atariki).
Moje założenia:

• automatyczne odpalanie AUTORUN.BAS
• wejście do basx'a za pomocą BASX[.COM]
• zarządzanie pamięcią pod romem (kod programu)
• 1024b na kod, 59400b (22522 pod romem + 37902 max std ram - 1024) dostępnych dla basx'a
• kod programu trzymany w pierwszej kolejności pod rom (od $A000..$CFFF oraz $D800..$FFF9), dopiero w następnej kolejności w ram; dzięki temu wszystkie operacje obniżania ramtop i przełączania trybów graficznych powinny działać bez zarzutu; również poke/peek powinno działać jak dawniej, bo tylko odczyt tokenów będzie spod romu
• własne procedury (c)save/load, list/enter, fre, usr, run, zapisujące tokeny w pamięci, przesuwające pamięć programu, pobierające tokeny programu, określające adresy linii programu
• program basx'owy "przeżywający" zimny start i zwisy kompa :)
• cała niska pamięć dla danych, fontów, muzyki itd.
• edytor umożliwiający edycję 254 znaków w wierszu, a nie 120 (poprawka dla urządzenia "E:" w systemie)
• do rozważenia porządny mechanizm ładowania rozszerzeń basx'a (rozszerzanie składni np. oparte o token REM)
• poprawka błędu porównanie dwóch funkcji chr$()=chr$()
• poprawka 10 dim: dim
• poprawka 10 trap 10 - sygnalizacja błędu przepełnienia stosu (2 - insufficient memory)
• case insensitive dla wszystkich elementów programu (prócz oczywiście tekstów)
• automatyczna zmiana ? na PRINT, COM na DIM, GO TO na GOTO, THEN x na THEN GOTO x, x=y na LET x=y, itd.
• błąd przy separacji instrukcji znakiem ESC
• poprawka note i status - poprawne przypisanie wartości do zmiennych tablicowych
• po RESET powrót do basx'a - odinstalowanie po zleceniu dos (powrót do basx'a możliwy za pomocą run - ustawiany jest wektor RUNAD)

Z tego co widzę, to na razie dałoby się zmieścić kod w 4kb, ale mielibyśmy ok 50kb pamięci dla basica i cały zwykły ram ($2000..$bfff) dla danych, stosu basica i zmiennych, ekranu, muzyki itp.
Nie wszystkie rzeczy są ważne - np. z case insensitive można śmiało zrezygnować.
Na razie mam część rozpoznawania składni zrobione, uruchamianie większości poleceń w trybie bezpośrednim i walczę z poprawnym rozpoznawaniem nazw funkcji (chr$, asc itd.). Jak będzie coś działającego, to się pochwalę :)
Ciekawi mnie czy jednak da się to zrobić porządnie, czy po przepisaniu większości procedur mało co będzie wywoływane z romu.
Wydaje mi się, że to byłoby chyba coś fajnego dla miłośników atari basica.
- 22: CommentAuthormono
- CommentTime17 Nov 2009
W załączonej poprzednio wersji jest już poprawne rozpoznawanie funkcji case insensitive.
- 23: CommentAuthormono
- CommentTime17 Nov 2009 zmieniony
Masakra. Jak się chce poprawnie obsługiwać błędy to trzeba skopiować praktycznie wszystkie funkcje i instrukcje. Moja "łatka" na basic zajmuje 7kb ramu !!! Jedyne co w zasadzie nie wymagało skopiowania to parser wyrażeń (wystarczyło podać wektor na tablicę ze składnią) i trochę funkcji narzędziowych. Wychodzi na to, że będzie to zajmować tyle co zwykły basic - sensowniej byłoby napisać chyba nowy basic kompatybilny z AB, ale szybszy i korzystający z "podromu".
Cóż - mimo tego 8kb dalej dla basica zostanie całe 22kb dodatkowej pamięci.
Wersja jest dalej nierelokowalna i jest ulokowana w $3000..$4C44, ale powinno chodzić wszystko (wszystkiego jeszcze nie testowałem).
Jak to robią w Turbo Basicu...?

Edit: Nie można separować instrukcji escapem. Jakiś błąd w instrukcji PRINT (przełazi do basica w romie). ASC("") rzuca błąd.
- basx2.obx
- 24: CommentAuthorRzymianinus
- CommentTime18 Nov 2009
Podpinam moje pytanie aby nie zakładać nowego tematu...

Na pierwszym roku studiów miałem (chyba jako ostatni rocznik) programowanie w BASIC`u (ZX Spectrum oraz MERITUM). Początki abecadła. Sprowadzało się to do pisania programików wyświetlających przebieg podanych funkcji itp. Na drugim roku usłyszałem od innego prowadzącego zajęcia, że nauki programowania nie należy zaczynać od BASIC`a!!! Podobno uczy ZŁYCH NAWYKÓW (?). "BASIC NIE powinien być PIERWSZYM językiem programowania dla nowicjuszy" - to słyszałem wiele razy. Mówił to człowiek preferujący coś takiego jak FORTRAN, FORCON (tego akurat nienawidziłem).
Przypomniałem sobie o tej historii gdy syn grający w "Montezumas Revenge" (niestety w konwersję na PC bowiem ta jest lepsza od oryginału na emulatorze) spytał mnie czy ja potrafię cokolwiek napisać na ATARI.

Inni też mają dzieci, więc napiszcie: rozbudzenie ciekawości w tym kierunku zaczyna się od ......?
- 25:
  
  CommentAuthorMaW
- CommentTime18 Nov 2009
Ej no, nie uwierzę - co jest lepszego w konwersji PC montezumy od oryginału na emulatorze (nie mówiąc już o oryginale na oryginale!) ? Bo kurna zaraz tu dla kogoś bana zaproponuję :[

A zaczynasz uczyć od tego, co masz pod ręką - wtedy pod ręką był wyłącznie BASIC. Decyzja firm komputerowych o wbudowaniu interpretera w rom maszyny była krokiem milowym informatyki.
- 26: CommentAuthormono
- CommentTime18 Nov 2009
Mój profesor od ZPT w szkole podstawowej na kółku komputerowym uczył nas Atari BASIC'a i LOGO. To były dwa pierwsze języki programowania, które poznałem. Nie wiem, czy wskutek tego mam złe nawyki programistyczne :) - ktoś musiałby to ocenić...
W Ubuntu standardowo w paczkach jest KTurtle - takie właśnie Logo z żółwiem. Do Atari LOGO Kaz ma w archiwach instrukcje - IMHO zacznij rozbudzać zainteresowanie od tego co znasz i co jesteś w stanie wytłumaczyć.
- 27:
  
  CommentAuthorKaz
- CommentTime18 Nov 2009 zmieniony
Czy jezyk programowania wyrabia nawyki to pewnie kwestia sporna. Zalezy zapewne od dlugosci i czestotliwosci programowania, jednym wyrabia, innym nie i przy pierwszej lepszej okazji zmieniaja jezyk programowania :).

Ja zaczynalem od Logo (jeszcze bez komputera, na sucho), ale wcale nie czulem przez to lepszych nawykow, bo i tak w praktyce Atari Basic sprzyjal pisaniu niestrukturalnemu i nieczytelnego (mimo, ze oczywiscie gdyby sie uprzec to mozna i strukturalnie i czytelnie). Dopiero GFA Basic na ST przyzwyczail mnie do ladnego, czytelnego pisania programow - bo nie dawal innego wyboru ;).

PS. Skorzystam z okazji i dodam, ze GFA Basic jest wciaz rozwijany: ->link<-
- 28: CommentAuthorRzymianinus
- CommentTime18 Nov 2009
Niech mi ban od MaW`a lekkim będzie ale te czaszki z konwersji na PC są takie ładne :)
->link<-
->link<-
Niestety w grze dostałem baty od syna. Chciałem się popisać i straciłem wszystkie życia w sposób kompromitujący :(

A wracając do BASICA to chyba będę się uczył od nowa (we dwóch z synem zawsze raźniej). Musze poprawić swój nadszarpnięty autorytet. Z tych pozycji (biblioteka atarionline):
1. Atari Basic - praca zbiorowa pod redakcją: Wiesław Migut, wydawca: KAW
2. Atari Basic. Język programowania i obsługa mikrokomputera Atari, wydawca: NOT ODKTRS
3. Atari Basic XL, autor: Adam Stawowy pod redakcją Wiesława Miguta, wydawca: NOT ODKTRS
jeśli znacie, to która jest np. bez błędów i zasługuje na miano Elementarza?
- 29: CommentAuthormono
- CommentTime18 Nov 2009
Do Atari BASIC'a polecałbym właściwie Miguta, ale jeśli chcesz się uczyć od nowa, to może zastanów się poważnie nad Turbo BASIC'em XL - to jest (jak już Koledzy tu pisali) znacznie lepszy język od wbudowanego interpretera. W którymś czasopiśmie (chyba Bajtek) można znaleźć kurs tego języka. Polecam przeszukanie forum albo nowinek AtariOnline pod tym kątem, bo zdaje się gdzieś padały konkretne linki.
Gra Kolony 2106 została napisana właśnie w TBXL!
- 30: CommentAuthortbxx
- CommentTime18 Nov 2009
Ja odświerzam sobie TBXL po 16 i "Atari BASIC" W.Miguta to bardzo dobra pozycja. Jeśli nie miałeś wcześniej do czynienia z TBXL, nic nie szkodzi - to ten sam stary dobry BASIC, tylko trochę szybszy i wyposażony w dodatkowe ułatwiające życie funcje. Ciekawych rzeczy można też dowiedzieć się z "Tajemnic Atari"
- 31: CommentAuthormono
- CommentTime19 Nov 2009 zmieniony
Wersja z relokacją - można próbować uruchamiać rzeczy w basicu. Na razie jeszcze nie korzysta z "podromu". Po reset wraca do siebie (czyli basx'a ;)); dos wyłazi do dosu, run z powrotem wraca do basx'a i nie traci programu.

Edit: ?FRE(0) w basxu pokazuje 46405, natomiast w basicu 23883 (dos 2.5 z cp) -- 22522 dodatkowo. Zacznę chyba dorabiać obsługę podromu i dodatkowej pamięci...
- basx3.obx
- 32:
  
  CommentAuthorKaz
- CommentTime19 Nov 2009
46405 - niezle!
- 33:
  
  CommentAuthorlarek
- CommentTime19 Nov 2009
Uruchomiłem. Napisałem:
GR.8
C.1
i zrobił się czarny ekran...
- 34: CommentAuthormono
- CommentTime19 Nov 2009 zmieniony
Dzięki - przyjrzę się problemowi.

Edit: Informacja i plik z poprawką przesunięty do nowego komentarza.
- 35: CommentAuthormono
- CommentTime19 Nov 2009 zmieniony
Naprawione - były odwołania do starej tablicy nazw instrukcji (i skoki do procedur w romie basica), a powinny być do ramu.
Larek - z jakiego dosa korzystasz?
Dodana funkcja odpalania pliku D1:AUTORUN.BAS przy starcie basxa.

Edit: Błędy przy uruchamianiu AUTORUN.BAS są maskowane.
- basx4.obx
- 36:
  
  CommentAuthorlarek
- CommentTime19 Nov 2009
Generalnie to z MyDOS i ew. DOS II+/D oraz SDX.
Jeśli chodzi o ten efekt z ciemnym ekranem, o którym pisałem wyżej, to nie było żadnego DOSu - wczytałem plik obx zmieniony na xex.
- 37: CommentAuthormono
- CommentTime19 Nov 2009
Czy można w DOS II+/D wyłączyć ramdysk pod romem?
- 38:
  
  CommentAuthorPecus
- CommentTime20 Nov 2009
Można, opisane jest to tutaj: ->link<-
w sekcji "Dodatkowe możliwości uzyskiwane przez modyfikację pamięci." zaraz na jej początku. Czyli wystarczy z DOSa wydać rozkaz:
>070E 00
i zapisac taki dos na dyskietkie
IN#
Od tego momentu nie bedzie on zakładał ani formatował żadnego RAM-dysku.
- 39: CommentAuthormono
- CommentTime20 Nov 2009
Dzięki. Widziałem ten opis, ale potraktowałem go zbyt literalnie i myślałem, że ramdyski w tym dosie są zakładane zawsze ;)
- 40: CommentAuthormono
- CommentTime19 Dec 2009 zmieniony
Wersja trzymająca program w kolejnych obszarach:
- $D800..$FFF9
- $C000..$CFFF
- $A000..$AFFF
- memlo($2E7..$2E8)..memhi($2E5..$2E6)

1. Dodałem obsługę zmiennej ERRCOD ($B9=185) przy powrocie z USR dzięki czemu można w USR generować błędy obsługiwane przez TRAP (oczywiście wsteczna kompatybilność została zachowana i nie ustawienie zmiennej ERRCOD nie wpływa na nic :)).
2. Nie są adresowane jeszcze poprawnie stałe tekstowe (bo są pod romem - w kodzie programu) np. ?"BASX"; ADR("BASX") zwraca adres wirtualny (liczony od 0 - pamięć programu bazuje na adresowaniu wirtualnym).
3. Nie działają instrukcje LOAD/SAVE/CLOAD/CSAVE/RUN/LIST/ENTER ładujące/zapisujące stokenizowany kod programu z/na nośnik zewnętrzny.

Edit:
1. Działa na razie wolno, ale będzie szybciej.
2. Mruga podczas działania, ale jest to wina fontów - po podniesieniu romu ANTIC czyta fonty z RAM a nie z ROM, a tam znajduje się pamięć programu i pokazywane są krzaki.
3. ?FRE(0) zwraca 45409 z dos2.5+cp - bez zwraca 52070.
- basx5.obx
- 41: CommentAuthormono
- CommentTime20 Dec 2009 zmieniony
No i wersja kolejna.

Co to potrafi:
1. Obsługuje poprawnie stałe tekstowe.
2. Poprawnie działają operacje LIST I ENTER na urządzenie zewnętrzne.
3. Zmieniłem kod indeksowania zmiennych tekstowych.

Co nie działa:
1. CLOAD/CSAVE/LOAD/SAVE/RUN z/na urządzenia zewnętrzne(go).

Parę uwag.
1. Zaskoczyło mnie to, że AB ogranicza nazwę pliku do 255 znaków! Byłoby to logiczne dla stałych tekstowych (które mają maksymalny rozmiar 255 znaków), ale robi to również kiedy mamy zadeklarowaną i wypełnioną zmienną. Jeśli długość nazwy przekracza 255 znaków, wtedy jest ona obcinana do 255 znaków. Co więcej - na końcowej pozycji wstawiany jest znak EOL ($9B=155) bez względu na to, co leży za nazwą pliku! Oczywiście jest to po operacjach I/O odtwarzane, ale sam fakt że interpreter jest napisany tak, że może bez wiedzy użytkownika popsuć mu kod programu napawa mnie wstrętem :/.
Zamierzam się z tym również rozprawić - w SDX przecież nazwa pliku może być dłuższa!
2. Zmienne tekstowe mogą mieć teoretycznie dowolny rozmiar, ale porównywanie dokonuje się na pierwszych 32768 znakach. Poprawiłem - teraz można mieć 65536 :) Co prawda pamięć dostępna w niskim RAMie dla zmiennych tablicowych to max 24576 bajty (około $4000..$9FFF), ale może się to przyda w dalszych modyfikacjach ;)
3. Najważniejsza zmiana - zmiana zachowania podczas indeksowania zmiennych tekstowych.
Kiedy podczas pisania programu w AB zadeklarujemy zmienną tekstową A$ automatycznie otrzymuje ona długość 0 i jest wyświetlana PRINTem jako "". Można potem nią manipulować, rozszerzać
A$(1,length)=""

skracać
A$(length)=""

i wybierać podciągi
A$(first,last)

o rozmiarze co najmniej 1. Ale nie można za nic otrzymać pustego podciągu np. przez
A$(1+LEN(A$))

czyli podciągu o rozmiarze 0. Dodałem zmianę w kodzie indeksowania ciągu umożliwiającą otrzymanie podciągu pustego przy czytaniu końca ciągu:
A$(1+LEN(A$))

lub
A$(1+LEN(A$),1+LEN(A$))

Do tej pory podczas tych operacji wylatywał błąd 5 (indeks poza zakresem). Dlaczego ta zmiana? Wydała mi się kompletnie niespójna możliwość stworzenia zmiennej i niemożność odczytania jej wartości przez:
DIM A$(10): ? A$(1)

co upraszcza przecież kod, bo nie trzeba wtedy robić specjalnych rozgałęzień dla długości 0.
Indeksowanie ciągu zerem od zawsze powodowało błąd 5.
4. Wprowadzenie wirtualnego adresowania pamięci programu pociąga za sobą niestety to, że
ADR("cośtam")

zwraca adres wirtualny a nie rzeczywisty. Nie będzie w związku z tym poprawnie działać funkcja
USR(ADR("cośtam")...)

bo ADR wskaże adres nierzeczywisty. Poprawnie zadziała jednak ADR bazujące na zmiennej tekstowej np.
DIM A$(n): A$="program_maszynowy": ? USR(ADR(A$))

ale w pamięci znajdzie się on 2 razy - raz w stałej, drugi raz w zmiennej (tak, jak do tej pory). Aby poprawnie działało USR mógłbym przepisywać stałą do bufora tokenizacji ($480) w ADR i dopiero zwracać jej adres - wtedy z kolei wszystkie ADR na stałych zwracały by ten sam adres i porównanie
ADR("a")=ADR("b")

zwracałoby 1 (tak, jak aktualnie
CHR$(x)=CHR$(y)

z czym zamierzam się wkrótce rozprawić). Przeliczanie w ADR adresu wirtualnego na fizyczny jest połowicznym rozwiązaniem bo program trzymamy W BANKACH i może się zdarzyć, że stała znajdzie się na ich granicy - początek w jednym bank, koniec w drugim. Procedura maszynowa w USR rzecz jasna nie zadziała w takim przypadku poprawnie.
Poza tym program musiałby być uruchomiony z podniesionym ROMem!
5. W książkach Zientary jest masa błędów na których już parę razy pojechałem :/.

Zaskoczyło mnie to, że w AB NIE MOŻNA dostać się do adresu zmiennej tablicowej! Może by to zmienić rozszerzając działanie funkcji ADR? Będzie wtedy można przekazywać je do USR?

Program po relokacji zajmuje 8534 bajty a ?FRE(0) pokazuje 45229 (dos 2.5+cp) lub 51890 (ładowany na emulatorze bezpośrednio bez żadnego dosa).

Edit: Pomysł z przepisywaniem stałych tekstowych dla USR nie jest taki zły - będzie to działać poprawnie bo wiem, jak dobrze rozwiązać błąd z porównaniem CHR$ów.
- basx6.obx
- 42: CommentAuthormono
- CommentTime20 Dec 2009
Ciekawostka - co zwróci FRE(0), FRE(1) i FRE(-1) ? :D I dlaczego...
- 43: CommentAuthormono
- CommentTime22 Dec 2009 zmieniony
Kolejna wersja.
1. Uruchomiłem LOAD/SAVE/RUN/CLOAD/CSAVE (dwóch ostatnich nie mam jak sprawdzić chwilowo).
2. Odpala D1:AUTORUN.BAS.
3. Nie kasuje programu po wyjściu DOS i powrocie przez RUN.

Coś jeszcze nie działa dobrze z READ.

?FRE(0) pokazuje 44854 (dos2.5+cp) lub 51515 bez. Kod po relokacji zajmuje 8909 ($22CD) bajtów.
- basx7.obx
- 44:
  
  CommentAuthortdc
- CommentTime22 Dec 2009
Nieco o Action!

# urborg: "największym minusem jest brak pamięci. Każda liczba czy to stała czy zmienna to 8 bajtów gdyż jest ona traktowana jako liczba zmiennoprzecinkowa. Przechowanie dużej ilości parametrów w pamięci wymaga czasem absurdalnie dużo RAM-u."

Co prawda w Action! również najbardziej mnie męczy brak RAM, który ponoć i tak jest mniej dokuczliwy jak w TBXL, jednak w nim można zrobić kilka myków.
1. Zmienne można umieszczać w dowolnych miejscach pamięci, np. na 6 stronie lub nawet na stosie ;):)
2. Ponieważ Action! nie ma operacji zmiennoprzecinkowych to można zmienne wstawić pod $0580-$05FF ;)

Następnym ograniczeniem tego kompilatora jest ilość zmiennych na co przeznaczone są 2*2kb (wielkość tablicy symboli dla zmiennych globalnych i lokalnych). Wtedy można jak w asm korzystać z danych komórek pamięci jako ze zmiennych, nie jest to wygodne, ale jest! A ja w jednym z moich programów jestem powoli zmuszony do takiego działania :P ;)
- 45:
  
  CommentAuthorKaz
- CommentTime23 Dec 2009
Mono:
?FRE(0) pokazuje 44854 (dos2.5+cp) lub 51515 bez.

Miazga!
- 46: CommentAuthormono
- CommentTime23 Dec 2009
No miało być nieco lepiej (60kB) a wyszło gorzej :/
Powalczę jeszcze z błędami (CHR$, USR, 10 TRAP 10) i nazwami plików (żeby interpreter nie modyfikował programu użytkownika) i uruchomię pamięć dodatkową.
Potem jeszcze optymalizacje wykorzystania pamięci i poszukiwania linii programu, bo na razie jest strasznie wolne.
Fajnie byłoby mieć też dodatkową pamięć dla danych, ale to dalej spowolni działanie więc nie wiem czy jest sens.
- 47:
  
  CommentAuthorDracon
- CommentTime2 Jan 2010
Taki lekki offtopic, ale Basic wiecznie zywy:
->link<-

... jest na wiodace obecnie platformy sprzetowe, i np. pisanie srednio skomplikowanej przygodowki to pewnie w tym pikus! :)
- 48: CommentAuthormono
- CommentTime2 Jan 2010 zmieniony
Poprawiłem READ.
Można sobie odpalić np. "Hammurabi'ego" (a po zmianie HAMMUR.BAS na AUTORUN.BAS a BASX.COM na AUTORUN.SYS nawet odpalić z automatu) :).

?FRE(0) daje 44387 (DOS2.5+CP) lub 51048 (bez).
- basx8.obx
- habi.atr
- 49:
  
  CommentAuthorMaW
- CommentTime2 Jan 2010 zmieniony
no i przy przewijaniu o linię mam piękną kaszkę np. podczas ładowania listingów - tzn. jakby w charsecie coś się działo nie tegez ze znakami, DL dalej w porządku - to prawidłowo ?

no i po komendzie RUN basic się wiesza...
- 50: CommentAuthormono
- CommentTime2 Jan 2010
1. Kaszka jest wynikiem przełączania ROM/RAM (std. zestaw znaków jest pod $E000), bo przecież program trzymany jest pod romem.
2. Po RUN z DOS (przy poprzednim DOS z basxa), czy po RUN załadowanego programu przez LOAD (podeślij ładowany programik i napisz z jakiego dosa odpalałeś całość)?

Od 1 do 50 z 72