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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorgrego
   • CommentTime7 Sep 2012 00:09 zmieniony

    
   Tak sobie siedzę i myślę, że taki fajny jest ten turbo basic, ale programowanie w nim już jest dziś nieco uciążliwe (brak copy/paste, mały ekran itp).
   I wpadł mi do głowy taki pomysł, aby stworzyć edytor TB na PC, ale taki bardziej rozbudowany.
   Pisałoby się bez numerów linii. Można dodawać etykiety. Dodać nową komendę FUNC (arg1, arg2, ..., argn) zwracającą wynik. Może nawet struktury i proste klasy.
   Taki parser, który kod TB++ zamienałby na TB.
   Czyli np.
   
   TB++
   
   

   #LOOP
     ?"ATARI"
     G.#LOOP
   

   
   
   A parser zamieniłby na:
   
   

   10 ? "ATARI"
   20 GOTO 10
   

   
   
   (lub wykorzystując GO#)
   
   Następnie zapis jako ATASCII, na atr i wgranie poprzez ENTER"".
   
   Albo np. funkcja:
   
   

   FUNC RANDOM(A,B)
     RETURN INT(RND*(B-A))+A
   ENDFUNC
   
   #LOOP
     ? RANDOM(1,10)
     G.#LOOP
   

   
   
   na
   
   

   10 PAR1=1: PAR2=10
   20 GOSUB 1000
   30 ? RET
   40 GOTO 10
   1000 RET=INT(RND*(PAR2-PAR1))+PAR1
   1010 RETURN
   

   
   
   (czy też wykorzystując EXEC)
   
   To jest tylko zamysł. Wokół tego może być wiele innych wątków jak np.: odczytywanie i zamiana z TB na TB++, zamiana prostych podprogramów asemblera na FOR/NEXT/USR lub USR("krzaki"), ustalenie autonumeracji linii w wynikowym listingu - np. co 1 - itd, itp.
   
   Co Wy na to? :)
2. • 2: CommentAuthorBluki
   • CommentTime7 Sep 2012 00:09

    
   Dla tych co piszą na PC to może ciekawy pomysł. Ja wolę stare poczciwe 800XL, bo jeśli mam pisać na PC to po co mi Atari? PC to tylko zimna maszyna.
   
   I kto to miałby zrealizować.
3. • 3: CommentAuthorgrego
   • CommentTime7 Sep 2012 01:09 zmieniony

    
   Mam poczciwe 800XL również. Uwielbiam pisać w TB na "hardzie", ale zrobienie większego projektu można dzięki TB++ usprawnić.
   Przecież dlatego powstał Raster Music Tracker, Raster Converter, CC65 itd.
   
   I może z projektu TB++ nic nie wyjdzie, bo mamy w kraju najlepszych malkontentów, ale mamy także najlepszych koderów i może właśnie dlatego wyjdzie :)
   A piszę o tym dlatego, że jak będzie odpowiedni moral support, to może powstanie silna grupa pod wezwaniem TB++ :)
4. • 4:
      
     CommentAuthorlarek
   • CommentTime7 Sep 2012 08:09

    
   Czytając początek pomyślałem "o, super, ktoś w końcu zrobi edytor TB na PC". Jak doszedłem do końca trzeciego wpisu, to było już tylko "no i standardowo skończyło się na tym, że 'hej, mam pomysł - niech ktoś to zrobi'". Może się mylę, ale takie właśnie odniosłem wrażenie...
   Sam pomysł nie jest nowy. Uważam, że na PC przydałby się taki edytor TB. Nie ma potrzeby, żeby cokolwiek zmieniał w kodzie. Wystarczy, żeby pilnował składni, poprawności odwołań, par FOR-NEXT, DO-LOOP, itp., miał funkcję copy-paste i tego typu inne bajery.
   Generalnie jestem za. Jednak wiem, że samo się nie zrobi, a mam wątpliwości, czy ktoś, kto potrafiłby coś takiego napisać, zajmie się tym.
5. • 5: CommentAuthorwieczor
   • CommentTime7 Sep 2012 09:09

    
   Z tym, ze jak powstanie taki parser to nie ma sensu przekladac tego na TB bo rownie prosto/trudno (prosciej?) zrobic od razu kompilacje na maszynowke :)
6. • 6: CommentAuthorpin
   • CommentTime7 Sep 2012 09:09

    
   ... największą bolączką TBXL jest brak pamięci :)- Tak na prawdę, no dobra - oprócz tego edytora na PC (bo czemu nie) to przydało by się mieć odpowiednik trybu /EXTEND/ jak ma to miejsce w przypadku Basica XE. Nic mi więcej do szczęścia by nie było potrzebne.
7. • 7:
      
     CommentAuthorxeen
   • CommentTime7 Sep 2012 10:09

    
   edytory programistów są gotowe i otwarte. "wystarczy" dorobić dobre pluginy (np. do eclipse). poza tym nie chcę wyrokować i znowu robić za malkontenta i marudę, ale taka zmiana składni może się nie sprawdzić, jeżeli już ktoś pisze w TBXL to będzie musiał to opanować - tylko że lepiej wtedy opanować jeszcze zabugowanego ATALANA lub bardziej wygrzany CC65 - generują jako crossy od razu pliki wynikowe i są "dużo szybsze", pozwalają na wykorzstanie większej ilości pamięci.
8. • 8: CommentAuthorwieczor
   • CommentTime7 Sep 2012 11:09

    
   Dlatego też w tytule jest TB++ a nie XL :) Wydaje mi się, że proponowane zmiany są na tyle subtelne, że skutecznie usprawnią pisanie a nie wprowadzą konfuzji dla użytkowników TBXL. Przesiadka z języka basic-like na c-like może być bardziej bolesna - to trochę inna filozofia :)
9. • 9: CommentAuthorgrego
   • CommentTime7 Sep 2012 13:09 zmieniony

    
   To uściślę. Zarzucam temat, ponieważ jeśli będzie spore (?) zainteresowanie, pokłonie się ku tematowi.
   
   Założenia:
   
   - uprzyjemnienie pisania w TB (zdecydowanie najważniejsze)
   - jak najbliżej TB (jednakże z pominęciem numeracji - tym zajmie się parser)
   - łatwe do ogarnięcia makrodefinicje (jak wspomniana FUNC)
   - żeby nie odstraszało, że to jakoś jest wspólne z C++, zmieniam na TB+ (a i rozszerzenie będzie spójne dla listingów na PC - *.TBP)
   - kontrola składni
   - podgląd kodu TB jeszcze na PC
   - użycie w edytorze fonta zgodnego z Atari (serduszka i inne semigrafiki) z mapowaniem jak na Atari, np. CTRL+T = KROPA
   
   
   Oczywiście, że jest CC65, ale TB, to TB :)
   Łatwy i przyjemny. A o przyjemności tak naprawdę w życiu chodzi. Nieprawdaż? :)
   
   Marzeniem byłoby od razu kompilowanie i linkowanie do atarowego *.com, niestety tu już nie mam takiego skila... :(
   Dlatego pomyślałem o utworzeniu zespołu. Ja mógłbym zająć się kodowaniem edytora i parsera. Ktoś ze skilem 6502, mógłby zająć się modułem tłumaczenia podprogramów asemblera do krzaczków USR (chociaż z tego, co pamiętam, tłumaczenie z mnemoników na kod maszynowy nie jest aż takie trudne...) i Reverse Eng. kompilatora TBC i LINKERa, co w końcowym rezultacie mogłoby poskutkować exporterem jako *.COM
   Osoby z doświadczeniem TB, proszone są o składanie ficzer listy. :)
   
   Chętni? ;)
10. • 10:
       
      CommentAuthorxeen
    • CommentTime7 Sep 2012 14:09 zmieniony

     
    - użycie w edytorze fonta zgodnego z Atari (serduszka i inne semigrafiki) z mapowaniem jak na Atari, np. CTRL+T = KROPA

    
    
    to akurat się przyda niezależnie od języka - często mi tego bardzo brakowało :)
11. • 11: CommentAuthorwieczor
    • CommentTime7 Sep 2012 15:09

     
    @grego: o tym właśnie mówię - po cóż przekładać TB+ na TBXL - dodatkowy etap pośredni, skoro można od razu execa wyprodukować. Basic akurat ma filozofię liniową , jest bardzo bliski pod tym względem assemblerowi. W zasadzie translacja opierałaby się na przekładaniu kodu linia po linii, a runtime od TBXL mógłby tu pomóc (chociaż można by go usprawnić).
    
    A teraz uwaga :) Ja bym proponował dodanie etykiety INT/ENDINT z wariacjami np. INT VB, INT DLI i kodem do zdefinionwania w środku. Zgadnijcie do czego :)
12. • 12: CommentAuthorgrego
    • CommentTime7 Sep 2012 16:09 zmieniony

     
    @wieczór: bez quizuff :) dajesz! (vblanki, przerwania ;) no ale rozwiń...
    
    PS. zacząłem pisać... teraz etap zbierania klocków.
13. • 13: CommentAuthorbob_er
    • CommentTime7 Sep 2012 16:09

     
    1. @grego - jeśli uważasz, że pomysł jest ok, to go po prostu realizuj. wtedy ktoś może się dołączy...
    2. heh, a mi kiedyś chodził po głowie szatański pomysł napisania shella (na linuxa) zgodnego z tbxl :D (tzn. nadal krąży, ale ma bardzo niski priorytet).
14. • 14: CommentAuthorwieczor
    • CommentTime7 Sep 2012 17:09

     
    @grego: właśnie chodziło mi o przerwania. To tylko luźny pomysł, ale skoro miało by być to potem kompilowane na maszynówkę, może się udać. Zainspirował mnie Locomotive Basic na Amstrada - oferował przerwania wyzwalane zegarem. Trzeba tylko pomyśleć jak to zrobić aby zachować "bejzikowość" , to znaczy, programista TB nie może przejmować się pierdołami typu timingi czy odkładanie czegoś na stos, tudzież pilnowanie odświeżania rejestrów. To musi się dziać poza nim. Ja bym widział to tak, że jak procedura czasowo nie mieści się na przerwaniu to jest albo terminowana (gorsze rozwiązanie) albo zawieszana i kontynuowana w następnym - lepsze rozwiązania bo będzie cały czas chodzić w tle jak programista chciał, ew. nie tak szybko/często jak chciał, ale tu już musi pogłówkować.
    
    Oczywiście stosując proponowane wstawki w assemblerze może to sobie napisać sam, jednak fajnie by było jakby jeśli już to samo ciało procedury pisał, nie martwiąc się o okoliczne pierdoły - taki ukłon w stronę wysokiego poziomu. A przerwań do zajęcia Atari trochę ma. Zdecydowanie mogłoby to zdynamizować programy/gry w TBXL.
    
    Ale jak mówię - to luźny szkic pomysłu do przemyślenia, chociaż mam w głowie jak bym sobie wyobrażał działanie tegoż.
15. • 15:
       
      CommentAuthorKaz
    • CommentTime7 Sep 2012 18:09 zmieniony

     
    Rozwinieciem Turbo Basica XL na maszynach 16-bitowych byl GFA Basic - moze stamtad wziac jakies inspiracje do skladni?
16. • 16: CommentAuthor0xF
    • CommentTime7 Sep 2012 21:09 zmieniony

     
    Dodać numery linii można tak:
    

    perl -pi.bak -e 's//$.0 /' test.lst
    

    
    Edit: backslashe niepotrzebnie dodało forum.
17. • 17:
       
      CommentAuthorpirx
    • CommentTime7 Sep 2012 22:09

     
    nl input.tbp >output.tb
18. • 18:
       
      CommentAuthorpirx
    • CommentTime7 Sep 2012 22:09

     
    Nie potrafię tego zrobić, ale kompilację do xex mógłby zrobić "portable" emulator atarki z zaszytym TBC tak przerobionym, żeby wejściem i wyjściem był plik - H: ?
19. • 19: CommentAuthorstjack
    • CommentTime7 Sep 2012 23:09

     
    Grego - super sprawa! Kibicuję projektowi.
20. • 20: CommentAuthorgrego
    • CommentTime7 Sep 2012 23:09

     
    No to mały WIP ;)

    • TBP_WIP.png
      
      
      
      
21. • 21: CommentAuthorwieczor
    • CommentTime8 Sep 2012 00:09

     
    Ale ładne! W czym piszesz?
22. • 22: CommentAuthorPhilsan
    • CommentTime9 Sep 2012 09:09

     
    The best would be something like Visual batariBasic for Atari VCS:
    ->link<-
    A visual editor that automatically compile and run the code on the emulator.
23. • 23:
       
      CommentAuthormgr_inz_rafal
    • CommentTime11 Sep 2012 09:09

     
    Stworzenie edytora BASIC na PC chodziło mi po głowie w momencie, gdy po wielu latach wróciłem do Atari. Irytowało mnie ręczne numerowanie linii, a zwłaszcza konieczność przenumerowania jeśli kończyło się "miejsce" między linijkami. Ale... Po paru godzinach przywykłem do odpowiednio skonfigurowanego Visuala z zestawem paru makr. Programy w BASIC nie są tak duże, aby nie dało się ich w zasadzie ogarnąć nawet w Notepadzie.
    
    W każdym bądź razie jak najbardziej popieram pomysł stworzenia edytora, choć sam wolę zająć się czymś innym ;-) Może też dlatego, że raczej w BASIC już nie będę za wiele tworzył.
24. • 24:
       
      CommentAuthorMaW
    • CommentTime1 Nov 2012 21:11 zmieniony

     
    Tak przy okazji tablicy błędów basic-a ->link<- o której wspomniał Mono w tym wątku - wpiszcie w basicu prosty kod:
    

    10 ? "PROSTA PETLA"[ESC][ESC]FOR I=0 TO 9[ESC][ESC]? "MAGIA"[ESC][ESC]NEXT I

    
    może kiedyś był to bug, dla mnie obecnie jest to feature :D
    
    Tylko jeszcze formatowania wcięć brakuje :-)
    
    //EDIT [ESC][ESC] to oczywiście "widoczny znak <ESC>" (czyli 2x klawisz ESC)
25. • 25:
       
      CommentAuthortdc
    • CommentTime2 Nov 2012 02:11 zmieniony

     
    @mgr_inz_rafal edytor Action! zapisuje zawartość edytora jako tekst, a jako tekst można też zapisywać i odczytywać programy w Bascicach. Parę razy tak w dawnych czasach robiłem, polecam bo Action! ma fenomenalny edytor w porównaniu z tym systemowym.
    
    
    

    grego:

    Można dodawać etykiety. Dodać nową komendę FUNC (arg1, arg2, ..., argn) zwracającą wynik.

    
    Zgadzam się że to jedna z największych bolączek basiców, ale kwestia przekazywania parametrów ujawnia następną... jako osoba która pisała duży program w TBXL dodam że fatalne jest tam np. duże ograniczenie ilości zmiennych oraz dziwaczne przechowywanie w pamięci zmiennych które nigdzie nie są używane (i nie były). To z lekka się zazębia i potęguje problem.
    
    Wracając do tych parametrów to jeśli ktoś napisze duży program, a Ty do niego niejawnie dodasz następne zmienne to może się okazać że ten kod się nie uruchomi bo autor nie będzie wiedział ile dodaktowych zmiennych w kodzie się pojawiło.
    
    Mamy tu konflikt pomiędzy wygodą, a realnym praktycznym wykorzystaniem, we właśnie dużych programach bo tylko w takich jest sens kogoś wspierać.
    
    

    grego:

    Może nawet struktury i proste klasy.

    
    Klasy to podobny problem, zysk żaden a pamięć tracimy na choćby dostęp do składowych obiektów itp. w przypadku tak małej pamięci w pierwszej kolejności należy dodać do języka obsługę dodatkowej pamięci niż klasy (o czym pisał już Pin) oraz poszerzenia ilości możliwych zmiennych czy też obiektów i jego atrybutów (dodawanie obiektów do języka, który już ma duże problemy ze zmiennymi jest IMHO pomyłką).
    A jakby tego było mało przykładowo TBXL ma ten problem że zbyt wiele miejsca zajmują zmienne i stałe (na szczęście czasami można użyć %), co w całości ukazuje obraz nędzy i rozpaczy: pamięć, pamięć, pamięć...
26. • 26: CommentAuthorwieczor
    • CommentTime2 Nov 2012 10:11

     
    może kiedyś był to bug, dla mnie obecnie jest to feature :D

    
    
    Boskie! Formatowane linijki - tyle lat człowiek używał tego interpretera i nie wiedział o czymś takim
27. • 27:
       
      CommentAuthorlarek
    • CommentTime2 Nov 2012 10:11

     

    tdc:

    (...)jako osoba która pisała duży program w TBXL dodam że fatalne jest tam np. duże ograniczenie ilości zmiennych(...)

    
    Jako osoba, która pisała dużo programów w TBXL dodam, że ograniczenie ilości zmiennych do 256 (Atari Basic ma 128) nie jest absolutnie żadnym problemem. Nigdy nie spotkałem się z sytuacją, żeby mi brakło zmiennych.
    

    (...)oraz dziwaczne przechowywanie w pamięci zmiennych które nigdzie nie są używane (i nie były)

    
    Nie rozumiem. Skoro w pamięci (w tablicy zmiennych) są zmienne, to oznacza, że były użyte.
    

    jeśli ktoś napisze duży program, a Ty do niego niejawnie dodasz następne zmienne to może się okazać że ten kod się nie uruchomi bo autor nie będzie wiedział ile dodatkowych zmiennych w kodzie się pojawiło.

    
    To jakiś sztucznie wymyślony problem. Jak napiszę duży program, to dlaczego ktoś miałby dodawać do niego jakieś zmienne (i to jeszcze niejawnie), a później ja miałbym ponownie na tym pracować?
    Wszystkie zmienne użyte w programie można wyświetlić za pomocą instrukcji DUMP. Jeśli tablica zmiennych zawiera jakieś wpisy z nazwami zmiennych, których już nie używamy, to należy ją oczyścić i po kłopocie. A robi się to poprzez zapisanie programu poprzez LIST "D:xx", wykonanie NEW i ponowny odczyt poprzez ENTER "D:xx". Tak odczytany program ma czyściutką tablicę i nie zawiera niechcianych wpisów.
    
    

    co w całości ukazuje obraz nędzy i rozpaczy

    
    Wybaczam Ci, bo Cię lubię ;p
28. • 28:
       
      CommentAuthorlarek
    • CommentTime2 Nov 2012 10:11

     

    wieczor:

    może kiedyś był to bug, dla mnie obecnie jest to feature :D

    
    
    Boskie! Formatowane linijki - tyle lat człowiek używał tego interpretera i nie wiedział o czymś takim

    
    Nieźle wygląda, ale z edycją takiej linii będzie już mały kłopot :)
29. • 29:
       
      CommentAuthorjhusak
    • CommentTime3 Nov 2012 01:11

     
    brak copy/paste
    

    
    
    Jedno z pryncypiów programowania to:
    
    "Nie powtarzaj się"
    
    Więc copy-paste nie jest potrzebne, zwłaszcza w tak ograniczonej pamięci...
30. • 30: CommentAuthorgrego
    • CommentTime7 Nov 2012 21:11

     
    COPY/PASTE - raczej chodziło o reusy w kolejnych progsach. "Nie powtarzaj sie" sprawdza się w zakresie jednego listingu, ale nie wyobrażam sobie pisać bibliotek każdorazowo :P
31. • 31: CommentAuthorgrego
    • CommentTime7 Nov 2012 21:11

     
    A struktury kombinowałem oprzeć o stringi+dpeek/dpoke. Robiłem także testy z substringami, ale były mniej wydajne.
    Ofsety liczone iloczynem opóźniają działanie. Niestety, to tylko basic...
32. • 32:
       
      CommentAuthormgr_inz_rafal
    • CommentTime7 Nov 2012 22:11

     
    COPY/PASTE - również przydatne, przy zamianie bloków kodu miejscami i przy drobnym refaktoringu.
33. • 33: CommentAuthorbolo
    • CommentTime24 Jan 2013 23:01

     
    Apropos Batari Basic ktory zostal wczesniej wspomniany to polecam ciekawy filmik , kiedys pisalem w Basicu ale to lata swietlne wstecz, glownie bardzo proste programy oparte na komendzie input. Teraz nic kompletnie po tylu latach nie pamietam acha sorry pamietam jedna rzecz tzn petle bezkoncowa.
    
    1 ? "Jestes glupi"
    2 G.1(goto 1)
    
    
    
    Hehe tego sie nie zapomina(mam nadzieje ze sie nie pomylilem)
    
    
34. • 34:
       
      CommentAuthorKaz
    • CommentTime16 May 2013 11:05

     
    Odkopuje - Grego, czy jest jakis postep w pracach?
35. • 35: CommentAuthorgrego
    • CommentTime22 Aug 2013 14:08 zmieniony

     
    Kaz - dziękuję za zainteresowanie, które... jednak jest zbyt małe (vide moje powyższe posty). Odpaliłem wczesną alfę, jeszcze dużo do zrobienia.
36. • 36: CommentAuthorBluki
    • CommentTime22 Aug 2013 15:08

     
    Zbyt małe zainteresowanie?
    Osób piszących program jest znacznie mniej niż grających, a ci co piszą, też nie zawsze mają na to czas. W dodatku nie każdy lubi używać peceta do programowania. Dla mnie hobby to kontakt z "żywym" sprzętem, a nie "udawanym".
    
    Ponadto, tylko na AOL można zbierać na pęczki różnego rodzaju deklaracje, co to nie powstanie - a potem martwa cisza. Zapewne wiele osób, w tym ja, woli poczekać na konkrety, czyli działający program, niż chlapać ozorem po próżnicy.
    
    Jeśli zrealizujesz ten projekt, to będą tacy, którzy z niego skorzystają i będą zadowoleni, ale tłumów użytkowników bym się nie spodziewał.
    
    Weź przykład z mgr_inż_rafała, który po prostu robi swoje (ABC, czyli Atari Basic Compiler).