Przepraszam, może głupio odpowiem bo jeszcze kawy nie wypiłem, ale zmienić dyskietkę na tą z fontami po wczytaniu SP**?

ps. @Sikor, czy będziesz kontynuował w przyszłości cykl ?

Super! czekam z niecierpliwością :)

Hej!
Będzie, borykam się jeszcze z drobnymi sprawami, ale ruszamy dalej w sierpniu.

Wszyscy czekamy niecierpliwie :-)

Tak informacyjnie - zgrałem sobie grafiki lopeza i powoli wracam do żywych z tutorialem. Wiem, długo to trwało... :/

Super kurs. Dzięki Sikor, też śledzę jak najbardziej uważnie :)

Ja z uwag mam tylko coś o czym już mówiliśmy wcześniej, ale chciałbym przypomnieć: żeby wszystkie pliki, całość prac trzymać w jednym atr i nie bawić się w ustalanie gęstości i innych takich. I tak większość chyba programuje to i testuje pod emulatorem na pececie z racji wygody, a jeśli ktos jest takim hardkorowcem, że robi wszystko na Atari, to również poradzi sobie bez problemu z samodzielnym podzieleniem tego sobie jak mu wygodnie na dyskietkach.
Tak że proponował bym atr 720kB i wrzucić wszystko do niego - ale to już decyzja Sikora.

Ja obecnie dość dużo grzebałem akurat w TBXL przy okazji refaktoringu mojej starej gry z dzieciństwa The Last Disk (udostępniałem na sąsiednim forum) i przy tej okazji doświadczyłem różnych koncepcji, co zaowocowało wypracowaniem najwygodniejszej dla mnie metody pracy. Oczywiście każdy robi po swojemu, ale napiszę jak ja to robię, może się przyda innym.
Po pierwsze skorzystałem z narzędzi Sikora opisanych w tym wątku - wszystko bardzo się przydaje.
Robię tak, że mam atr 720kB, na którym mam MyDOS, TBXL, i pozostałe narzędzia. Pracuję pod Altirra, więc odpalam tego atr-a i z niego startuję. Dodatkowo mam podmapowany katalog na pececie jako H6: i w tym katalogu trzymam cały listing pisanego programu w zwykłym pliku textowym, którego edytuję sobie na pececie (używam akurat Notepad++, który koloruje mi ładnie składnię).
I teraz tak: pracę zaczynam od odpalenia Altirra, następnie uruchamiam TB.COM.
W TBXL piszę sobie ENTER "H6:GRA" (plik nazwałem GRA, żeby szybko się wpisywało).
To powoduje wciągnięcie całego listingu i już można go odpalić RUN
Następnie podczas wprowadzania zmian w listingu nie robię całej operacji za każdym razem od nowa, tylko kopiuję z pliku tekstowego kilka linijek, które akurat pozmieniałem i zwyczajnie w Altirra robię prawym przyciskiem wklej. I znowu RUN.
Bardzo szybko się w taki sposób pracuje. Program przerywam Reset(F5), albo Break(F7). Jak zmienię bardzo dużo w kodzie, to ewentualnie "odświeżam" całość, więc w Altirra robię Shift+F5(cold start), L->TB.COM, ENTER "H6:GRA" i już.
Dodatkowo na każdym etapie wklejania kodu do Altirra można przytrzymać F1(przyspieszenie emulacji), co powoduje szybkie wykonanie szeregu operacji tak długo jak trzymamy F1 - jak puścimy, to wszystko pracuje z powrotem z normalną prędkością.

Jeszcze co do łączenia plików z danymi. Używam Super Packera od Sikora, jest fajny, używam też Mossada - też wszystko super. Ale jak już mamy plik z danymi i chcemy do niego dokładać kolejne dane, które i tak mamy na pececie, to już robię to inaczej, szybciej. Plik binarny edytuję sobie na pececie programem HxD Hex Editor. Jak sobie otworzymy w nim nasz plik z danymi, to zobaczymy, że nagłówek, który dołożył nam Super Packer jest bardzo prosty i można go szybko i łatwo zmieniać ręcznie. Pierwsze dwa bajty, to FFFF, następnie mamy dwa bajty adresu początkowego pod jaki wczytane zostaną nasze dane, a następnie dwa bajty adresu końcowego. Oba adresy mają odwrotnie zapisane bajty (najpierw bajt młodszy, a później starszy -trzeba na to zwrócić uwagę). I teraz jak do swojego pliku doklejam np. kolejne dane, to po prostu wklejam te dane na końcu pliku w HexEditorze, do adresu końcowego dodaję odpowiednią ilość bajtów i poprawiam go ręcznie w pliku. Zapisuję sobie plik i gotowe. Poprawiony plik wrzucam sobie na swojego atr-a również w Altirra. Odmontowuję dyskietkę, wchodzę sobie w Tools->Disk explorer, tam usuwam stary plik, a nowy przeciągam i upuszczam do wnętrza atr-a. I gotowe, podmontowuję z powrotem atr-a i już mam zaktualizowane dane.
Dane binarne wczytuję w pierwszej linii programu za pomocą BLOAD, więc jak robię RUN, to nie muszę o tym pamiętać. Jak już program jest skończony, to wywalam tą linijkę z BLOAD, a dalej kompiluję i łączę wszystko w całość już tak jak opisał Sikor w swoich poradnikach.

Tak, ja sobie sporo skorzystałem z Twoich porad, tak że super.

Co do tworzenia na Atari i opisywania pod tym kątem, to jestem jak najbardziej za - ma to też swoją dużą wartość, więc kontynuuj to właśnie tak.

Ja te swoje "udogodnienia" pecetowe opisałem tutaj tylko tak nawiasem, w dzisiejszych czasach jest mnóstwo różnych narzędzi, z których można korzystać na różne sposoby, tylko tyle chciałem pokazać. Odpowiada mi bardzo tutorial pokazujący jak to się wszystko robi na Atari, bo mówimy cały czas o Atari tylko i wyłącznie. Natomiast znając już jak się coś tam robi na Atari i mając podstawy można poszukiwać jakby w kolejnych krokach udogodnień, dodatkowych narzędzi itp. - ale to już indywidualnie co kto tam lubi.

Mam pytanie dot. zawartości materiałów binarnych. Co to jest za plik z tymi polskimi fontami? Oprócz tego, że ma polskie fonty, to zauważyłem, że ma trochę pozmieniane też inne literki. Np. S jest bardziej zawinięte itp. Ale najistotniejsze co zauważyłem, to font ma zamienione miejscami przecinek i średnik. Pytam z ciekawości, to tak ma być, czy może jest to jakaś wersja "rozgrzebana" czy coś w tym stylu? A może celowo font ma szereg jakichś zmian. Czy jest gdzieś do tego opis jakiś autora, lub coś, albo możesz Sikor Ty coś więcej o tym pliku opowiedzieć?

I może trochę wybiegnę tutaj do przodu, ale mam pytanie dot. przygotowania tekstów do gry i ich wyświetlania.
Kłopot jest taki, że jak chcę przykładowo wyświetlić większe ilości tekstu całymi ekranami, to najmniej kosztowne wydaje się być wrzucenie takich tekstów również jako dane binarne i wówczas wyświetlanie ich za pomocą MOVE bezpośrednio wrzucając pod adres ekranu z odpowiednim ofsetem. To działa super, jednak żeby w ogóle zadziałało, to teksty muszą być przygotowane w kodowaniu znaków z użyciem INTERNAL CODE. Jednak jak mamy tak przygotowane teksty, to z kolei nie da się (chyba) łatwo takiego tekstu wydłubywać jednocześnie z pamięci i wyświetlać za pomocą standardowych PRINT, czy TEXT, czy pojedynczych znaków przez CHR$, bo wszystkie te polecenia wymagają z kolei tekstu zakodowanego jako ATASCII. Czy da się jakoś łatwo radzić sobie z tą dualną naturą kodowania znaków na Atari (IC/ATASCII)?

O faktycznie, przeoczyłem tą uwagę.
Niemniej chętnie bym się coś więcej na temat tych tekstów/fontów/wyświetlania dowiedział, bo akurat się tym bawię w danym momencie:-)

To odpowiem: linie DATA są rozdzielane...? Przecinkami. Zamieniam znak w fontach ponieważ później łatwiej jest operować danymi, a z punktu pisania zmiana żadna. Dzięki temu data bez apostrofów może działać zarówno jako tekst, jak i dane liczbowe.

Mała ciekawostka odnośnie DATA.
Atari BASIC wewnętrznie pobiera dane z linii DATA za pomocą tej samej procedury, która realizuje INPUT. Tak więc dane w liniach DATA rozdzielane przecinkami traktowane są jako osobne. Polecam sprawdzić działanie takiego kodu:

10 DIM A$(100)
20 RESTORE 
30 READ A$
40 ? A$
50 GOTO 30
100 DATA 1ST LINE
110 DATA 2ND LINE,AND THE REST
120 DATA 3RD LINE
130 DATA 
140 DATA 4TH LINE

Edit: Dane w liniach DATA zawsze trzymane są w postaci niestokenizowanej - niezależnie od tego czy tam są liczby czy tekst, więc jest to mało optymalna metoda trzymania liczb dłuższych niż 6 cyfr.