Zagłosowałem na tak z grafikami, ale dopowiem, że interesuje mnie to jako lektura do poczytania i być może wykorzystania w przyszłości w ten sposób nabytej wiedzy - jednak nie będę raczej brał w tym udziału, bo nie mam na to czasu.
Tak czy owak uważam, że idea jest dobra, bo to może zachęcić nowe osoby to nauki programowania. Temat wydaje się być łatwy do oprogramowania z takim tutorialem nawet dla osób zupełnie zielonych w programowaniu. Osoby bardziej zaawansowane może złapią bakcyla i zaczną potem robić coś bardziej skomplikowanego mając tak szerokie podstawy.
Koncepcja super i daje szansę na kopniaka w rozwój naszych ulubionych maszynek:-)

Bardzo proszę z grafiką :)

Format rozszerzony MyDOS-a (MD) różni się od ED Atari DOS, dlatego proponowałbym go omijać. Albo SD albo DD.

A czy w zamiarze jest przekroczenie 90kB? Bo jeżeli nie, to po co DD?

Ja proponuję ED (130k na stronę dyskietki), DD na standardowej 1050 raczej nie ma szans zadziałać. A jak jest z nim problem to lepiej SD, kto będzie chciał ten sobie inny format, a przynajmniej zadziała u wszystkich :)

Zaczynamy.
Część pierwsza - przygotowujemy narzędzia.
Zanim napiszemy scenariusz i rozpoczniemy pracę nad programem - napiszę, jakich narzędzi będziemy używać do pisania naszej gry. Za namową kolegów z Zielonej Góry spreparowałem dwie dyskietki (opis za chwilę, dołączone do postu) w gęstości pojedynczej. Od razu napiszę, że osobiście używam większych pojemności i widzę, że na sam koniec trzeba będzie przygotować jeszcze jedną - ze względu na to, że dążymy do wykonania gry plikowej, a tu się nie zmieszczę z linkowaniem skompilowanego produktu. Osobiście obrazy dyskietek tworzę pod makeATR, dość archaicznym dziś narzędziem, ale które nigdy mnie nie zawiodło. Zasadniczo sam obraz dyskietki (dla osób działających pod emulatorem lub pod późniejsze wykonanie) można wykonać dowolnym programem, który na to pozwala, ale mam jedną uwagę - z autopsji (Grawitacja, inne party) wiem, że obraz pod MyDOSa tworzony pod pluginem do Total Commandera potrafi taką wirtualną dyskietkę rozwalić (nie wiem jak pod inne DOSy) - przerabiałem to swego czasu na kompie Mikera, jak dołączaliśmy rzeczy do obrazu, które potem starałem się odtworzyć na moim Atari.
Z ankiety wynika, że będziemy się starali robić grę w hiresie (najwyższej rozdzielczości) z grafikami o rozdzielczości 80x80px. Jest to tryb jednokolorowy (instrukcja graphics 8+16, śmiało można napisać graphics 24 - ale opisy kodu będę robił w części temu poświęconej). Wybrałem język Turbo Basic XL, bo to w nim tworzę swoje programy. W programie nie będziemy używać żadnych procedur języka maszynowego - oprócz wywołania muzyki w Chaos Music Composerze (mam nadzieję, że jakąś muzykę dostarczą czytelnicy, jak nie - weźmiemy jakiegoś gotowca). Z uwagi na brak grafika (chyba, że jakiś się zgłosi) - konwersji i poprawek kodu będę dokonywał na PC pod programem GIMP, ale może być to dowolny program pozwalający na zapis jednokolorowych bitmap (ja będę zapisywał w formacie *.gif i dalej działał na Atari). W tym trybie proporcja piksela jest 1:1, więc taki obraz idealnie się konwertuje na Atari.
Do pracy przygotowałem dwie dyskietki, każda zawiera MyDOSa i dodatkowe programy/dane.
1. roboczy_tbxl.atr o zawartości:
  DOS     SYS 0035     - MyDOS
  DUP     SYS 0054    - powłoka MyDOSa (menu)
  LINKER  COM 0111    - linker do skompilowanych programów
  TB      COM 0145    - Turbo Basic XL
  TBC     COM 0080    - Turbo Basic XL Compiler, czyli kompilator
  RUNTIME2EXE 0088    - dołączany plik uruchomieniowy do naszych zlinkowanych programów
  POLSKIE FNT 0009    - polskie fonty z PANTHER-a, jako przykład*
0186 FREE SECTORS     - ilość wolnego miejsca na dyskietce
* UWAGA! znak "," zamieniony ze znakiem ";" - dlaczego opiszę w kolejnych częściach tutorialu
2. roboczy_tools.atr o zawartości:
  DOS     SYS 0035    - MyDOS
  DUP     SYS 0054    - menu MyDOSa
  SP      COM 0060    - Super Packer
  MOSSAD3 COM 0108    - Mossad
  JV      COM 0075    - jview
  BLOCKCUTXEX 0170    - GR_Block cutter
0206 FREE SECTORS
Czemu takie a nie inne narzędzia? No cóż, takich używam na Atari i mi wystarczają. Brak CMC-a (Chaos Music Composera) - tten dodamy potem, a właściwie tylko muzyczkę i player z niego, po wybraniu odpowiedniej wersji. Opiszę najpierw narzędzia (dyskietka 2), gdyż niekoniecznie używam ich wszystkich zgodnie z oczekiwaniami, a mianowicie:
- Super Packer - jest przeze mnie używany głównie do nadawania... Nagłóków binarnych w danych, które używam. Ułatwia mi to życie przy pisaniu programów plikowych, a w jaki sposób - opiszę w trakcie tworzenia dalszych części artykułu, zdradzając jedynie, że wykorzystuję tu jedną ze specyficznych cech TBXL (jak od teraz będę w skrócie nazywał Turbo Basic XL).
- Mossad - służy mi do linkowania całości, ma znacznie większy bufor od Super Packera, więc pozwala w łatwy sposób tworzyć większe pliki (równie dobrze można linkować przy pomocy dosa, ale po co utrudniać sobie życie?).
- JView - posłuży mi do zamiany GIF-ów na format graphics 24 (UWAGA! Zawsze pełen ekran!).
- GR_Block cutter - takie moje narzędzie do wycinania bloków grafiki, może nie jest intuicyjne, ale mi wystarcza, a wydaje mi się, że Wam też się przyda
Pierwsza dyskietka oczywiście służy do programowania, mamy tam:
- nasz edytor TBXL.
- kompilator do niego.
- linker do kompilowanych programów wraz z poprawionym (o ile pamiętam przez Simiusa) runtime-m, czyli plikiem uruchomieniowym z bibliotekami, co nam pozwala uruchomić skompilowane programy bezpośrednio pod DOSem (lub jako pliki samouruchamialne typu XEX z urządzeń typu SIO2_coś_tam).
- przykładowy font do zastosowania w grze.
Teraz poproszę Was o zabootowanie drugiej dyskietki, po wgraniu MyDOSa o wybranie klawisza 1 (directory stacji nr 1), pokaże się spis zawartości dyskietki, a następnie uruchomienie po kolei wszystkich plików (póki co sprawdzamy, czy Wam poprawnie działają), czyli: opcja "L" i wpisujemy nazwę programu (wystarczą dwa pierwsze znaki i dwie gwiazdki, na przykłąd do Mossada wystarczy wpisać: MO**). Jak się program uruchomi - wyjście do DOSu i kolejny (lub reset komputera i kolejny). Jak wszystko się uda - proszę o zabootowanie dyskietki nr 1 i wgranie TBXL ("L" a następnie TB.COM lub TB**), jeśli wszystko pójdzie prawidłowo - pokaże nam się znajomy nappis READY. Można spróbować wgrać dalsz eprogramy, ale ja Wam zaproponuję pewien test kompilatora, napiszmy typowy program "hello world":

1 GRAPHICS 0:POKE 710,0:POKE 709,15
2 ? "Witaj skompilowany programie!"
3 GET KEY

Prawda, że ciężki kod? Proponuję zapisać go pod nazwą TEST.TB (ja standardowo zapisuję programy w TBXL z rozszerzeniem .TB, ale nazwa jest zwyczajowa i dowolna właściwie. Zapisujemy całość (SAVE"D:TEST.TB") i spróbujmy uruchomić nasz program (RUN). Działa? Działa, tylko nas oszukuje (nie jest skompilowany, ale to zaraz zrobimy). W linii nr 3 wykorzystałem specyficzną instrukcję TBXL - GET zmienna, która zatrzymuje nasz program i czeka na naciśnięcie dowolnego klawisza, po jego naciśnięciu zaś zapisuje wartość klawisza do zmiennej (w naszym przypadku KEY) i kontynuuje działanie programu. Będziemy z tej opcji często korzystać w naszym programie, a dałem tutaj ten przykład, aby zaraz po uruchomieniu programu DOSowego nie przeszedł do DOSu lub RUNTIME-u (jak by było w naszym przypadku - nie ma instrukcji kończącej działanie programu, czyli END, zresztą sam END też czasem wraca do RUNTIME-u).
Dobrze, wpiszmy teraz polecenie DOS i z MyDOSa wgrajmy kompilator ("L" a następnie "TBC**")  - od tej chwili już nie będę pisał jak wgrywać programy spod DOSa, bo to chyba każdy potrafi, tu opisałem to tylko ze względu na specyfike MyDOSa, ale być może będziecie używać innych DOSów.
Po wgraniu kompilatora - naciskamy 1 (o ile dyskietka z programem w napędzie nr 1) i klawiszami kursora wybieramy nasz program. O ile wszystko poszło bez błędów - pojawia się prośba o podanie nazwy pliku, przy czym program podpowiada nam rozszeżenie *.CTB - pozostańmy przy nim, wpisujemy słowo "TEST" i wciskamy Return, następnie "N" (nie chcemy kolejnej kopii) i Control-D i Y(wychodzimy do DOS-a). I teraz clue dzisiejszego wieczoru: wgrywamy nasz linker, podajemy pełną ścieżkę przy pliku źródłowym (D:TEST.CTB) i docelowym (D:TEST.COM). Jeśli wszystko przebiegło prawidłowo (All done) - naciskamy klawisz Esc (koniecznie!) i wychodzimy do DOSu (D). Mamy nasz pierwszy program DOSowy z TBXL - sprawdźmy listując katalog. Niestety od razu rzuca się w oczy objętość RUNTIMEu, ale to jest rzecz drugorzędna teraz. Uruchamiamy nasz program spod DOSu i cieszymy się pierwszą produkcją.
Na tym kończymy pierwszą, dość długą część tutorialu.  Obrazy dyskietek dołączone do postu.
Napiszcie proszę, czy taka forma Wam odpowiada - dziś tylko przetestowaliśmy narzędzia. Od kolejnej części zajmiemy się szkieletem programu, a następnie wypełnimy go treścią.

Spoko artykuł. Mimo, że czasy programowania w B/TBXL mam już za sobą to przypomnienie sobie takiej elementarnej wiedzy jest przyjemnością. Czekam na część kolejną!

Sikor super!

Dyskietki ściągnięte, niestety sprawdzę dopiero w niedziele i dam znać :) i z niecierpliwością czekam na kolejne części.

... działają :-)

Jeszcze chwilkę musicie poczekać ;) Nie chcę tego robić po łebkach - ale jak pisałem wcześniej - będę się starał robić przynajmniej jedną część tygodniowo. Dzięki za odzew tak wogle - miło, że ktoś czyta moje wypociny ;)

Dziś króciutka część druga - zróbmy sobie szkielet programu.
Skoro powiedziało się A, trzeba powiedzieć B. Póki co tylko cztery osoby sprawdziły dyskietki, ale dla tych czterech już warto. Zastanowimy się dzisiaj, jak powinien wyglądać sam szkielet programu, aby spełniał wymogi gry.Przewrotnie dziś nie dołącze działającej dyskietki, ale napiszę co i jak robimy (sprytni przekleją kod w emulatorze, ale polecam samodzielne pisanie, aby coś zostało).
Dobre zasady programowania na Atari mówią, że należy obniżyć tak zwany RAMTOP pamięci, czyli maksymalne miejsce, gdzie może znaleźć się program (komórka pamięci 106). Muszę się Wam przyznać, że... Ja tego nie robię ;) Póki co nie zawiodłem się na mojej metodzie, więc będę ją promował - ale jakby ktoś chciał skorzystać z niej, nic nie stoi na przeszkodzie. Trzeba tylko pamiętać - że  po obniżeniu RAMTOPu zmienia nam się diametralnie adres ekranu, lądując odpowiednio niżej. A dobre umiejscowienie danych w programie to połowa sukcesu. Ja po prostu umieszczam dane w odpowiednich adresach - przy tym posługuję się pewną specyfiką TBXL, a mianowicie - podaję adresy danych w kodzie szesnastkowym (po prostu liczbę w kodzie szesnastkowym traktujemy prefixem, czyli przedrostkiem, w formie znaku "$"). Dzięki temu łatwiej jest mi korzystać z dobrodziejstw większości programów użytkowych na Atari. Dlaczego - przekonacie się sami w dalszych częściach tutoriala.
Z autopsji i wielu prób wiem (nie zdarzyło mi się wywalić programu), że bezpiecznym maksymalnym adresem, do jakiego należy wrzucać dane - to $A035. Od lat właściwie wrzucam fonty pod adres $9C00, po dodaniu wartości 1024 bajtów łatwo się zorientować, że są to tak zwane cztery strony pamięci - font kończy się pod adresem $9fff. Tu jedna uwaga - fonty zawsze należy wrzucać na granicy strony (256 bajtów), aby łatwiej go potem wyświetlić bez kombinowania - czyli zawsze zachowujmy schemat $xx00, gdzie xx jest numerem strony. Łatwo to potem wykorzystamy, co zaraz pokażę. Proszę o wczytanie TBXL.
Uważny czytelnik powie: "zaraz, zaraz, a te kilka pozostałych bajtów między $9fff a $A035?". Czasem tam wciskam drobne dane, czasem pozostaje nieruszane...
Dobrze, przejdźmy do konkretów. Ustalamy, że nasze fonty będą siedziały pod adresem $9c00 - moje przyzwyczajenie. Jak je wczytać pod TBXL? Pokażę trzy metody, wraz z krótkim komentarzem do nich. Za każdym razem korzystamy z krótkiego kodu. Załóżmy, że nasze fonty nazywają się "POLSKIE.FNT" i są w stacji identyfikującej się jako "D:". Możemy je wczytać następująco:
1. Metoda podstawowa, według mnie najgorsza, za każdym razem przed wczytaniem programu lub po nim wpisujemy kod:

O.#1,4,0,"D:POLSKIE.FNT":BGET#1,$9C00,1024:CL.

Pokrótce opiszę, co się dzieje:
- otwieram kanał nr 1 do odczytu i ustawiam na plik z fontem
- używam instrukcji TBXL BGET, która pobiera odpowiednią ilość bajtów pod wskazany adres. Za broszurą Blukiego "Turbo Basic XL 1.5 Nowe Polecenia z przykładami" podaje składnię (Uwaga! Jeśli będę podawał skłądnię jakiegoś polecenia - będę się podpierał tą pozycją, nie dlatego, że nie znam zastosowania, tylko dlatego, że jestem leniwy i mogę coś przekleić, a tu jest po polsku):

- na koniec zamykam otwarty kanał (dobra praktyka)
Według mnie jest to najgorsza metoda, wymaga każdorazowego wpisywania po każdym uruchomieniu TBXL.
2. Nieco "poprawiona" poprzednia metoda. Zamykamy wszystko w procedurze - ponieważ tam możemy jednorazowo wczytywać różne dane, nazwijmy ją po prostu WCZYTYWANIE. Procedury zaczynają się od słowa PROC i kończą słowem ENDPROC, dodatkowo każda ma swoją unikalną nazwę (nie mogącą być słowem kluczowym TBXL) i można ją wywołać bezpośrednio z programu lub edytora. Proszę o przepisanie kodu:

1000 PROC WCZYTYWANIE
1001 O.#1,4,0,"D:POLSKIE.FNT":BGET#1,$
9C00,1024:CL.
1002 ENDPROC

Tak zapisaną procedurę należy jednokrotnie wywołać poprzez polecenie EXEC nazwa_procedury, bądź bezpośrednio z edytora, bądź z programu. Proponuję tą drugą metodę, dopiszmy linijkę (na początku programu):

1 EXEC WCZYTYWANIE

Teraz uruchamiamy program (RUN) i co? Otrzymujemy błąd! (takie było moje zamierzenie). Przypominam, że każdy program BASICowy (w tym program w TBXL) działa sekwencyjnie, linia po linii - o ile nie sterujemy przebiegiem programu - i kończy się kluczowym słowem end. Dopiszmy sobie linię kodu:

10 end

Uruchamiamy i nie mamy błędu. Ale nic się nie dzieje. Tak ma być - proponuję zapisać program jako TESTFNT.TB. Teraz wpisujemy POKE 756,$9C - zmieniając tym samym zestaw znaków. Musimy go wskazać zawsze po zmianie trybu graficznego - sprawdźmy, czy działa (polskie litery z control, przecinek zamieniony z średnikiem). Jest ok? To teraz gr.0 i ponownie polskie znaki. Nie ma? Nie ma... Poke 756,$9c.
Mały test - napiszmy w edytorze:

?$9C

Co uzyskaliśmy? Liczbę 156 - czyli nasze znaki znajdują się na 156 stronie pamięci. Gr.0 i poke 756,156 - są polskie znaki? Są. Zapis poprzedni jest tożsamy, tylko dana podana dziesiętnie. A teraz zwróćcie uwagę na jedno - jak wczytywaliśmy nasz font? Przypomnę:

Łatwe do zapamiętania? Łatwe. A teraz: jeśli zamiast $9C00 zapiszemy 39936 - co łatwiej zapamiętać? Dlatego ja używam adresów zapisanych szesnastkowo.
3. Ostatnia metoda, preferowana przeze mnie - to wykonanie osobnego pliku binarnego z danymi (różnymi). Na początek musimy taki plik wykonać - póki co z samymi fontami. Ja wykorzystuję do tego Super Packera, teraz po kolei:
- wychodzimy do DOS
- z dyskietki z narzędziami wczytujemy Super Packera (SP**)
- wczytujemy nasz font (opja F - load data file)=>POLSKIE.FNT
- podświetla nam się adres - wpisujemy 9C00
- zapisujemy jako DANE.DAT: S=>DANE.DAT
- wychodzimy do DOS
- wczytujemy TBXL i wpisujemy w edytorze:

BLOAD"D:DANE.DAT

POKE 756,$9c i cieszymy się wgranymi danymi (póki co fonty, ale będzie tam tego więcej z czasem). Co zrobiliśmy? Przygotowalićmy sobie plik binarny z danymi, do dalszego wykorzystania - który potem będzie idealny także do zrobienia wersji file naszego programu. W tym wypadku zacznijmy sobie tworzyć plik/notatki z danymi naszego programu, aby wiedzieć - co gdzie będzie. Dołączę do tutorialu plik tekstowy z notatnika - DANE.TXT. Będziemy go sukcesywnie uzupełniać.
Na zakończenie tej części tutoriala zastanówmy się, co nasza gra powinna mieć? Póki co zaproponuję bardzo uproszczony szkielet, który będziemy potem modyfikować/uzupełniać. Ponieważ tutorial jest pisany na bieżąco - pewne elementy mogą się zmieniać, byc modyfikowane w trakcie. Proszę o ewentualne uwagi na bieżąco.
Osobiście lubię, jak gra ma jakiś początek i koniec. Musi też być obsługa gry, najprostszy szkielet gry, który możemy stworzyć, mógłby wyglądać tak (proszę go wpisać):

50 EXEC INTRO:.WYWOLANIE INTRA
51 EXEC START:.WYWOLANIE GRY
90 END
99 --
100 PROC INTRO
101 GR.24:POKE710,0:POKE709,15:poke756
,$9c
102 COLOR %1:TEXT 10,10,"Tu będzie intro"
150 IF PEEK(53279)<>6 THEN 150
190 ENDPROC
199 --
200 PROC START
201 .TU ZEROWANIE DANYCH
202 EXEC PARAGRAFY
290 ENDPROC
299 --
300 PROC PARAGRAFY
340 ENDPROC

Zapiszmy całość jako GRA0.TB - osobiście przy większych poprawkach zmieniam numer, mogąc w razie czego wrócić do dalzego działania w przypadku namotania w kodzie. Spróbujcie sami przeanalizować ten szablon, w razie problemów - postaram się odpowiedzieć na pytania w postach.
======================================
Jak zwykle proszę o komentarze i pytania. Jednocześnie mam pytanie - znajdzie się litościwy grafik (może być na PC) i muzyk (CMC pilnie poszuiwany)?

Żeby nie było, też śledzę wątek, bardzo mnie ciekawi i z niecierpliwością czekam na kolejne odcinki. Szkółka elegancka! W wolnej chwili przysiądę do Atari i przejdę z teorii do praktyki. Tak trzymać!