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.
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.
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."
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."
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)...".
"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."
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."
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"
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
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.
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.
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.
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.
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… :/
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.
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.
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."
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
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 :).
>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.
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.
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.
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.
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.
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
@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
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.
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ą.
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?
@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.
