atarionline.pl Durny problem w Turbo Basic XL - Forum Atarum

    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.

    4. Programowanie / Programming  »   Durny problem w Turbo Basic XL

    W dół

    Od 51 do 97 z 97

    1. <
    2. 1
    3. 2
    4. >
      • 1: CommentAuthormono
      • CommentTime26 Nov 2009 12:11 zmieniony
       
      Tuż nad ekranem ulokowana jest displaylista, więc rozsądniej będzie użyć DPEEK(560) i od tego odjąć 40*192 - tam możesz spokojnie ulokować swoje dane. Przesuń jeszcze na wszelki wypadek MEMTOP (741) na bajt tuż przed twoim obszarem (DPOKE'm) wtedy basic na niego nie powinien wleźć ze stosem wykonania programu (przynajmniej ATARI BASIC - powinno tak też być w TBXL).
      • 2: CommentAuthortbxx
      • CommentTime26 Nov 2009 13:11
       
      Nie robie przełączania ekranów, tylko przenosze kawałki puzzli komendą move. Tak, że pamieć nad "klockami" jest wolna (nie siedzi tam DL)... i pod TBXL gra normalnie działa z muzyką. Problem pojawia się po skompilowaniu...
      • 3:
         
        CommentAuthorxeen
      • CommentTime30 Nov 2009 22:11 zmieniony
       
      jakiego playera używasz do muzyczki? męczę się z tym samym problemem, ale u mnie zwis nawet przed kompilacją (coś pewnie złego robię z pamięcią) :(

      edit:
      ok widzę, że music.rep - sorry
      męczę się dalej zatem.....
      • 4: CommentAuthormono
      • CommentTime30 Nov 2009 22:11 zmieniony
       
      Mogę dostać ten player (music.rep)? Zobaczyłbym czy nie używa ZPG...

      Edit: I jeszcze kawałek w BASICu, jak go wywołujesz.
      • 5:
         
        CommentAuthorxeen
      • CommentTime30 Nov 2009 22:11
       
      wywołanie zupełnie banalne, pewnie lamersko coś knocę

      10 POKE 106,PEEK(106)-16
      15 GRAPHICS 0
      20 CMC=(PEEK(106)+5)*256
      30 PLR=(PEEK(106)+6)*256
      40 OPEN #1,4,0,"D:FOREST.CMC"
      50 BGET #1,CMC,172
      60 CLOSE #1
      70 OPEN #1,4,0,"D:MUSIC.REP"
      80 BGET #1,PLR,1992
      90 CLOSE #1
      100 A=USR(PLR,1,CMC)
      • 6: CommentAuthortbxx
      • CommentTime30 Nov 2009 23:11 zmieniony
       
      music.rep z dyskietki "Chaos Music Composer 2.0 (v2).atr" dostepnej w tutejszym archiuwum, procedura wywołująca z przykładu demo.bas też z tej dyskietki - aczkolwiek wygląda dość podobnie do tej powyżej, z tym ze adresy PLR i CMC są pobierane tam z pliku. Podejżewam ze player xeen'a chce odgrywać muzyczkę z adresu w którym jej nie ma.
      • 7: CommentAuthormono
      • CommentTime30 Nov 2009 23:11 zmieniony
       
      Player lokuje się w obszarze $9000..$97C1. Na świeżym TBXL peek(106) zwraca mi 192 czyli RAMTOP jest w $C000 (dla odmiany w AB jest to 160 czyli $A000). Na pierwszy rzut oka wygląda na to, że:
      1. Playera spodziewacie się w $B600 a binarka jest przygotowana dla $9000 (1986 bajtów bo nie liczę nagłówka).
      2. Muzyki CMC spodziewacie się w $B500 - czy ona faktycznie ma 256 BAJTÓW tylko???? O ile pamiętam patterny zaczynały się w CMC od CMC+$300... ale mogę się co do tego mylić.
      Poprosiłbym jeszcze plik FOREST.CMC.

      Edit: Na pierwszy rzut zgrałbym playera z CMC podając adres $B600, albo ustawił RAMTOP absolutnie za pomocą POKE 106,$90.
      • 8:
         
        CommentAuthorxeen
      • CommentTime30 Nov 2009 23:11
       
      oczywiśćie, forest.cmc jest dłuższy
      • 9: CommentAuthortbxx
      • CommentTime30 Nov 2009 23:11 zmieniony
       
      ja w CMC zmieniałem adres muzyki (CMC) na $9B00 i adres playera (PLR) na $5900, tak jak pisałem nieskompilowana gra działa bez problemu z muzyką, po skompilowaniu emulator zawiesza się przy wywolaniu a=usr(plr,1,cmc)

      ps. pogodziłem sie już, że puzzle będą bez muzyki... jak je w końcu udostępnie, to może ktoś o wiekszych zdolnościach dorobi muzyczkę ;)
      • 10: CommentAuthormono
      • CommentTime30 Nov 2009 23:11
       
      Muzyka ulokowana jest w $8000..$8789 i zajmuje 1930 bajtów :)
      Powód, dla którego po skompilowaniu player nie działa może być taki, że korzystacie z adresów liczonych względem RAMTOP (106). Może po kompilacji RAMTOP jest inny? Musiałby się wypowiedzieć ktoś, kto zna TBXL wystarczająco dobrze.
      Player korzysta ze strony zerowej dobrze - nie powinien z niczym kolidować, bo komórki z których korzysta ($FC..$FF) odkłada na stos i potem przywraca.

      Proponuję jeszcze raz wygenerować w CMC binarkę dla CMC i REP pod konkretne adresy po czym wpisać je bezpośrednio do programu (na próbę). Jeśli zadziała znaczy, że faktycznie problem leżał w złych binarkach i (w przypadku problemów po kompilacji) w ustalaniu adresu względem RAMTOP.
      • 11: CommentAuthortbxx
      • CommentTime30 Nov 2009 23:11
       
      tak, w przypadku xeen'a adres wyliczny jest dla RAMTOP. Ja musiałem zmieścić się "nad danymi" obrazków, czyli adres wyliczam z DPEEK(88), 8kB pod nim jest pierwsza paczka 6kB danych obrazka, a 16kB pod nim jest druga paczka 6kB. Nad te paczki wpycham player i muzyke. Sprawdzłem tez czy DPEEK(88) zmienia się po kompilacji. Utawiłem aby A=DPEEK(88), po czym gra ustawiała GR.0 następnie ?A i END, po czym stwierdziłem że wartości przed i po kompilacji są takie same
      • 12: CommentAuthormono
      • CommentTime1 Dec 2009 00:12 zmieniony
       
      Czy będzie to RAMTOP (106), czy SAVMSC (88), czy DLPTRS (560) to nie ma znaczenia, bo te adresy są od siebie zależne. System otwierając tryb graficzny tworzy displaylistę i ekran następująco: bierze wartość RAMTOP i tuż przed nią umieszcza ekran, a tuż przed ekranem displaylistę. Ale widać, że nie w tym rzecz.
      Jeśli trzymasz dane za obrazem nie powinno być żadnych problemów. Być może TBXL korzysta ze standardowego AB włączając go "na chwilę" kiedy potrzeba i potem przywraca znowu RAM. Spróbuj umieścić playera i muzykę poniżej $A000 (40960) i skompiluj (nawet testowy program). Jeśli będzie ok to znaczy, że wykorzystywany jest ATARI Basic i trzeba uważać na obszar $A000..$BFFF.

      Edit: Player CMC gra muzykę w przerwaniach VBLKD i może się zdarzyć, że zastanie włączony Atari BASIC i pięknie pójdzie w maliny. Rozwiązaniem jest napisanie krótkiej procedury przerwania (ulokowanej poniżej $A000, a nawet dla bezpieczeństwa nie wchodziłbym też w obszar $4000..$7FFF) podnoszącej ROM BASICa i wywołującej playera po czym przywracającej konfigurację pamięci.

      Edit 2: @tbxx: Przepraszam - nie zauważyłem, że playera masz od $5900. Nie mam pomysłu czemu procedura odgrywająca wiesza kompilowany program. A możesz mi podesłać plik binarny (po skompilowaniu) i dokładną informację gdzie wrzuciłeś do niego playera i muzykę?
      • 13:
         
        CommentAuthorlarek
      • CommentTime1 Dec 2009 08:12 zmieniony
       

      xeen:

      40 OPEN #1,4,0,"D:FOREST.CMC"
      50 BGET #1,CMC,172
      60 CLOSE #1
      70 OPEN #1,4,0,"D:MUSIC.REP"
      80 BGET #1,PLR,1992
      90 CLOSE #1


      pliki *.cmc i *.rep są plikami dosowymi (z nagłówkami) i nie można ich wczytywać jak pliki danych. Należy to zrobić poprzez:
      BLOAD "D:FOREST.CMC" : BLOAD "D:MUSIC.REP"

      oczywiście wcześniej ustawiając odpowiednie adresy tych plików w CMC!

      Być może TBXL korzysta ze standardowego AB włączając go "na chwilę" kiedy potrzeba i potem przywraca znowu RAM


      Może po kompilacji RAMTOP jest inny?


      RAMTOP dla TBXL wynosi zawsze 192 i tego można się trzymać na sztywno. TBXL nie korzysta również z AB (?).

      Generalnie trudno coś Wam doradzić nie widząc całego kodu. Jedno mogą powiedzieć: CMC i TBXL wpółpracują ze sobą bardzo dobrze i przy prawidłowym umieszczeniu muzyki i playera w pamięci (tak, aby dane nie były np. później zamazane przez coś innego) wszystko powinno działać zarówno w interpretowanym jak i w kompilowanym TBXL.
      • 14:
         
        CommentAuthorxeen
      • CommentTime1 Dec 2009 09:12
       
      dzięki Panowie (głównie za cierpliwość), chyba mnie to naprowadziło
      to co muszę zrobić to ustawić adresy na sztywno w CMC - (zerknę do instrukcji) i używac BLOAD bo pliki zawierają adresy w nagłówkach.
      • 15: CommentAuthormono
      • CommentTime1 Dec 2009 10:12 zmieniony
       
      @larek: AB=Atari Basic :)

      Edit: Czyli TBXL ma cały swój kod pod romem systemowym?
      • 16:
         
        CommentAuthorlarek
      • CommentTime1 Dec 2009 11:12
       
      Nie no, to "AB" to wiem co oznaczało ;-)
      Mój znak zapytania wziął się z tego, iż zupełnie nie wiem, po co TBXL miałby korzystać z procedur AB? Ma swoje - szybsze :)

      Z tego co wiem, to TBXL ładuje się w miejsce Atari Basic oraz do RAM pod ROM-em (być może nie zajmuje jej całej - tego nie wiem).

      xeen:

      ustawić adresy na sztywno w CMC

      i weź poprawkę, że plik FOREST.CMC jest znacznie dłuższy od 172 bajtów, więc musisz odpowiednio przewidzieć miejsce w pamięci na dane muzyki.
      • 17:
         
        CommentAuthorxeen
      • CommentTime1 Dec 2009 12:12
       
      tak, wiem, to był gruby błąd
      dzięki :)
      • 18: CommentAuthormono
      • CommentTime1 Dec 2009 12:12 zmieniony
       
      Skoro ładuje się w miejsce BASICa,to dlaczego RAMTOP jest 192 (czyli wskazywałby na $C000 - początek systemowego romu)? Inaczej zarządza pamięcią niż AB? Nie działałyby programy korzystające ze sztuczki z RAMTOP i GR.x.
      Jeśli ekran byłby tuż nad RAMTOP a TBXL włączał "na chwilę" BASIC to widoczne byłyby śmieci na ekranie a nawet rozwalenie całej displaylisty (zw z czytaniem przez ANTIC kawałka romu a nie programu dl) - czyli nie korzysta a AB :).

      Edit: Pozostaje chyba więc tylko problem z nadpisaniem czegoś w pamięci.
      • 19:
         
        CommentAuthorlarek
      • CommentTime1 Dec 2009 12:12
       
      Tak, TBXL inaczej rokłada program w pamięci niż Atari Basic. Z tego względu programy napisane w AB i rezerwujące sobie w pamięci pewne obszary na swoje dane (w większości) nie będą poprawnie działać w TBXL. Niestety. Taki program musi być przerobiony do pracy w TBXL. Najcześciej polega to na przesunięciu danych trochę w górę pamięci.
      W sumie nie jest tak źle, bo programy w TBXL pisze się i uruchamia raczej w... TBXL ;-)
      • 20: CommentAuthortbxx
      • CommentTime2 Dec 2009 08:12
       
      larek - wielkie dzięki. W wersji pierwotnej "Warm Reset" na wersji skompilowanej powracał do gry, ale uniemożliwiał wczytanie danych z dyskietki. Po twoim skróceniu ładownia muzyki, gra wraca do menu programu "runtime.com". Podmieniłem tą kombinację PEEK na DPEEK, skróciłem "sekwencje" DIM, i teraz po "Warm reset" można spokojnie grać od nowa.

      Na koniec pytanie... czy 10 pierwszych komórek, zaczynając od 1536 jest zawsze pusta (0)? Czy też jeśli chce pobierać z tamtąd "0" to lepiej to wyzerować na początku gry?
      • 21:
         
        CommentAuthorlarek
      • CommentTime2 Dec 2009 08:12 zmieniony
       
      Cała 6 strona, czyli 256 bajtów od komórki 1536 nie jest ruszana przez system oraz Basic, więc po włączeniu komputera są tam zera.
      Nie wiem, jaki jest cel pobierania zera z tych komórek?
      Jeśli ma to jakiś sens ;-), to ja w swoim programie pewnie bym tak na wszelki wypadek obszar ten wyzerował (bo nigdy nie wiadomo, co użytkownik miał wcześniej uruchomionego) np. pisząc: 
      MOVE ADR("tu_wpisać_10_serduszek"),1536,10


      tu_wpisać_10_serduszek oznacza oczywiście aby w tym miejscu wpisać 10 serduszek ;-) - na klawiaturze Atari to Control+",", czyli znak ATASCII o kodzie 0. Cudzysłów oczywiście w ADR("...") musi być!


      edit:

      A wracając do skracania programu to takich możliwości w tym kodzie jest jeszcze dość sporo. Np. liczenie czasu oparte na komórkach 18-20. TBXL oferuje instrukcję TIME$=, którą możemy ustawić czas np. TIME$="233059" oznacza godzinę 23:30 i 59 sekund. Mamy do dyspzycji również zmienne systemowe TIME i TIME$ z których możemy odczytywać czas, a tym samym odpada nam samodzielne wyliczanie czasu na podstawie komórek 18-20, co znacznie ułatwia programowanie i skraca sam program.
    22.  
      hehe,

      this game reminds me of one of the old "puzzler" games, where one could load a standard gr. 7 (31 sectors) or a gr. 15 (62 sectors) picture and make a puzzle out of it.

      I have four versions of these puzzler games - you can find them attached here... (some of them might be in german language only). greetings, Andreas Koch.
      • 23: CommentAuthorpin
      • CommentTime6 Dec 2009 23:12
       
      .. TBXX - w drugim przykładzie, na początku topica czy czasem nie lepiej zastąpić jest warunki

      ..
      40 IF ...
      50 IF... itd

      czymś w stylu:

      B$=chr$(48+Z)


      ????? - będzie znacznie krócej :)))
      • 24: CommentAuthortbxx
      • CommentTime8 Dec 2009 14:12
       
      tak byłoby krócej, z tym że prezentowany fragment miał służyć konwersji obrazków do puzzli. W trakcie prac okazało się że dużo wygodniejszy jest G2F.

      ps. wkrótce powinna pojawić się poprawiona wersja puzzli... mam nadzieje że już nic więcej nie bedzie trzeba zmieniać
      • 25: CommentAuthorlhuven
      • CommentTime10 Mar 2010 21:03
       
      Ile można się nauczyć z lektury tego forum!

      Moja wiedza o Turbo Basicu jest dość skromna, ale ambicje i zapał twórczy - ogromne ;-) Szukałem sposobu w jaki sposób w programie zapisać i odczytać dane z dyskietki do obrazka w GRAPHICS 1 (ze zmienionego zestawu znaków). Odpowiedź znalazłem już w 1 poście tbxx. Dzięki!

      pozdrawiam serdecznie.
      • 26:
         
        CommentAuthorMaW
      • CommentTime11 Mar 2010 14:03 zmieniony
       
      Podepnę się: napisałem se procedurkę, która ma robić FILL na pamięci:
      1 DIM FILL$(255), A$(255)
      10 FILL$="BLA ":A$="SGHH RHFHRH N H SHRSH R RHSE NBRSNSRNBS RT":FILLADR=ADR(A$):FILL_LEN=20
      20 EXEC _FILL_AT_ADR
      32310 PROC _FILL_AT_ADR
      32311 .FILL$, FILLADR, FILL_LEN
      32312 N_=LEN(FILL$):II_=FILLADR+FILL_LEN-(FILL_LEN MOD N_):? N_;" ";II_
      32313 FOR I_=FILLADR TO II_ STEP N_:? I_:MOVE ADR(FILL$),I_,N_:NEXT I_
      32314 FILL$=FILL$(N_-(FILL_LEN MOD N_)+%1,N_):MOVE ADR(FILL$),I_,LEN(FILL$)
      32318 ENDPROC

      Gdzie:
      FILL$ - tablica bajtów, którymi będziemy wypełniać,
      FILLADR - adres początkowy obszaru,
      FILL_LEN - ilość bajtów, nak których ma być wykonana operacja

      Wywołanie: linie 1-20

      ...lecz gdzieś mam błąd i procedura się "wykrzacza" siejąc nie w tych miejscach, co trzeba :(

      //EDIT: chyba już widzę...
      //EDIT2: podmieniłem na poprawioną wersję i mam teraz error 5 w 32314 :|
      • 27:
         
        CommentAuthorPecus
      • CommentTime11 Mar 2010 15:03 zmieniony
       
      Tak samo zadziałają Ci dwa rozkazy wydane po kolei (ale będzie sporo szybciej). Nie zastosowałem tu żadnych zmiennych pomocniczych jak widać.

      MOVE ADR(FILLCHARS$),FILLADR,LEN(FILLCHARS$)
      MOVE FILLADR,FILLADR+LEN(FILLCHARS$),FILL_LEN-LEN(FILLCHARS$)


      przynajmniej teoretycznie, bo nie mam teraz jak sprawdzić :)

      A błąd masz pewnie dlatego, że bez sprawdzania dodatkowo warunków wejścia do procedury musisz wypełniać nią obszar mniejszy niż długość zmiennej tekstowej z której pobierasz dane do wypełniania.
      Ops chyba nie dlatego masz błąd, ale nie chce mi się szukać dlaczego, bo mam lepszą procedurę ;)
      • 28:
         
        CommentAuthorMaW
      • CommentTime11 Mar 2010 20:03
       
      Niech zgadnę:USR(cośtam,cośtam) ?
      • 29:
         
        CommentAuthorPecus
      • CommentTime11 Mar 2010 20:03 zmieniony
       
      Błąd :)

      Tę, którą podałem wyżej, czyli dwa MOVY... Powinny być tak samo szybkie jak USR(costam,costam,costam).

      Działają na tej samej zasadzie jak np. wypełnianie zmiennej tekstowej spacjami (czy innymi znakami) w zwykłym BASICU:

      DIM A$(1000):A$=" ":A$(1000)=" ":A$(2)=A$


      W zasadzie to też można w ten sposób zmienną tekstową dowolnym powielonym ciągiem wypełniać.
      • 30:
         
        CommentAuthorMaW
      • CommentTime11 Mar 2010 21:03 zmieniony
       
      a próbowałeś, czy to faktycznie działa dla wszystkich znaków ?

      w międzyczasie poprawiłem prockę :P :
      0 ------------------------------
      1 DIM FILL$(255), A$(255)
      10 FILL$="!@#_$%^":A$="SGHH RHFHRH N H SHRSH R RHSE NBRSNSRNBS RT":FILLADR=ADR(A$):FILL_LEN=20
      20 EXEC _FILL_AT_ADR
      25 ? A$
      30 FILL$="ABCDEF":A$="#%&$*@^! $^* @#^#& ^$ $*$#@&@$*$^($^":FILLADR=ADR(A$):FILL_LEN=2
      40 EXEC _FILL_AT_ADR
      45 ? A$
      50 END
      32000 ----------------------
      32310 PROC _FILL_AT_ADR
      32311 .FILL$, FILLADR, FILL_LEN
      32312 N_=LEN(FILL$):II_=FILLADR+FILL_LEN-(FILL_LEN MOD N_)
      32313 II_=II_-N_:IF II_>=FILLADR: FOR I_=FILLADR TO II_ STEP N_:MOVE ADR(FILL$),I_,N_:NEXT I_:ELSE:I_=FILLADR:ENDIF
      32314 IF (FILL_LEN MOD N_)>0: FILL$=FILL$(%1,FILL_LEN MOD N_):MOVE ADR(FILL$),I_,LEN(FILL$): ENDIF
      32318 ENDPROC

      Wypełnia dowolnym ciągiem znaków, gdy ilość znaków do przeniesienia jest mniejsza to obcina ilość znaków źródłowych do potrzebnego zakresu, gdy większa - powiela ciąg znaków do potrzebnego zakresu
      • 31: CommentAuthormono
      • CommentTime11 Mar 2010 22:03
       
      @MaW: Dokładnie to właśnie robi przypisanie (pod)ciągu znaków w BASICu. I śmiałbym twierdzić, że jest trochę szybsze ;)
      • 32:
         
        CommentAuthorMaW
      • CommentTime11 Mar 2010 22:03 zmieniony
       
      Nie no... ja się zabiję - jeszcze przed chwilą nie działało, a teraz zadziałało - kurde, aż odechciewa się pisać w TBXL :( :P
      • 33:
         
        CommentAuthorPecus
      • CommentTime11 Mar 2010 22:03
       
      Musiałeś cuś wcześniej pomylać :)

      Co prawda wszystko pisałem bez sprawdzania, ale to musiało działać :P
      • 34:
         
        CommentAuthorMaW
      • CommentTime11 Mar 2010 22:03 zmieniony
       
      No to poprawiłem dla... - gdy ciąg źródłowy jest dłuższy niż liczba znaków, którą trzeba przenieść, Twój sposób przenosił za dużo znaków (udało mi się nadpisać DL :D). Oto poprawka:
      1 DIM FILL$(255), A$(255)
      10 FILL$="!@#_$%^":A$="SGHH RHFHRH N H SHRSH R RHSE NBRSNSRNBS RT":FILLADR=ADR(A$):FILL_LEN=20
      20 EXEC _FILL_AT_ADR
      25 ? A$
      30 FILL$="ABCDEF":A$="#%&$*@^! $^* @#^#& ^$ $*$#@&@$*$^($^":FILLADR=ADR(A$):FILL_LEN=2
      40 EXEC _FILL_AT_ADR
      45 ? A$
      50 END

      32299 ------------------------------
      32310 PROC _FILL_AT_ADR
      32311 .FILL$, FILLADR, FILL_LEN
      32312 I_=ADR(FILL$):II_=LEN(FILL$):IF II_>FILL_LEN THEN II_=FILL_LEN
      32313 MOVE I_,FILLADR,II_: MOVE FILLADR,FILLADR+II_,FILL_LEN-II_
      32318 ENDPROC
      • 35:
         
        CommentAuthorPecus
      • CommentTime11 Mar 2010 23:03
       
      Bo proste dwa MOVY działają właśnie z założeniem że obszar wypełniany jest większy od wypełniacza, ja już przy nich warunku nie dopisywałem :)
      A czy wiesz że jest jeszcze rozkaz -MOVE :)
      • 36:
         
        CommentAuthorMaW
      • CommentTime11 Mar 2010 23:03
       
      tak wiem - siedzę w tych fatalnych instrukcjach i klnę przy każdej komendzie, którą chcę użć.

      BTW: jakaś szybka metoda na ustawianie/kasowanie konkretnego bitu ?
      • 37:
         
        CommentAuthorPecus
      • CommentTime12 Mar 2010 00:03 zmieniony
       
      W Turbo Basicu masz kilka komend działających na bitach (a właściwie nie tyle komend co operatorów).

      WYNIK=LICZBA ! LICZBA    - to binarne OR
      WYNIK=LICZBA & LICZBA    - to binarne AND
      WYNIK=LICZBA EXOR LICZBA - to binarne EOR


      ORem sobie zapalisz bit a ANDem zgasisz.
      Ja tam w TBasicu orłem nie jestem, ale jak coś to wal.

      W sumie zacząłem tłumaczyć oryginalną instrukcję TBASICA, ale ja po niemiecku tylko tyle umiem ile z Pancernych i Klossa zapamiętałem :), więc jeszcze trochę mi to zajmie. Na szczęście większość rozkazów znam z dawnych czasów, więc zawsze można samodzielny opis zrobić.
      • 38:
         
        CommentAuthorMaW
      • CommentTime12 Mar 2010 09:03
       
      Mam napisane coś takiego (poniżej), ale nie wiem, czy czasem nie jest tak "optymalne" jak ta moja procedurka do wypełniania pamięci :D

      10 CELL=559:CELLBIT=4:BITVAL=%1:.lub %0
      32300 PROC _SET_BIT
      32301 CVAL=PEEK(CELL)
      32302 IF BITVAL=%0:CVAL=CVAL&(255-%2^CELLBIT)
      32303 ELSE :CVAL=CVAL!(%2^CELLBIT)
      32304 ENDIF
      32305 POKE CELL,CVAL
      32308 ENDPROC
      • 39:
         
        CommentAuthorMaW
      • CommentTime13 Mar 2010 23:03 zmieniony
       
      Jak łączyć stringi w TBXL ?
      ...i czy można wyskoczyć z procki przed zakończeniem jej działania ?
      • 40: CommentAuthormono
      • CommentTime13 Mar 2010 23:03 zmieniony
       
      1:
      10 A$(1+LEN(A$))=B$

      2:
      EXIT

      Polecam: ->link<- i ->link<- .
      • 41:
         
        CommentAuthorMaW
      • CommentTime14 Mar 2010 00:03
       
      Oooo dzięki! Widzę, że lepsze niż spis instrukcji z "języki atari" ;-)
      • 42:
         
        CommentAuthorKaz
      • CommentTime14 Mar 2010 09:03
       
      Jak łączyć stringi w TBXL ?


      Piszesz dobra gre w TBXL, potem wystawiasz ja na targach, zatrudniasz albo zapraszasz hostessy, ktore nosza stringi i gotowe: stringi polaczyly sie dzieki TBXL:

      • 43: CommentAuthorlhuven
      • CommentTime14 Mar 2010 11:03 zmieniony
       
      Podepnę się pod temat. Używam Turbo Basic XL. Dlaczego w programie skonstruowanym w ten sposób, wywołanie procedury poprzez EXEC bezpośrednio z innej procedury, zżera każdorazowo 8 bajtów pamięci?

      (przykład 1)




      a w ten sposób jest OK? (przykład 2)



      Czy każde opuszczenie procedury poprzez wywołanie z niej innej procedury za pomocą EXEC daje taki efekt? I właściwie, dlaczego?

      Piszę programik w TBXL 1.5 i byłem w szoku, gdy zorientowałem się że dostępna pamięć kurczy się bez powodu w zastraszającym tempie. Jako totalny 'noob', przed zadaniem głupiego pytania, przewertowałem na szybko zasoby literatury w necie i nie znalazłem wytłumaczenia.

      Pozdrawiam!
      • 44: CommentAuthorilr
      • CommentTime14 Mar 2010 11:03 zmieniony
       
      Ponieważ wołasz procedury nawzajem (rekurencyjnie). Na stos odkładane są adresy powrotu z procedury i nigdy z niego nie są zdejmowane.
      • 45: CommentAuthorlhuven
      • CommentTime14 Mar 2010 11:03 zmieniony
       
      @ilr: Dzięki, chyba coś świta w mojej pustej łepetynie :D

      Wywołanie procedury z innej procedury jest OK, ale zapętlenie tego (druga procedura wywołuje potem z powrotem pierwszą) powoduje że powstaje błędne koło?
      • 46:
         
        CommentAuthorMaW
      • CommentTime14 Mar 2010 13:03
       
      to się nazywainfinite loop i jest znane jako jeden z poważniejszych błędów programowania :P
      • 47: CommentAuthorlhuven
      • CommentTime14 Mar 2010 14:03
       
      Maw: To dobrze ilustruje poziom moich umiejętności ;-) Nie no, ten programik to oczywiście tylko taka demonstracja :P

    Od 51 do 97 z 97

    1. <
    2. 1
    3. 2
    4. >