Ostatnie zdanie tylko a propos ostatnich komentarzy wyżej, że "przesiadając się z Atari XL/XE na PC-ta w latach 90-tych", nigdy w życiu nie musiałem (oprócz na zaliczenie przedmiotu i zapomnieć) korzystać tych dziwnych znaczków chaosów śmieciowych typu C lub UNIX, dzięki Bogu, czyli Mnie.

Jedyna ciekawostka, jaką poznałem przenosząc się z Atari BASIC na Turbo Pascal 5.5., to znak przypisania

:=

zamiast zwykłego

=

Więcej dziwności nie pamiętam, hmm...

Do dziś czuję się programując, jakbym był nadal na Atari XL/XE, tylko trochę więcej możliwości i osiągi, szersze zakresy zabawy, możliwe, że aż w nieskończone wszechświaty, tak bym to ujął - jednak czy Atari XL/XE, czy PC, nie widzę za bardzo różnicy w komforcie pracy, ani różnicy narzędzi, systemów, etc. - nic, zero, oczywiste. To te same komputery i narzędzia w sumie, chociaż zubożenie układów graficznych na PC spowodowało kataklizm typu ZX Spectrum, Windows programowe, zamiast sprzętowe, etc. - same zagłady PC-tów po drodze, oczywiste... wszystko przez C, UNIX i ZX Spectrum, oczywiste...

Ale już niedługo będzie powrót do Atari, czyli do dobrych komputerów, a nie śmieci, oczywiste...

@Mq:

Zgoda a propos programowania, ale ze zwróceniem uwagi, że sprzęt sprzętowi nierówny, więc programując w obojętne czym (kto co lubi, to sobie używa), nadal wykonuje program na sprzęcie. I w tym miejscu dopiero zaczyna być widać różnice w efektach, oczywiste.

Więcej nie zaśmiecam. Potwierdzam, prawda, true. amen.

Część trzecia, czyli dwa słowa o grafice i pliku DOSowym.
Miło mi, że na forum pojawiaja się komentarze i poprawki mojego kodu. Zgodnie z ustaleniami dziś postaram się pokazać jak stworzyć plik uruchamiany spod DOSu (lub dowolnego loadera). Ale ponieważ ma to być gra, w dodatku z grafiką - zacznijmy od niej.
Całą gra ma być w trybie graficznym (bo mi tak wygodnie z pewnych względów, ma zawierać grafikę, itp., itd.). Niestety, nie doczekałem się pomocy grafika, więc muszę sam coś zaimprowizować. Całość robimy w trybie jednokolorowym (dla niektórych: dwukolorowy, barwa i odcień). Tak działa nasze Atari (o ile nie korzystamy z artefaktów, ale te to na CRT i głównie w NTSC). Lubię, jak gra ma jakiś tytuł. Postanowiłęm, że do dzisiejszej części dorobię taką namiastkę. Ponieważ w tym trybie standardowo mamy rozdzielczość 320x192 punkty, proporcje piksela 1:1 (co jest bardzo ważne), bardzo wygodnym narzędziem są wszelkiego rodzaju edytory graficzne na PC (oczywiście można grafikę zrobić na Atari, Macu czy nawet Atari ST czy Amidze), w moim przypadku z możliwością zapisu/eksportu w formacie GIF (bo z takich narzędzi korzystam na Atari i w tym tutorialu). Obsługi programów nie będę tutj uczył - napiszę tylko, że w naszym przypadku korzystam z darmowego GIMPa.
Dobrze, stworzyłem sobie grafikę w odpowiednim formacie i rozdzielczości - ponieważ mam zamiar tytuł wyświetlać także podczas gry, założyłem, aby grafika nie była zbyt duża, powiedzmy 320x40 pikseli, oczywiście w jednym kolorze. Grę nazwałem oryginalnie "Tutorialowa gra paragrafowa" i zmodziłem z tego grafikę o zadanych rozmiarach, po czym przekonwertowałem ją na grafikę jednobitową i zapisałem w formacie GIF. Całość umieściłem na dyskietce roboczej (stworzyłem na potrzeby tutorialu kolejną dyskietkę - grafika.atr - osobiście preferuję większe obrazy, ale poradzimy sobie). Zakładając, że ktoś korzysta z pojedynczej stacji dyskietek postaram się przeprowadzić teraz drogich czytelników przez proces konwersji, przy czym zaczniemy od liczenia: 320px w szerokości daje nam w tym trybie graficznym 40 bajtów, mamy 40 linii, czyli 40x40=1600 bajtów - tyle docelowo zajmie nasza grafika.
Zabieramy się za konwersję. Ponieważ tu grafika zajmuje całą szerokość ekranu do testów napiszemy sobie prosty programik w TBXL do wycięcia bloku, ale najpierw trzeba wszystko przekonwertować. Wczytujemy dyskietkę roboczy_tools.atr i program do konwersji (jv.com). Po pojawieniu menu programu za pomocą klawisza "M" wybieramy tryb Gr.8 BW - jest to nasz docelowy tryb graficzny (nawiasem mówiąc - proponuję się w wolnej chwili pobawić tym programem). Podmieniamy w stacji naszą dyskietkę na obraz grafika.atr. Teraz możemy ją wylistować (D), można podać maskę lub wcisnąć RETURN (bo całość mamy w stacji D:). Upewniamy się, że jest tam nasz GIF - wybieramy "L", następnie *.gif (mamy ten jeden póki co, więc po co się męczyć z nazwą?), możemy zmienić sposób dzielenia szerokości i wysokości (tu bez zmian) i wczytujemy (Return). Po wczytaniu widzimy nasz obraz, naciskamy klawisz START i całość zapisujemy - dla grafik w 8-mym trybie graficznym ja zwyczajowo daję rozszerzenie .8, ale może być dowolne, więc naciskam "S" i wpisuję "TYTUL.8" (wpisujcie bez apostrofów). Zapisał nam się plik w 8-mym trybie graficznym. Teraz podmieniamy dyskietkę na taką z dosem, "Z" i jesteśmy w DOSie.
Proponuję wczytać TBXL. Podmieniamy dyskietkę na ą z grafiką i teraz proponuję Wam chwilę przerwy od gry. Napiszemy sobie krótki programik do naszej grafiki. Przepiszmy uważnie ten kod:

10 OPEN #1,4,0,"D:TYTUL.8":BGET #1,$60
00,7680:CLOSE
11 GRAPHICS 24:POKE 710,0
12 MOVE $6000,DPEEK(88),1600
13 GET KEY
14 OPEN #1,8,0,"D:TYTUL.DAT":BPUT #1,$
6000,1600:CLOSE

Proponuję zapisać to sobie, na przykład jako "TESTGR.TB". Uruchamiamu (RUN) - na ekranie po chwili ukaże się nasz tytuł. Robimy DIR i co widzimy - plik TYTUL.DAT, który jest sporo krótszy od TYTUL.8 - ma dokłądnie 1600 bajtów.
Co dokłądnie robi nasz mini program? Otwieramy kanał pierwszy do odczytu, wczytujemy pod adres $6000 7680 bajtów, uruchamiamy ósmy tryb graficzny bez okna tekstowego (8+16=24), przepisujemy pierwsze 1600 bajtów na ekran (linia 12), po naciśnięciu klawisza otwieramy pierwszy kanał do zapisu i zapisujemy dane na dyskietkę. Pamiętamy o każdorazowym zamykaniuu otwartych kanałów - dobra praktyka!
Teraz tak - zaraz kilka osób się przyczepi, że przecież mogłem otworzyć dwa kamnały od razu (jeden odczyt, drugi zapis) i polecieć całość za jednym zamachem (pierwsze 1600 bajtów pliku), mogłem wczytać od razu na ekran (zamiast $6000 od razu dpeek(88)) - itp. Nie zrobiłęm tego, aby pokazać mechanizm działania i pewien sposób trzymania danych w pamięci komputera.
Czas określić miejsce w pamięci, gdzie będziemy trzymać nasz tytuł. Proponuję tuż pod fontami, pamiętamy, że one siedzą od adresu $9C00, wpiszmy w TBXL:

?HEX$($9C00-1600)

Wyskoczy nam wynik: 95C0, czyli naszym docelowym adresem będzie $95C0. Kto chce, może skorzystać z metody Open... itd, ale jak widzicie - pliki nam się mnożą. Proponuję wczytać teraz Super Packera, i po kolei:
1. L (czyli load) i podajemy DANE.DAT (nasze fonty, przypominam)
2. F (wczytanie danych niebinarnych) i podajemy TYTUL.DAT, podajemy adres 95C0, sprawdzamy, czy jest przed fontami (jest - 9BFF)
3. S (zapisujemy) i podajemy DANE.DAT - nadpisujemy nasz plik z danymi
4. Q - wychodzimy do DOSu
Uwaga! Pamiętamy, aby w stacji były odpowiednie dyskietki! Wynik zapisujemy na naszej roboczej dyskietce z programem w TBXL!
Teraz wczytujemy TBXL. dajemy komendę BLOAD"D:DANE.DAT" i możemy sprawdzić, czy dane siedzą w pamięci:

GR.8:MOVE$95C0,DPEEK(88),1600:POKE756,$9c

Powinniśmy mieć tytuł na górze ekranu oraz polskie literki z control. Zakłądam, że wszystko jest ok. Pamiętamy, aby uzupełnić nasz plik z adresami o odpowiedni wpis - $95c0-$9fff grafika tytułowa - aby potem ich nie zadeptać. Wczytujemy nasz plik z grą (LOAD"D:GRA0.TB"). Zmodyfikujemy sobie póki co tylko procedurę INTRO, proszę o własnoręczne przepisanie zmian:

99 ------------------------------
100 PROC INTRO
101   GRAPHICS 24:POKE 710,0:POKE 709,
15:POKE 756,$9C
102   MOVE $95C0,DPEEK(88),1600
142   COLOR %1:TEXT 10,100,"Tu będzie i
ntro"
150   IF PEEK(53279)<>6 THEN 150
190 ENDPROC
199 ------------------------------

Pomijając fakt, że będzie to procedura mocno zmieniana w kolejnym odcinku - wykonajmy nasze zadanie, czyli pokażę jak wykonać plik wczytywany z DOSu lub loadera. Zapiszmy całość jako GRA1.TB (ja zawsze zmieniam numer jak coś robię - w razie wpadki mogę wrócić do poprzedniego pliku. Można też tworzyć sobie tylko dwa pliki i je nadpisywać naprzemiennie, nie polecam natomiast zapisywać zmian zawsze na tym samym pliku, bo mogą pojawić się problemy i czasem ciężko będzie do nich wrócić).
Jeszcze sprawdzam, zy wszystko jest ok - RUN.
Jeśli wszysko w porządku - wczytujemy nasz kompilator (DOS i TBC.COM). Wciskamy 1 (numer stacji dyskietek z naszym źródłem), następnie klawiszamy kursora wybieramy nasz plik źródłowy (GRA1.TB) i naciskamy return. Jeśli wszystko będzie w porządku (no errors) - program poprosi o podanie nazwy dla skompilowanego programu (podajemy bez rozszerzenia) - GRA1.CTB, potem naciskamy N (nie chcemy kolejnej kopii), control-D (wyjście do DOS), Y (potwierdzenie) i sprawdzamy nasz katalog (DIR). Niestety, jak tam spojrzymy - mamy tylko 63 wolne sektory (ach, ta pojedyncza gęstość), a sam runtime ma... 88 (jak ktoś stworzył sobie większego ATR-a to nie będzie miał problemu). Na potrzeby tutoriala tworzę nowy ATR, tam przegrywam wyłącznie plik linker, runtime2.exe oraz nasz skompilowany program - ja go nazwałem kompilat.atr (do ściągnięcia).
Po wgraniu DOSa wkładamy do stacji nasz dysk i wczytujemy linker (LINKER.COM) -  i tu uwaga, oryginalny linker wymaga, aby plik RUNTIME2.EXE był w stacji nr 1. O.k., podajemy nazwę naszego programu (pełna śzieżka) - D:GRA1.CTB, następnie nazwę pliku wynikowego - D:GRA1.CO (Uwaga! Z premedytacją dalem rozszerzenie CO - potrzebujemy dograć nasze dane! Gdy nic nie dogrywamy - mamy już gotowy plik!). Wciskamy Return i KONIECZNIE klawisz Esc po zapisaniu! (dopiero on zamyka plik). Wkłądamy dyskietkę z DOSem i mossadem, wciskamy D (wyjście do DOS), wczytujemy mossada i po kolei:
1. R D:GRA1.CO <return> - wczytanie "naszej gry"
2. R D:DANE.DAT <return> - wzytanie brakujących danych
3. W D:GRA1.COM <return> - zapis całej gry
4. Q T - wyjśie do DOSu (musi być w stacji)
Teraz już możemy wczytać naszą grę spod DOSu! Sprawdźcie sami...
Oczywiście, zamiast Mossada można użyć nawet DOSa, ale dla mnie jest to wygodne narzędzie, co więcej - ma spory bufor pamięci. W następnym odcinku spróbujemy nieco doszlifować nasz program binarny i zająć się ekranem inta. Jak zwykle liczę na odzew ze strony forumowiczów i czekam na uwagi.

Również dzięki za kolejny odcinek.

Sikor, czy na potrzeby tutorialu na obecnym etapie, nie lepiej było by jednak zmienić trochę koncepcję ogólną i zrobić na tyle dużego atr-a, żeby wszystko dało się robić na jednej "dyskietce"?
Myślę, że wówczas opisy były by bardziej przejrzyste, a same operacje dyskowe nie zajmowały by tak dużo miejsca w opisach, dzięki czemu i Tobie było by to łatwiej pisać i czytelnikom było by łatwiej czytać, rozumieć i testować. Tak sobie myślę, że bardziej gładko by się przechodziło przez ten tutorial, gdyby założyć, że robimy to na potrzeby naszej nauki w emulatorze: przecież każdy czyta tutorial na pececie, ściąga na nim te pliki, więc najszybciej też jest je przetestować na emulatorze. Następnie kto ma ambicję przenieść to na prawdziwe Atari, to sobie poradzi już we własnym zakresie układając dyskietki jak mu wygodniej. Ja osobiście wolał bym mieć wszystko w jednym atr i nie zastanawiać się co jest w którym i którą dyskietkę w jakiej kolejności przekładać.

Sam nie lubię emulatorów, ale tutorial łatwiej się w tym wypadku tak testuje. Z kolei ja np. na prawdziwym Atari używam SIO2SD, więc też jest mi wszystko jedno jaki duży jest atr - im większy tym lepiej.

To tylko propozycja, niech się może jeszcze raz wypowiedzą osoby, które wcześniej optowały za takimi a nie innymi gęstościami.

ok - do następnej części zrobię dużego ATR-a, a każdy w razie potrzeby sobie wypakuje i przegra na mniejsze atr-y nawet pod emulatorem. Czekam na wrażenia i pytania do tej części ;)

Hej!
Z przyczyn zdrowotno-czasowych kolejny odcinek pewnie w przyszłym tygodniu. Co do adresów - póki co starczy Ci "Atari Basic" Miguta.
Teraz tak - Bload powinien Ci zadziałać po kompilacji i zrobieniu pliku, ale, jeśli łączysz plik w całość (jak jest w tutorialu) - to i tak dołączasz ten plik, więc jest to zbędna linia. Oczywiście te dane musisz mieć na dyskietce, a program po skompilowaniu jeszcze zlinkowany.
Jak dam radę (będę poza domem) - to dziś może wrzucę większego ATR-a, aby wszystko było w jednym miejscu - według sugestii.
Co do adresów DEC/HEX - łatwiej mi lokalizować wgrywając, ale... Wychodzą przyzwyczajenia z Atari Basica i niestety/stety część adresów pamiętam w DEC po prostu i łatwiej mi to pisać. Nic poza tym - ale zawsze można sobie przerobić, szczególnie ucząc się. Przepraszam za zamieszanie z tym, jeśli taka wola ludu - będę przerabiał na HEXy, aby wszystko było ok. Tak będzie lepiej?
Aha, i dzięki za odzew, bo już myślałem, że nikt z tego nie korzysta.

Sikor, rób tak jak ci wygodniej, w sumie to i lepiej dla mnie jak muszę poszukać, więcej zostaje w głowie.

ps. właśnie nie miałem DANE.DAT na dyskietce dlatego nie działało :)

Sikor, tych trzech-czterech czytelników zawsze masz, a może więcej, którzy się nie przyznają:-) Ja chętnie czytam, nie testuję bo nie mam czasu, ale na razie wszystko to co podajesz odpalam sobie wirtualnie w głowie i wszystko mi działa:-) Trochę żartobliwie to piszę, ale na serio, analizuję sobie kod, przypominam sobie z rozrzewnieniem Basic z dzieciństwa, i chętnie odnoszę to do TBXL, którego bardzo żałuję, że nie znałem w tamtych latach, bo na pewno bym używał. W Basicu za dzieciaka robiłem bardzo dużo, aż okazało się, że gry takiej jak Robbo nie da się zrobić, wtedy próbowałem assemblera, ale za mały byłem, żeby skumać o co tam chodzi, nie miałem materiałów, nie miałem w otoczeniu żadnego guru, który wiedział by co to w ogóle jest assembler, no i poległem z programowaniem aż do czasów gdy robiłem później gry w assemblerze na pecetach. Dziś z perspektywy czasu patrząc, gdybym miał wtedy TBXL, to dziś pewnie był bym takim drugim Larkiem:-) hehehe:-) - bo jego wspomnienia jak czytam, to jakbym czytał swoje.
Tak że Sikor, pisz dalej, pisz, a nawet jeśli dziś nie będzie bardzo wielu czytelników, to myślę, że Twój tutorial na koniec można spokojnie zebrać w całość i zrobić z tego książkę choćby w pdf, a na pewno nie raz ludzie do tego jeszcze będą sięgać.
Edit: aha, nikomu się nie pali, więc rób ze spokojem wtedy kiedy masz czas i kiedy Ci się chce - tylko nie przerywaj i dokończ robotę:-)

Ło pieronie... jestem pierwszy przy tablicy... postaram się coś wymodzić w tzw. międzyczasie w zakrzywionej czasoprzestrzeni... :-)

Moje wypociny, słabe, ale może się coś nada. Niestety grafikiem nigdy nie byłem i nie będę :)

ps. grafiki ściągnięte z google i przerobione, więc co do praw autorskich to nie mam pojęcia.

Faktycznie coś nie wyszło :)

Będzie chwila przerwy, bo zmarł mi brat i nie jestem w nastroju. Ale grafikę szykujcie.