atarionline.pl Porady z komentarzy konkursowych - 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.

    • 1:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    Juz jakis czas temu postanowilem, ze zbiore wszystkie porady, ktore pojawialy sie w komentarzach i mailach do mnie, a dotyczacych konkursu "Napisze se". Poniewaz jest szansa, ze w przyszlym roku bedzie co najmniej jeden podobny konkurs - na Grzybsoniadzie, a moze i dwa, jezeli w przyszlym roku zrobimy dogrywke na atarionline.pl, to wszystko to moze byc przydatne.

    Zaraz zaczne tu wklejac ponizej wycinki, ktore potem poskladam w calosc i umieszcze w FAQ. Jezeli ktos zechce dodatkow cos skomentowac/sprostowac/uzupelnic/wyjasnic - bardzo prosze.
    • 2:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK O PMG:
    "Turbo Basic nie ma niestety specjalnych instrukcji związanych z grafiką PMG, ale jest to naprawdę bardzo łatwe. Choć łatwe nie oznacza, że proste ;-)

    Co trzeba zrobić, żeby ustawić duszki i zmieniać im kolor? Wpisać w rejestry położenia poziomego odpowiednie wartości, a w inne rejestry, odpowiedzialne za kolor duszków, odpowiednie wartości kolorów. Jak już duszki (statyczne) ustawisz, to one sobie będą tam stać. Nie ma potrzeby ciągłej ich kontroli.

    Po pierwsze proponuję skorzystać z książki ATARI BASIC Miguta. Masz taką książkę w swojej bibliotece. Na stronie 46 i 47 wydania w niebieskiej okładce (w innych nie wiem, ale pewnie to samo) jest krok po kroku wyjaśnione, co należy zrobić, aby na ekranie pojawił się duszek. Jest tam przedstawionych osiem prostych kroków, które należy uczynić i naprawdę jest to tak opisane, że nawet ja kiedyś to pojąłem. Wybaczcie, że odsyłam do lektury, ale tłumaczenie, jak się to robi polegałoby po prostu na przepisaniu tego, co jest w tej książce.

    Postaram się oczywiście bardzo ogólnie zarysować sposób postępowania, a bardziej zwrócić uwagę na pewne rzeczy.

    1. Trzeba zarezerwować w pamięci specjalny obszar dla PMG. W przypadku wysokiej rozdzielczości (wysokość poziomej 1 linii duszka = wysokość 1 linii skaningowej /1 linia w gr.15/) to musimy mieć na to aż 2KB. Przy niższej rozdzielczości (wysokość linii duszka = 2 linie skaningowe /2 linie gr.15
    lub inaczej - 1 linia gr.7/) wystarczy nam obszar wielkości 1KB
    Adres początku tego obszaru musi być podzielny przez 256.

    2. Duszki na ekranie są wyświetlane w postaci paska z góry na dół o szerokości 8 pikseli, tj. 1 bajt (szerokość można, jak pewnie wiesz, zwiększyć poprzez rozciągnięcie tych ośmiu pikseli w poziomie). Dane duszka są ułożone w pamięci RAM jeden po drugim, czyli np. dane pierwszej linii duszka są w pamięci pod adresem X. Pod adresem X+1 jest bajt reprezentujący drugą linię duszka. X+2 - trzecia linia duszka, itd., aż do 255, bo każdy z duszków (wysokiej rozdzielczości) może mieć wysokość 256 linii, czyli zajmuje w pamięci 256 bajtów. I tak kolejno 4 duszki. Są jeszcze pociski, ale na razie pomijamy to.
    • 3:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK O PMG 2:
    "Rejestry Atari kontrolują tylko położenie poziome duszka, czyli poprzez wpisanie do jednej komórki pewnej wartości (0-255) możemy przesuwać ten nasz pionowy pasek w lewo lub w prawo (nawet poza ekran). Nie ma czegoś takiego, jak położenie pionowe duszka. Jego fizyczne umieszczenie na ekranie (w pionie) zależy od tego, w którym miejscu pamięci pojawią się dane. Jeśli dane umieścimy w początkowych komórkach, to obraz pojawi się wyżej. Jeśli dane będą w środkowej części tych 256 bajtów, to obraz pojawi się w środku. Jeśli w końcowej części, to na dole ekranu. Ruch w pionie polega na przerzucaniu danych duszka bliżej lub dalej od początku obszaru duszków (w pamięci RAM), co objawia się na ekranie tym, że dane pojawiają się wyżej lub niżej (bo pamiętamy, że duszek to pasek od góry do dołu o szerokości 1 bajta). W programie, jeśli duszki miałyby mieć wysokość np. 80 linii, dane zajmowałyby 80 bajtów i byłyby umieszczone w pewnej odległości (=wysokości) od początku obszaru duszka(-ów). Jeśli ma to być pełne wypełnienie (bez specjalnych kształtów), to będzie to kolejne 80 bajtów zapełnione wartością 255 (=obsadzone wszystkie bity/piksele/ w danym bajcie). Jest tu dokładnie to samo, co mamy w znakach (fontach) - każdy bit w tym bajcie odpowiada za 1 piksel na ekranie. Tyle, że znak ma 8 linii (bajtów) wysokości, a duszek 256 (lub 128).

    Ustawienie kolorów i położenia poziomego jest realizowane przez zwykłe POKE. I jest to robione tylko raz, chyba że chcemy zmienić pozycję duszka. Zmianę kolorów duszka robi się dokładnie w ten sam sposób, co zmianę koloru np. ramki ekranu.

    Jak już ustalimy obszar i kształt duszków, to wystarczy poinformować system o tym, że chcemy włączyć duszki, podajemy ich rozdzielczość, priorytet i takie tam inne ważne dane i w zasadzie to wszystko.

    Bez obaw zajrzyjcie do książki, tam naprawdę jest to bardzo prosto opisane. Gdybyście mieli już jakieś konkretne pytania, to pytajcie. Chętnie odpowiem. Ogólny opis uruchomienia duszków wymaga sporo pisania i tak, jak wspomniałem musiałbym przepisać dwie strony z książki...

    Jako ciekawostkę dodam, że w grze PARACHUTE drzewa i ląd (to, co na ekranie jest brązowe), to właśnie takie statyczne duszki. Dlatego w grze mamy 5 kolorów, a nie tylko 4 (gra jest w graficznym trybie 15). W sumie, to mogłem lewe drzewo i ziemię zrobić w innym kolorze, a prawe w innym i byłoby 6
    kolorów. Że też o tym nie pomyślałem... :-). O ile pamiętam, to są wykorzystane cztery duszki i jeden pocisk. Ustawienie parametrów następuje zaraz na początku programu. Ja akurat wybrałem metodę wczytania kształtów duszków z pliku zewnętrznego (PMG.PMG), ale na początku dane te wprowadzałem ręcznie poprzez pętle FOR-NEXT i READ, POKE z danych w liniach DATA. Później zapisałem cały 2KB obszar pamięci PMG do pliku i było po sprawie. Możecie podejrzeć :-)

    Rzuciłem okiem na kod do PARACHUTE. Cała obsługa duszków znajduje się liniach 1019-1023. Do tego obszar 2KB od adres $9000, do którego wczytywane są dane (kształt) dyszków z pliku zewnętrznego (w linii 1014 - plik PMG.PMG) i to cała tajemnica duszków. Jedynie kilka Poke'ów ;-)

    Acha, jeszcze jedno. Przy włączonych duszkach, jeśli program wykona instrukcję GRAPHICS, to mamy kaszankę na ekranie. Po zmianie trybu graficznego (nawet na ten sam) musimy wskazać jeszcze raz systemowi nasz obszar pamięci duszków i chyba kilka innych danych."
    • 4:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    I link od Scalaka:
    ->link<-
    • 5:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK O KOMPILACJI:
    "Sprawa jest bardzo prosta.
    1. Uruchamiamy kompilator, tzn. piszemy coś w Dosie i kompilator się uruchamia ;-)
    2. Wkładamy dyskietkę z naszym programem do stacji (jeśli go nie ma na dyskietce wraz z kompilatorem)
    3. Naciskamy klawisz odpowiadający numerowi stacji, na której jest program źródłowy – w większości przypadków będzie to „1”. Możemy jednak dyskietkę z programem źródłowym włożyć np. do stacji nr 2 – wtedy wybieramy „2”
    4. Program wyświetli spis plików znajdujących się na dyskietce.
    5. Za pomocą kursora wybieramy nasz plik z programem źródłowym w TBXL i zatwierdzamy RETURN.
    6. Cierpliwie czekamy, aż kompilator skończy pracę. Odczytuje on sobie nasz program źródłowy z dyskietki linia po linii i umieszcza skompilowany kod w pamięci.
    7. Jeśli w programie wystąpiły jakieś błędy, to zostaniemy o tym poinformowani. Błędy mogą wystąpić nawet, gdy interpretowany program ich nie wykazuje! Bierze się to z tego, że kompilator sprawdza wszystkie odwołania w programie, pętle i takie tam różne sprawy. Wszystko musi mu się zgadzać!
    8. Jeśli proces kompilacji dobiegnie końca i nie otrzymamy komunikatu o błędach, to zostaniemy poinformowani o możliwości zapisania gotowej wersji programu. Zapis następuje o ile pamiętam tylko na dyskietkę numer 1, a nazwa musi mieć rozszerzenie CTB. Na poziomie kompilatora nie da się tego zmienić. Proponuję nadać plikowi nazwę AUTORUN.CTB
    9. Wychodzimy do DOS. Proponuje to zrobić poprzez „twardy” Reset, czyli Shif+F5 w emulatorze. Kompilator potrafi się dziwnie zachowywać po zwykłym przejściu do dosa (błąd jakiś, czy co?)
    10. W DOS uruchamiamy bibliotekę (RUNTIME lub lepiej RUNTIME2). Jeśli na tej samej dyskietce mamy również nasz skompilowany program z nazwą AUTORUN.CTB, to nic więcej nie musimy robić. Po wczytaniu się biblioteki nastąpi automatyczne odczytanie i uruchomienie naszego skompilowanego programu. Jeśli natomiast wymyśliliśmy sobie inna nazwę dla programu, to po załadowaniu biblioteki pojawi się komunikat o błędzie (braku pliku AUTORUN.CTB) i zostaniemy poproszeni o decyzję, co do dalszego działania. Możemy wtedy wybrać opcję Load i wpisać ręcznie nasz plik.

    To tyle na początek. Są jeszcze programy, które potrafią połączyć bibliotekę z programem w jeden plik, ale to już inna historia."
    • 6:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    CHARLIE CHAPLIN O LINKERZE:
    "Well,
    if you compile the game and it does not run too fast (meaning if the game is still playable after compiling), you may think: "Hey I have to load the Runtime which then loads the Autorun.CTB. It would be nice to have the program as *one* single file..."

    And this is possible with the CTB-Linker. Prepare a disk (130k or 180k) with the following files on it:
    - Runtime2.COM
    - Autorun.CTB (which is the CTB-Linker)
    - your "Parachute.CTB" (or any other CTB) program
    - and enough free sectors to fit for a *.COM program that has the size of your CTB program + 88 single sectors (the Runtime)...
    then do the following:

    1) binary load the Runtime2.COM (without Basic!)
    2) it will load the Autorun.CTB (the linker)
    3) which will load the Runtime2.COM again (ouch, but the linker was originally a TB XL file, thats why it loads the Runtime!)
    4) then you are asked which file to convert (source file), type in Parachute.CTB for example...
    5) the program then asks for the destination filename, type in Parachute.COM for example
    6) next the linker will save the runtime.com in a modified form and with the given destination filename on to disk in drive 1
    7) then the linker will load your *.CTB file and "append" it to the existing *.COM file (the modified Runtime)...

    In the end you have one single COM-File that can be loaded from DOS or Gamedos. Don`t forget to switch off basic (since the Runtime nor the modified Runtime will do that!) or simply add a basic-off routine to your new *.COM file created with the linker. When you load the program from DOS or Gamedos, you may notice, that there is no title for quite a long time (88 single sectors for the Runtime + xxx sectors for your CTB file), so maybe you want to add a title in front of the COM-file (right after the basic-off routine)...".
    • 7:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    PRZYKLADOWE PROGRAMY:

    ->link<-

    ->link<-
    • 8:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    PORADNIK SIKORA:

    "Dzisiejszego wieczoru pojawia się dłuższy tekst od Pawła "Sikora" Sikorskiego, który popełnił zarys FAQ - dodatkowe porady dla początkujących w Atari Basic/Turbo Basic XL:

    "Kilka uwag dla osób, które pod wpływem konkursu Kaz-a zaczęły tworzyć programy w Turbo Basic XL. Od razu zaznaczam, że nie jestem ekspertem w tej dziedzinie. Na pewno są osoby, które znają ten język dużo lepiej niż ja, ale to w tym przypadku może być zaletą – może ktoś pomoże napisać cykl artykułów dotyczących Turbo Basica XL? Oto lista przykładowych pytań, które moga paść:

    1. Czy jest gdzieś opis języka?

    Tak, w sieci jest kilka(naście, dziesiąt) stron z opisem języka. Naprzykład był prowadzony jego kurs w "Tajemnicach Atari" (polecam elektroniczne archiwum tego magazynu), był opisywany w "Bajtku", a pełen opis języka, ale bez przykładów, można znaleźć w książce Wojciecha Zientary „Języki Atari XL/XE cz.1”. (warto zajrzeć też do materiałów bibliotecznych - Kaz)

    2. Znam tylko Atari Basic, więc co dalej?

    To znakomicie. Wszystkie prawidłowo napisane programy w Atari Basicu działają także w TBXL, jak od tej pory będę skrótowo nazywał Turbo Basic XL. Osoby znające Atari Basic mają znakomitą podstawę do programowania w TBXL, który oferuje to wszystko co ten pierwszy i wiele dodatków. W drugą stronę też to działa, ale z pewnymi ograniczeniami – prawidłowe konstrukcje Atari Basica da się odczytać, ale rozszerzenia standardu już nie.

    3. Wywołania, procedury i inne takie

    W odróżnieniu od standardowego Basica, TBXL jest językiem opartym o procedury, co ma swoje niezaprzeczalne zalety. Tam, gdzie programista w Atari Basicu musiał się męczyć z pamiętaniem linii w przypadku skoków lub sterowania warunkowego (GOTO, GOSUB) – tu wywołujemy procedurę (EXEC nazwa_procedury). Budowa procedury jest następująca (numeracja linii przykładowa):

    100 proc Przykladowa: REM nazwa procedury
    101 … :REM treść procedury
    150 ENDPROC :REM koniec procedury

    Co ciekawe i co widać w powyższym przykładzie, TBXL nie jest czuły na wielkość liter przy pisaniu kodu, co jest ważne dla świeżo upieczonych programistów. Nazewnictwo procedur jest zasadniczo dowolne, przy założeniu, że nazwa składa się z liter i/lub cyfr i nie zawiera słów kluczowych języka (bez znaków narodowych!).

    Procedurę wywołujemy przez instrukcję EXEC, kilka przykładów (wywoływanie procedury o nazwie PRZYKLADOWA).

    10 EXEC PRZYKLADOWA:REM WYWOŁANIE BEZPOŚREDNIE Z LINII
    10 IF A$=”T” THEN EXEC PRZYKLADOWA:REM WYWOŁANIE Z WARUNKU
    10 FOR I=0 TO 9
    11 IF (IMOD3=0) EXEC PRZYKLADOWA
    12 NEXT I: REM WIELOKROTNE WYWOŁANIE Z WARUNKIEM W PĘTLI

    O czym należy pamiętać? Przede wszystkim o tym, że pierwsze wywołanie procedury (pamiętamy, nasze EXEC NAZWA_PROCEDURY) musi być przed pierwszą procedurą! Co jeszcze? Każda procedura w momencie zakończenia (ENDPROC) wraca do pierwszej instrukcji (uwaga! Przy niektórych warunkowych wywołaniach do pierwszej linii) po instrukcji wywołania. Każda procedura powinna się kończyć instrukcją ENDPROC (lub kilkoma takimi instrukcjami – możliwe wymuszenie warunkowego zakończenia procedury), jednak to nie jest sprawdzane przez kompilator.

    Pamiętamy także, że program w Basicu powinien się kończyć przez END – a taki najbardziej elegancko jest wstawić przed pierwszą procedurę (zakończenie procedury zawsze wyskakuje do instrukcji za jej wywołaniem). Kolejne procedury (a nawet tą samą, na przykład tytułową) można oczywiście wykonywać z kolejnych procedur."
    • 9:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    PORADNIK SIKORA 2:
    "4. Ułatwienia dla programujących

    listing z wcięciami, czytelniejszy kod: L + (wyłączenie – przez minus zamiast plusa)
    programowa obsługa klawisza BREAK (standardowy błąd obsługiwany przez instrukcję TRAP, a nie systemowe przerwanie działania programu): B +/-
    pusta instrukcja REM w formie dwu myślników (--) – oddziela „logiczne” części programu, tylko w celu poprawy listingu (krótsza od standardowego REM)
    instrukcja wyświetlająca użyte zmienne i stałe (tak jakby ich listing): DUMP
    renumeracja linii RENUM skąd, gdzie, jaki_skok
    dwubajtowy PEEK i POKE: DPEEK, DPOKE. Przykład użycia (tu przeniesienie obrazka tkwiącego pod adresem $7000 na ekran w grafice 8-mej BASICA):

    10 GR.24: REM tryb HIRES bez okna tekstowego
    20 MOVE $7000,DPEEK(88),7680

    Przeniesienie instrukcją MOVE z pamięci skąd (tutaj $7000 – tam przykładowo umieszczona grafika) do pamięci dokąd (tutaj odczytana dwubajtowa wartość początku ekranu: DPEEK(88)), wartości ile_bajtów (7680 – tyle ma standardowy obrazek)
    instrukcje pobierania i przenoszenia (BGET, BPUT, MOVE, BLOAD)
    Przykładów można mnożyć, jednak te na początek powinny wystarczyć, a w razie dalszych pytań odsyłam do Zientary i "Tajemnic Atari".

    5. Dlaczego gra wolno działa?

    TBXL jest językiem interpretowanym, więc każda instrukcja jest przetwarzana w trakcie realizacji. Są dwie zasadnicze metody przyspieszenia programu:
    optymalizacja kodu – warto ją zrobić zawsze, nawet gdy chcemy zastosować drugą metodę przyspieszania.
    kompilacja kodu – 95% prawidłowo napisanych programów daje się skompilować do języka maszynowego, a tam prędkość działania to już zupełnie inna bajka.

    6. Jak skompilować?

    Użyć zewnętrznego programu, który taką czynność wykona. Dodatkowo tak przetworzony kod – jeśli go chcemy uruchomić bez TBXL – wymaga dołączenia bibliotek. Załatwi to za nas LINKER (narzędzia są na mojej dyskietce). (te same narzędzia są też w dziale Użytki oraz na ostatnio prezentowanej dyskietce dla poczatkujacych - Kaz).

    7. Kłopocki, kłopocki?

    Trzeba pamiętać, że nie wszystko zechce od razy zadziałać. Należy wtedy spróbować zoptymalizować kod – to jest przyczyna najczęstszych błędów. Dodatkowo należy wiedzieć, że program skompilowany siedzi w innych miejscach pamięci niż nieskompilowany – może to spowodować na przykład błędy w grafice, muzyce, zawieszanie się programu. Jeśli program w TBXL działał prawidłowo, a po kompilacji i zlinkowaniu coś się dzieje – trzeba podejrzeć adresy pod jakimi obecnie siedzi program (na przykład przy pomocy Super Packera – jest na dyskietce wymienionej w linku) i skorygować ewentualną pozycję grafiki, muzyki, fontów… Jest to najczęstszą (przynajmniej u mnie) przyczyną złych objawów po kompilacji programów. Na koniec wyrażam cichą nadzieją, że mój mini-artykuł się komuś przydał i życzę sukcesów w pracy kodera onkursowego i nie tylko."

    Oryginalnie tutaj:
    ->link<-
    • 10:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    PROPOZYCJA PINa:
    "jeśli ktokolwiek ma problemy z programowaniem w TurboBasic XL - zapraszam na PRIV. Chętnie pomogę, w miarę moich możliwości. GG: 3249345"
    • 11:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    ROZNE:

    YOSH:
    Każdemu kto pragnie ściągi z mapy pamięci Atari polecam:
    ->link<-
    z dowcipem i o wszystkim (tzn adresy $0000 do $FFFF :P)

    PIN:
    aha - jeśli ktokolwiek kompiluje kod TB zawierający bodajże instrukcję DIV - koniecznie niech się zgłosi po poprawiony RUNTIME do mnie. Dodatkowo mam linker umożliwiający połączenie w jeden WYKONYWALNY :) plik programu po kompilacji z bibliotekami. Poprawki bibliotek RUNTIME są autorstwa Jacka Żuka - autora hardware'u KMK/JŻ IDE - czyli interfece'u IDE.

    MALY:
    da sie podzielic tu opis: ->link<-
    tak w TBXL da sie utworzyc displayliste przez dpoke
    • 12:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    ANONIM O ACTION:
    Dla piszących/chcących pisać w action!:
    ->link<-

    ->link<-
    ->link<-
    • 13:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK o BASIC-ach:

    Co do edycji programu w Basicu - jakoś chyba nie odkryję Ameryki, jak powiem, że w edytorze Basica :) Edytor Atari Basic jest na tyle user friendly, że wykrywa błędy składniowe zaraz po wprowadzeniu linii, no i możemy używać skrótów. Nie to, co edytor C= ;)
    Oczywiście najlepiej bawić się z edytorem Turbo Basica XL (można w nim pisać również program w Atari Basic, trzeba tylko pamiętać o tym, aby nie używać nazw instrukcji TBXL, których nie ma w AB lub poprzedzić je LET=...). Ma więcej możliwości czysto edycyjnych, np. renumerowanie, usuwanie linii. Osobiście nie wyobrażam sobie pisania programu w Basicu w innym edytorze, np. QA, Action!, Panther czy notatniku windy.

    Ja do informacji Larka dodam, ze troche o kompilatorach Basica przeczytacie tutaj: ->link<-
    Sa tam tez linki do poszczegolnych Basicow. Jeszcze jakby bylo malo to pamietajcie o katalogu uzytkow - tam mozna znalezc sporo przydatnych programow narzedziowych.
    • 14:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    YOSH O ACTION:
    zaczynam czytać (elektroniczne archiwum wymiata - acz Tylko o Atari 2 mam 'papierowe'):
    ->link<-
    • 15:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK i procedura odczytu grafiki:

    Kaz, nie wiem o jaką procedurę Ci chodzi, ale np. w TBXL może to być coś takiego:

    10 GR.24 : REM włączenie trybu 8 bez okna
    20 EK=DPEEK(DPEEK(560)+4) :REM początek pamięci ekranu
    ----------tu procedura odczytu grafiki z dysku---------
    30 O.#1,4,0,"D:GRAFIKA.GR8" :REM otwarcie pliku na dysku
    40 BGET#1,EK,7680 :REM wczytanie grafiki z dysku
    50 CL.#1 REM zamknięcie kanału
    --------------------------------------------
    -----------------
    60 GET KL :REM podziwiamy obrazek

    Na dyskietce musi być oczywiście zapisany obrazek w formacie GR8, czyli o długości 7680 bajtów. Taki plik generuje np. Design-Master lub Trzmiel. Nazwa pliku to oczywiście tylko przykład.

    PS. poleciałem z pamięci, ale powinno działać :)
    • 16:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    KAZ O ZRODLACH WIEDZY:

    Jeszcze taka mala pomoc dla zupelnie zielonych. Na serwer wrzucilem dyskietke z Turbo Basiciem - sam sie uruchamia, wiec jest wygodniej. Plik tutaj: ->link<-

    Do tego przyda sie AtrUtil, zeby dogrywac na dyskietke kolejne plki (np. przygotowana osobno grafike, etc):
    ->link<-

    W FAQ jest o tym, jak zrobic sobie samouruchamianie programow w Basicu: ->link<-
    Jest tam tez link do czystego dysku, przygotowanego, jak sie tam nagra PROGRAM.BAS, to gra bedzie potem sama startowac z dyskietki: ->link<-

    Jak sa inne podstawowe pytania to zadawajcie, to jest miejsce, zeby podzielic sie problemami. Ja tez po kilkunastu latach nie pamietalem prawie niczego w Basicu, szczegolnie, ze duzo w nim nie pisalem.

    Pamietam tez, ze jak z Larkiem i Urborgiem zaczelismy pisac Kolony2106 to na poczatku wszyscy mielismy klopoty organizacyjne - chocby taka niby prosta rzecz - jak wyluskac listing gry do postaci txt na pececie. Nie ma wiec co sie szczypac - jak macie nawet infantylne pytania - zadawac.

    A w dziale bibliotecznym jest mala ksiazeczka o Turbo Basicu. Nic wielkiego, ale moze sie przydac:
    ->link<-
    Ja znalazlem tam pare przydatnych informacji.
    • 17:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    ANONIM O WCZYTYWANIU GRAFIKI:
    Jeśli wczytujesz grafikę, to najlepiej jest ją wczytać metodą podobną do tej podanej przez Larka, ale nie pod zdefiniowany adres, tylko do zmiennej tekstowej.

    1) Definiujesz zmienną tekstową o odpowiedniej długości. 2) Zamiast adresu lub zmiennej z adresem ekranu podajesz adres początku zmiennej tekstowej (to bodaj funkcja addr, ale teraz nie jestem na 100% pewny).

    Zalety:
    - nie jesteś związany sztywnym adresem, nie przejmujesz się, gdzie to wrzucić, system załatwia to za ciebie,
    - powinno działać po kompilacji, bo system dostowowuje się do zmian w wolnej pamięci,
    - nie interesujesz się, ile zajmuje dos i gdzie są wolne miejsca w pamięci bo: jak wyżej,
    - masz dane dostępne na żądanie,
    - zamiast wrzucać do pamięci ekranowej po zmianie trybu graficznego (pamiętaj o użyciu +32, żeby nie kasowało ramu) ustawiasz adres początku ekranu na początek zmiennej (addr).

    Przy wczytywaniu .MIC wystarczy pamiętać że na początku są 4 bajty z kolorami, wystarczy zwiększyć zmienną o te 4 bajty, adres dla początku ekranu zwiększyć o 4, no i te kolory przekopiować do rejestrów lub ustawić ręcznie.

    Możesz zobaczyć taka procedur w Tajemnicach Atari, bo procedurę odczytu (i zapisu, bo używałem tego w swoich programikach do obróbki grafiki) zerżnąłem z jakiegoś programu w TBXL w TA. To był jeden z pierwszych numerów, program chyba robił coś z plikami Blazing Paddles, autorem
    był na pewno Carampuc.

    Jeśli coś pokręciłem ze względu na upływ czasu (ponad 10 lat
    w końcu…) to niewiele, ogólna idea powinna być poprawna.
    • 18:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK I ANONIM O WCZYTYWANIU GRAFIKI:
    @Stary Atarowiec: "[...] ustawiasz adres początku ekranu nu początek zmiennej (addr)."

    Nie bardzo. Sam napisałeś, że nie martwisz się, gdzie system trzyma te dane w pamięci. No i system trzyma, gdzie mu wygodniej. Jak teraz ustawisz pamięć ekranu na początek tej zmiennej i będziesz miał pecha, że dane będą leżeć na granicy pewnych obszarów w pamięci, to masz na ekranie "krzaki". Pamięć ekranu nie może zajmować dowolnego obszaru, a co za tym idzie, nie może zaczynać się w dowolnym (nieznanym) miejscu.

    Sposób na przechowywanie danych w zmiennej sam w sobie jest dobry, ale nie można ustawiać na niego pamięć obrazu. Co innego przerzucenie tych danych ze zmiennej do "prawidłowego" obszaru pamięci obrazu np. poprzez MOVE skąd,gdzie,ile (w TBXL oczywiście).

    I jeszcze jedno, ta funkcja to ADR.

    Stary Atarowiec @2008-11-08 00:17:43
    A być może, że właśnie przerzucałem przez MOVE. Bo ja to pamiętam… :/
    • 19:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK I ANDYGROO O GRAFICE:
    andygroo @2008-11-08 08:06:19
    ciekawe;) nie znam tego jezyka wcale, ale.........
    no wlasnie..larek wychodzi na to, ze atari basic turbo psuje ciagi tekstowe? bo leza na granicach pamieci? to juz chyba blad raczej. Mialbym zrobic dlugiego scrola (np tekst na parenascie kb a co) i by robilo w nim krzaczki????? larek twoje dzialanie pachnie asemblerem;p

    larek @2008-11-08 09:22:16
    TBXL nic nie psuje. Atari Basic zresztą też, a zachowuje się identycznie. To żaden błąd. To właściwość ANTICA i jego DL! Licznik pamięci obrazu układu ANTIC jest licznikiem 12-bitowym z 4-bitowym rejestrem kluczującym - cytuję z książki DeRe Atari :) - dlatego też zbiór danych ekranowych nie może znajdować się po dwóch stronach granicy przedziału 4K. Jeśli zachodzi taka konieczność, należy powtórnie użyć instrukcji LMS (w DL) w celu wpisania do licznika pamięci ekranowej adresu z nowego przedziału, co na poziomie programowania w Basicu jest raczej niemożliwe.
    Scrol na parenaście kb, to nie to samo, co pamięć ekranu.
    Pachnie asemblerem? Działanie? Ale o co chodzi? Funkcja ADR i instrukcja MOVE, to Basic w czystej postaci!

    andygroo @2008-11-08 10:33:06
    larek zle mnie rozumiesz lub sam sie zapedzasz....przechowuje cos w stringach i wrzucam to na ekran w kryteriach jakich dany komp [rzyjmuje....jak to moze byc zniszczone???????

    larek @2008-11-08 11:41:18
    Przechowujesz w stringach i PRZERZUCASZ (!) w odpowiedni obszar pamięci - no to OK!
    Zwróć uwagę na to, że Atarowiec pisał o przechowywaniu danych w stringach i USTAWIANIU pamięć ekranu na początek takiego stringa. Jeśli string leży w pamięci na granicy 4KB, to będzie problem, bo Antic błędnie to wyświetli. Chyba, że odpowiednio zmodyfikujesz DL, co programując w Basicu nie jest takie proste. Poza tym odpada tu argument "bezstresowego" przechowywania danych w pamięci. W takim przypadku (żeby umiejętnie zmienić DL) trzeba precyzyjnie znać położenie danych w pamięci. Skoro musimy znać miejesce, gdzie leżą dane, to wracamy do punktu wyjścia: po co nam do tego zmienne tekstowe? Wygodniej od razu przewidzieć na te dane miejsce w pamięci i nie bawić się w modyfikowanie "w locie" DL.

    larek @2008-11-08 12:22:16
    Tu masz przyklad na poprawne wyświetlanie obrazu - dane grafiki kopiujemy ze zmiennej do obszaru pamięci ekranu: ->link<-
    A tu przykład błędnego wyświetlania grafiki - pamięć obrazu ustawiamy na początek zmiennej, w której przechowywane są dane grafiki: ->link<-

    Stary Atarowiec @2008-11-08 13:52:00
    Im dłużej myślę, tym bardziej jestem pewien, że faktycznie używałem MOVE do przerzucania danych ze zmiennej do pamięci ekranu. Po latkach pamiętałem jedynie, że fonty można bodaj umieszczać co 4 KB, to chyba to samo zjawisko. Tłumaczono mi działanie licznika Antica, ale to za skomplikowane było dla mnie.
    • 20:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK O NUMERACJI W TB:
    "Gdybyś chciał w przyszłości zmienić numerację linii (co wg mnie będzie wcześniej lub później konieczne), to użyj polecenia RENUM x,y,z.
    X - to numer pierwszej linii, od której nastąpi renumeracja (leci do końca programu).
    Y - to nowy numer linii X
    Z - krok, z jakim kolejne linie będą numerowane.

    Przykład.
    LIST /PRZED:
    13 ?"PROGRAM"
    18 X=X+1: GOTO 99
    40 Y=X+2
    99 ?"KONIEC"

    RENUMERACJA:
    RENUM 18,100,10

    LIST /PO:
    13 ?"PROGRAM"
    100 X=X+1: GOTO 120
    110 Y+X+2
    120 ?"KONIEC"

    Renumeracja zachowuje wszystkie jawne odwołania do linii. Nie będzie problemu np. z GOTO xxx, czy RESTORE xxx. Niestety niejawne odwołania, np.: GOTO xxx+wartość_zmiennej lub RESTORE xxx*wartość_zmiennej - najprawdopodobniej będą wskazywać niepoprawne adresy po renumeracji."

    Przypominam, ze chodzi o Turbo Basic.
    • 21:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK:

    Jeszcze pare porad od Larka:

    POKE 559,0 wyłącza ekran (przyspieszenie obliczen)
    POKE 559,34 włącza ekran

    Tak na wszelki wypadek coś, co może się przydać przy pisaniu po ekranie ;-):

    POKE 752,2 wyłącza znacznik kursora
    POKE 752,0 włącza kursor

    POKE 731,0 - włącza klik klawiatury
    POKE 731,1 (a w zasadzie każda wartość większa od 0) - wyłącza

    jak zastopować wykonywanie programu (TB) pod emulatorem - pętla nieskończona... ?
    a) PAUSE czas - czas=50=1sekunda.
    b) GET X - oczekiwanie na wciśnięcie klawisza. W "X" odkładany jest kod ATASCII naciśniętego klawisza. Można to później wykorzystać.
    c) WHILE STRIG(0):WEND - oczekiwanie na wciśnięcie Fire w joysticku.
    d) Jeszcze STOP...
    e) klawisz BREAK
    • 22:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    SCALAK i KAZ:

    Scalak @2008-11-13 11:40:04
    mam jeszcze jeden problem... jak wczytać do emulatora plik z programem (txt)? listować na printer umię, ale odwrotnie już nie :(. Utworzyć atr i załączać pliki też potrafię.

    Kaz:
    Druga sprawa: jezeli masz program AtrUtil, to odczytaj swoj dysk, na ktorym pracujesz, potem uzyj opcji Insert txt (podaje z pamieci, bo nie mam teraz tego przed soba) i wskaz plik txt, ktory chcesz wrzucic na dysk. Do plikow nie-tekstowych stosuje sie Insert bin.

    Scalak:
    wrzucam ten plik i jak w TB daje LOAD "D:plik.txt" to wywala: ERROR- 21 ?LOAD

    Kaz:
    uzyj komendy ENTER - do odczytu pliku, a LIST zeby zapisac.

    Scalak:
    Czy jezyk TB udostepnia tablice?

    Kaz:
    Tak, Turbo Basic to prawie zwykly Basic, tylko uspranwiony :).
    • 23:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK O GRAFICE:

    >A da sie zrobic, zeby przed gra zaladowac obrazek GR.8,
    >potem wycinac z niego kawalki do zmiennych tekstowych i wstawiac je
    >podczas przechodzenia z jednej lokacji do drugiej? Wolalbym unikn¹æ
    >doladowywania obrazkow w trakcie gry.

    Mo¿na, mo¿na, choæ nie wiem, czy uda mi siê to w prosty sposób wyt³umaczyæ.
    Spróbujemy na przyk³adzie.


    10 DIM PE$(7680) 'tu sobie rezerwujemy zmienn¹ tekstow¹ (P-amiêæ E-kranu) o
    d³ugoœci 7680, czyli tyle ile wynosi obraz w GR8 (192 linie x 40 bajtów
    ka¿da)
    20 PE=ADR(PE$) ' tu odczytujemy adres pocz¹tku tej zmiennej, ¿ebyœmy
    wiedzieli, sk¹d póŸniej czytaæ dane
    30 O.#1,4,"D:OBRAZEK.GR8":BGET#1,PE,7680:CL.#1 'odczytujemy obrazek z dysku
    i umieszczamy w zmiennej
    40 GR.24: EK=DPEEK(DPEEK(560)+4) 'w³¹czamy tryb 8 i zapamiêtujemy adres
    pocz¹tku pamiêci obrazu

    Teraz mamy ju¿ obrazek w pamiêci (schowany w zmiennej) i wiemy, gdzie jest
    fizyczna pamiêæ ekranu.
    Jeœli chcemy teraz wyœwietliæ nasz obrazek na ekranie, wystarczy przenieœæ
    dane ze zmiennej (a dok³adnie z pamiêci, która jest zarezerwowana dla tej
    w³aœnie zmiennej) do pamiêci ekranu. Robimy to w nastêpuj¹cy sposób:

    50 MOVE PE,EK,7680 'sk³adnia instrukcji jest taka: MOVE
    sk¹d,dok¹d,ile_bajtów. W tym przypadku przenieœliœmy ca³y blok 7680 bajtów
    ze zmiennej do pamiêci ekranu. Mo¿na oczywiœcie przenieœæ dowolny fragment
    ze zmiennej w dowolne miejsce ekranu, np.:

    50 MOVE PE+40*80,EK+40*20,40*100 'tu przeniesione bêdzie 100 linii obrazu
    (po 40 bajtów ka¿da) od 80-tej linii i umieszczone od 20-tej linii na
    ekranie. Ta liczba "40" w ka¿dym przypadku jest konieczna do tego, aby
    prawid³owo wyliczyæ fizyczny adres - ka¿da linia obrazu zawiera 40 bajtów
    danych. Mo¿na oczywiœcie wycinaæ "nierówno" bajty - bez podzia³u na pe³ne
    linie. Wystarczy sobie to odpowiednio wyliczyæ. Nale¿y pamiêtaæ tylko, ¿e
    pamiêæ w komputerze jest liniowa: zawartoœæ 40-tego bajtu wyœwietla siê w
    prawym górnym rogu, a wartoœæ 41-szego bajtu to pocz¹tek drugiej linii i
    wyœwietli siê z lewej strony na drugiej pozycji od góry. Zauwa¿, ¿e operuj¹c
    bezpoœrednio na pamiêci pos³ugujemy siê ca³ymi bajtami. Jeœli chcemy
    wy³uskaæ z tego poszczególne bity, czyli dostaæ siê do ka¿dego punktu na
    ekranie, to musimy ingerowaæ w te bajty, co jest raczej ci¹¿ka spraw¹.

    Mo¿emy siê pokusiæ np. ³adne efekty:

    50 FOR Y=0 to 191
    60 MOVE PE+Y*40,EK+191-Y*40,1*40
    70 NEXT Y

    Lub

    50 FOR Y=191 to 0 STEP -1
    60 MOVE PE+Y*40,EK+Y*40,40
    70 NEXT Y

    Lub

    50 FOR Q=0 TO 7
    60 FOR Y=Q TO 191 STEP 8
    70 MOVE PE+Y*40,EK+Y*40,40
    80 NEXT Y
    90 NEXT Q

    ¯eby móc podziwiaæ te przyk³ady, to trzeba pamiêtaæ o ostatniej instrukcji,
    która wstrzyma dzia³anie programu, np.:

    200 GET KL: GET KL 'oczekiwanie na wciœniêcie klawisza (na wszelki wypadek
    x2)

    Tego ostatniego przyk³adu nie jestem pewny, bo wszystko piszê z g³owy. U
    mnie w g³owie to dzia³a, ale w rzeczywistoœci mo¿e byæ zonk ;-)


    Jeœli zajdzie potrzeba wyczyszczenia obrazu w trybie graficznym, to TBXL
    oferuje tu instrukcjê z której warto skorzystaæ - CLS#6.

    Mam nadziejê, ¿e opisa³em to wszystko w taki sposób, który da siê zrozumieæ
    ;-)
    Niestety bez w³asnych eksperymentów zapewne siê tu nie obejdzie.
    • 24:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    LAREK O NUMERACJI:
    Poza tym, jak ju¿ wczeœniej pisa³em, w TBXL numeracja jest wprawdzie
    konieczna, ale nie musimy z jej dobrodziejstw/ograniczeñ korzystaæ.
    Wystarczy, ¿e fragmenty, do których bêdziemy siê odwo³ywaæ oznaczymy
    etykietami, np.: #PETLA, #KONIEC, #DALEJ, #ETAP2 (etykieta musi byæ
    umieszczona na pocz¹tku linii!)
    Skok do takie etykiety nastêpuje poprzez: GO#PETLA, GO#KONIEC, itd.
    Nie musimy w takich przypadkach znaæ numerów linii.
    • 25:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    KAZ:
    To moze sie jeszcze przydac: kody bledow oraz bugi TBXL:
    ->link<-
    • 26:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    INNE DYSKUSJE NA FORUM o PROGRAMOWANIU:

    O Action!:
    ->link<-

    O RAM-dysku:
    ->link<-

    Podstawy o plikach Atari:
    ->link<-

    Larek o Display List:
    ->link<-

    O dzwiekach do gry:
    ->link<-
    • 27:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    ROZYK:

    PS. Ciekawostka. Jak otrzymać czysty listing programu Basicowego w pliku tekstowym. Wczytuję program do Basica, zapisuję przez LIST „D:nazwa.lst”, wyciągam plik z ATR’a Windows Commanderem z odpowiednią wtyczką plik i zAtati800Win używam konwertera ATASCII to ASCII.
    Pewnie wszyscy wiedzą jak to robić, nawet pewnie łatwiej, ale na wszelki wypadek daję przepis.
    • 28:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    URBORG O EDYCJI w TB:

    Urborg @2007-07-10 08:07:58
    Przeklepywanie tego to wyważanie otwartych drzwi :-). Nie mam tu na myśli faktu że gra jest już dostępna, tylko samą czynność wpisywania programu.

    Wystarczy bowiem zaznaczyć tekst i skopiowac do notatnika. Usunąć zbędne entery, tak żeby enter był jedynie na końcu linijki. Potem zapisujemy plik np. jako "gra.txt". W emulatorze robimy konwersję ASCII->ATASCII z z opcją "EOL only". Następnie uruchamiamy MakeAtr i tworzymy dyskietkę do której dołączamy skonwertowany plik. Potem zaś wystarczy uruchomić Basic pod emulatorem, podpiąć dyskietkę i załadować program komendą ENTER.
    • 29:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    URBORG:

    Pytanie kogos:
    Pozwolę sobie mały OT... Jakim sposobem wkleić napisany pod blaszakiem kod do naszego emulka? Nie widzę takiej opcji w emulku, a za bardzo nie wiem w jakim formacie powinienem zapisać plik tekstowy na dyskietce (makeATRem), aby potem go zgrabnie wczytać. Jak to zrobić odwrotnie? Czyżby był jakiś fajny konwerterek txt2xxx?

    Urborg:
    To może ja pomogę. Można to zrobić tak: Gdy mamy gotowy tekst programu zapisujemy go jako plik "txt". Następnie trzeba zrobić konwersję do Atascii ze względu na inny sposób kodowania końca linii. Tutaj można się posłużyć emulatorem Atari800win. Wchodzimy w opcję "Convert", "Ascii to Atascii", wskazujemy plik i wybieramy opcję "EOL only". Potem uruchamiam program "MakeATR" i dodaję skonwertowany plik do dyskietki (pliku atr). Potem podpinamy plik do stacji dysków w emulatorze i wczytujemy program Basicową komendą "Enter"

    Jak zrobić odwrotnie? Czyli wylistować program do powiedzmy windowsowego notatnika? Jest w emulatorze plugin do drukarki. Trzeba go skonfigurować aby wysyłał tekst do programu Notanik. Sorki, nie powiem z pamięci co tam trzeba wybrać i zaznaczyć. Jest to dosyć proste. Jakbyś sobie nie radził to daj znać to wtedy sprawdzę i napiszę co tam dokładnie trzeba zrobić.
    Potem wystarczy wpisać w basicu
    LIST "P:" i po chwili otworzy się nam okienko Notatnika z listingiem programu.
    • 30:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    O GRAFICE:

    Pytanie: Jak skonwertowac grafike z PC na format Atari (MIC)?

    PPS (StarSoft Berlin):
    For this simple problem I wrote the TIF2PIC tool. As of a bug with input in QUICK there is only a beta version available. It´s fully working, but you can´t change the loading & saving filename. So it´s a little odd to convert more than one picture a time...

    ATARIXLE (autor X-Boss):

    Here are some programs written in Turbo-BASIC. Please watch the Source-Code to understand the programs!

    BMP2MIC.TUR - old program ... converts a 160 x 192 x 8Bit - Picture (saved by Corel Draw 7, or Windows Paint) to MicroPainter
    GMP2MIC.TUR - the same ... but the pictures were saved by GIMP (seems like the header is a little different from the others)
    GMP2MICR.TUR - the same ... but I forgot, what was special in this version
    All these programs work the same way:
    Enter the full path to the picture, wait some hours while loading ... Then, the program stops - this is no error. Now you have time to enter some SETCOLORs (the programs does not convert colors!). When you CONTinue the program, you can enter a filename for saving.
    Please note, the Picture may be saved in 8 Bit, but of course its only usefull, when the palette has not more than 4 colors (like GRAPHICS 15 has).

    INVERTMIC.DLL - inverts a micropainter-file and reverses the 4-color-palette, so the result looks the same - only the bordercolor now is that, what color 3 was before.
    Do not RUN this program! At first, LOAD it, change the filename(s) right in the listing and then you can run it (not very userfrienldy, but a good base for a later all-in-one-app).

    BMPTO256.TUR - converts a 80 x 96 x 8 Bit - Picture to Paint256
    B24TO256.TUR - converts a 80 x 96 x 24 Bit - Picture to Paint256 (GIMP-Users: NOT 32 Bit RGBA! Switch to 24 Bit while saving!)
    These programs will also convert the colors (from RGB to ATARI).

    All these programs have in common, that they are very slow on a real ATARI, so it is more usefull to run them on an Emulator at full-speed. Use the virtual drives H1: - H4: to make them able to access the PC-files.

    PHILSAN:
    After having tested all your interesting programs, I think this is the best solution to transfer graphics mode 15 pictures from PC to Atari:
    - draw a 160x192 4 color image using your preferred PC program and save it in .bmp format
    - start Graph2Font, select 40 byte screen, select GED-- mode, load your .bmp image, turn off the last 6 lines by clicking with left mouse button over the numbers in the left column switching them to 0, save in .mic format
    - insert the .mic file in an .atr image using MakeATR
    - load the image in Turbo-Basic XL using the following code:

    CODE
    200 GRAPHICS 15+16
    210 DIM FILE$(12)
    220 FILE$="D1:IMAGE.MIC"
    225 S=PEEK(559):POKE 559,0:REM IF YOU WANT TO TURN OFF SCREEN WHILE LOADING
    230 OPEN #%1,4,%0,FILE$
    240 BGET #%1,DPEEK(88),7680
    250 BGET #%1,712,%1
    260 BGET #%1,708,%3
    290 CLOSE #%1
    295 POKE 559,S:REM TURN ON SCREEN
    • 31:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    Ufff... to na razie tyle co znalazlem w mailach, komentarzach. Oczywiscie na roznych stronach i forum jest tego multum.
    • 32:
       
      CommentAuthorKaz
    • CommentTime10 Dec 2008
     
    @czy da się sprawdzić w basicu jaki klawisz (lub kombinacja np. ctr+cos tam) został ostatnio wcisniety na klawiaturze?

    sikor @2008-12-10 18:09:54
    Da się. GET KEY w turbo basicu na przykład lub PEEK 764 - o ile dobrze pamiętam.

    xeen @2008-12-10 18:15:01
    dzieki Sikor , to jest to (trzeba wiedzieć co wpisac w google :)))
    znalazłem, czego szukalem
    10 A = PEEK(764)
    20 IF A = 63 THEN GOTO 100
    30 GOTO 10
    40 END
    100 PRINT "AN 'A' WAS HIT!"

    mono @2008-12-10 21:45:10
    Z komórką 764 jest pewien problem :) Systemowe procedury odczytu klawisza przyjmują, że wartość 255 ($FF) oznacza brak wciśniętego klawisza. Co nie do końca jest prawdą, bo POKEY wartością 255 sygnalizuje wciśniętą kombinację SHIFT+CONTROL+A. Można to łatwo zaobserwować wciskając tę kombinację klawiszy podczas trybu przyciągania uwagi (POKE 77,128).
    Gdyby ta kombinacja nie była obsługiwana, wtedy komputer nie zareagowałby na wciśnięcie, jak to się dzieje w przypadku np. SHIFT+CONTROL+Z.
    Typowa procedura odczytu klawisza czyta wartość z KBCODES, po czym zapisuje do niego wartość 255:
    10 K=PEEK(764): IF K=255 THEN 10
    20 POKE 764,255
    Gdybyśmy jednak chcieli rozpoznać wszystkie dostępne kombinacje klawiszy należałoby zachować ostatnio odczytaną wartość klawisza i porównywać świeżo czytaną zawartość KBCODES z tąże wartością np tak:
    10 L=-1: REM peek daje liczby [0..255]
    20 K=PEEK(764): IF K=L THEN 20
    30 L=K
    Nie da się jednak w ten sposób odczytać wciśnięcia tego samego klawisza raz po raz.
    Jest jednak na to metoda, ponieważ w całym zestawie możliwych kombinacji POKEY ma dziury. Brakuje np kombinacji SHIFT+CONTROL+[Z,X,C,V,B] i jeszcze kilku innych. Jakie kody one przyjmują? Zasada jest prosta - do kodu pojedynczego klawisza dodaje się 64 w przypadku dołączenia klawisza SHIFT i 128 w przypadku CONTROL. Jeśli więc normalny Z ma kod 23 ($17) to SHIFT+CONTROL+Z będzie mieć 128+64+23=215 ($D7) :)
    Po co to wszystko? Jeśli zamiast 255 założymy, że kod dla braku wciśniętego klawisza to właśnie zabroniona kombinacja SHIFT+CONTROL+Z, to będzie można rozpoznać również wciśnięcie SHIFT+CONTROL+A! Zmodyfikowana procedura może wyglądać tak:
    10 K=PEEK(764): IF K=215 THEN 10
    20 POKE 764,215
    Na koniec działania naszego programu tuż przed wyjściem do systemu operacyjnego warto do rejestru-cienia KBCODES wpisać wartość braku klawisza, której system się spodziewa, czyli 255.
    Zamiast sztuczki z zabronioną kombinacją można próbować testowania bitu wciśnięcia klawisza w rejestrze SKSTAT ($D20F) np. tak:
    10 S=PEEK(53775): SI=INT(S/8)*8: IF (S-SI)>=4 THEN 10
    20 K=PEEK(53769): REM KBCODE ($D209)
    Dokładnie tak samo można testować wciśnięcie klawisza SHIFT, który jest obsługiwany samodzielnie;
    10 S=PEEK(53775): SI=INT(S/16)*16: IF (S-SI)>=8 THEN 10
    CONTROL niestety takich możliwości nie daje :(
    Na koniec warto chyba wspomnieć jeszcze o jednej sprawie. Klawisze konsoli HELP, START, SELECT, OPTION I RESET mimo, że są umieszczone w jednym bloku, to nie są traktowane jednorodnie (analogicznie, jak SHIFT i CONTROL) - START, SELECT i OPTION bowiem są rozpoznawane przez GTIA w rejestrze CONSOL ($D01F)
    10 C=PEEK(53279)
    20 CI=INT(C/8)*8: ST=(C-CI)>=4
    30 CI=INT(C/4)*4: SE=(C-CI)>=2
    40 CI=INT(C/2)*2: OP=(C-CI)>=1
    natomiast wciśnięcie HELP'a jest testowane właśnie przez POKEY'a i powoduje pojawienie się w KBCODE wartości 17 ($11). Można sprawdzać co da wciśnięcie go z SHIFT i/lub CONTROL :D Konsekwencją takiej obsługi klawiatury jest również to, że klawisze START, SELECT i OPTION można wciskać równocześnie z dowolnymi kombinacjami klawiszy na klawiaturze. Możliwa jest więc kombinacja START+OPTION+SHIFT+CONTROL+N (kto pamięta w jakiej grze co ta kombinacja powodowała? ;)). Możliwe jest też testowanie wciśnięcia START+SHIFT (jaki "użytek" pana JBW się tak aktywowało?). Nie można jednak wciskać HELP'a równocześnie z klawiszami klawiatury.
    Można też wciśnięcie klawisza HELP testować odczytując rejestr cień HLPFLG (732 = $2DC):
    10 H=PEEK(732): IF H<>255 THEN 10
    20 POKE 732,255
    Rejestr ten zawiera wartość odczytaną z KBCODE a więc w kombinacji z SHIFT i/lub CONTROL.
    Osobiście jako kod braku wciśnięcia klawisza wykorzystuję kombinację SHIFT+CONTROL+HELP (209 = $D1), która nie jest sygnalizowana przez POKEY.

    mono @2008-12-10 21:49:24
    Poprawka dla HELPa - oczywiście:
    10 H=PEEK(732): IF H=255 THEN 10
    • 33:
       
      CommentAuthorKaz
    • CommentTime12 Dec 2008
     
    FAQ o programach w Basicu:

    ->link<-

    ->link<-

    ->link<-
    • 34:
       
      CommentAuthorYosh
    • CommentTime14 Dec 2008 zmieniony
     
    Bardzo mocno polecam maniakom oryginalnego Action (jej pisze PIERWSZY program a już się zakochałem)

    Najbardziej aktualna znana mi lista błędów w Action!:

    ->link<-

    np. Ostatnio wdepnąłem w błąd HEX ARRAY SIZES (nie można podawać rozmiaru tabeli hexem)
    • 35:
       
      CommentAuthorKaz
    • CommentTime22 Dec 2008
     
    LAREK o kompilacji:

    K> - czy zawsze trzeba na dysku trzymac RUNTIME?

    Tak. Ale za to nie musisz mieć Turbo Basica XL. Runtime jest trochę krótszy.

    K> - o ile mniej wiecej zwieksza sie program po kompilacji?

    Nigdy tego jakoś nie sprawdzałem, albo już nie pamiętam :).
    Plik z grą PARACHUTE zwiększył się o ok.600 bajtów po kompilacji. Nie wiem,
    czy to jest wartość stała, czy zależy od czegoś w programie źródłowym.
    Generalnie bardzo dużej różnicy to nie ma.

    K> Gra zajmuje obecnie 92 KB na dysku (program w postaci TXT, dane do gry
    oraz sam
    K> interpreter TB), a chce oszacowac czy sie zmiescimy na dyskietce SD po
    K> kompilacji czy nie bardzo.

    Trudno wyczuć. Jak już napisałem - po kompilacji nie musisz mieć pliku Turbo
    Basica XL. W to miejsce wchodzi RUNTIME. Jest sporo krótszy - 88 sektorów
    vs. 145 sektory dla TBXL (na dyskietce SD). Wychodzi gdzieś 5-6 KB mniej).

    K> LINKER.COM? Wlasnie takie cos by mnie interesowalo.

    Nigdy nie widziałem w działaniu programu LINKER.COM. Nie wiem, co to
    takiego? Może to programik służący tylko do łączeniu plików dosowych
    (odpowiednik publikowanego w TA APPEND.COM) - tak po samej nazwie wnioskuję.
    Taki program nie nadawałby się do łączenia biblioteki z programem. To musi
    być specjalny programik.
    Ja używałem zawsze prostego programu w Basicu - SCALAK.TXL (chyba też był
    publikowany w TA).
    Na dyskietce z załączniku jest ten program. Nigdy nie miałem z nim problemów
    i jakoś nie szukałem innego. Aby go uruchomić najpierw wczytujesz TBXL, a
    później RUN "D:SCALAK.TXL".

    Należy zwrócić uwagę na fakt, że wszystkie pliki z danymi nadal zostaną w
    formie plików zewnętrznych. Tego się nie da połączyć!
    No dobrze, w pewnych przypadkach da się, ale to muszą być pliki z danymi z
    nagłówkiem dosowym, które ładują się precyzyjnie w określone miejsce w
    pamięci. Takie wcześniej spreparowane pliki da się połączyć z gotowym
    programem. Jednak to nie jest takie proste i bardzo mocno zależy od tego, co
    to za dane i jak je wcześniej przygotowano.
    • 36:
       
      CommentAuthorsikor
    • CommentTime23 Dec 2008
     
    Oj, Kaz, Kaz... Masz na atarionline.pl moją "dyskietkę" z Turbo Basiciem XL. Jest tam też linker, który łączy skompilowany program z biblioteką (runtime2 - też jest na dyskietce). Oczywiście - co do damnych - trzeba je dalej trzymać na dyskietce lub - o ile to możliwe - dołączyć na stałe do programu.
    Przykład zastosowania masz w Swojej i Scalaka tekstówce, którą Ci podesłałem skompilowaną.
    • 37:
       
      CommentAuthorKaz
    • CommentTime23 Dec 2008
     
    Sikor - ale co Cie bulwersuje, bo nie rozumiem? Dyskietek z RUNTIME mam chyba z pietnascie. To automatycznie powoduje, ze kazdy wie, jak tego uzywac i z czym to sie je?
    • 38:
       
      CommentAuthorsikor
    • CommentTime23 Dec 2008
     
    @Kaz: jak zabrzmiało to tak, jakbym się zbulwersował - przepraszam, nie to było moim zamierzeniem. Poprostu odniosłem się do pytania: "K> LINKER.COM? Wlasnie takie cos by mnie interesowalo." z odpowiedzi powyżej. Nie, nie powoduje, że każdy wie. Więc teraz wytłumaczę:
    Program "LINKER" służy do połączenia programu skompilowanego (tutaj w Turbo Basicu XL, ale zasada jest ogólna)z bibliotekami dla danego języka. W stacji dysków numer jeden musi się znajdować dyskietka z linkerem i z plikiem RUNTIME2.EXE, natomiast w dowolnej innej - nasz skompilowany plik w Turbo Basicu. Po wczytaniu programu - podajemy pełną ścieżkę do skompilowanego pliku (np. D:PLIK>CTX) oraz pełną ścieżkę dla pliku wynikowego (np. D:PLIK.COM). Po chwili - mamy gotowy plik z bibliotekami dołączonymi do programu.
    • 39:
       
      CommentAuthorKaz
    • CommentTime23 Mar 2012
     
    Powyzej mozna powiedziec, jest taki watek poradnikowy na temat procedur. Jak ktos ma potrzebe albo wiedze, to moze dopisywac sie tutaj.