Sikor, wpadła mi w ręce oryginalna płytka z kartridża XEGS z grą One On One. W komplecie mam do niej oryginalną naklejkę z tegoż kartridża i nie pasuje ona do okienka w wydrukowanej obudowie od Ciebie.
Naklejka ma 55x53mm, a okienko 54,5x52,5mm.
Myślę, że okienko powinno być większe w obie strony o 1mm niż naklejka, żeby naklejka mieściła się w nim swobodnie. Czyli jakieś 56x54mm by musiało mieć okienko, nie wiem jakie jest w oryginale.

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)?

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, tylko, że nawet gdy to robiłem, to mi się działy jaja. Nie mam już tego problematycznego kodu, ale myślę, że kłopot polegał na tym, że sprawdzałem sobie w szeregu IF-ami po kolei te warunki, tylko że w różny sposób. Prawdopodobnie mój problem się powtarzał dlatego, że na początku sprawdzałem w pierwszej linii Return, więc obojętnie czy sprawdzałem LEN(A$)=0, czy też A$="", to ten warunek prawdopodobnie działał poprawnie i przypisywał odpowiednią wartość pod moją zmienną wynikową. Tylko że po sprawdzeniu tego warunku leciały jeszcze warunki dot. poszczególnych wprowadzonych liter i prawdopodobnie któryś z tych warunków również zwracał prawdę i nadpisywał mi zmienną wynikową inną wartością. Stąd miałem bałagan. Myślę, że temat jest wyjaśniony.

@mono: u mnie oba te IF-y działały tak samo. Jednak gdy zastosowałem którykolwiek z nich, to mój problem występował tak samo.

@Sikor: też myślę że jest to warte zbadania, zwykle jestem dociekliwy w takich kwestiach, ale przesiedziałem nad tym dzisiaj chyba ze trzy godziny i potrzebuję rozwiązania skutecznego, żeby działało, a GET mi to zapewnił - trochę już opadłem nad tym z sił.

@mono, strukturę programu mam dokładnie taką jak napisałeś w przykładzie. Z tym że ja ten program mam dłuuuugi na kilkaset linii i jest to trochę rozstrzelone, ale DIM jest na początku, wywoływane tylko raz, kolejność wszystkich działań jest taka jak u Ciebie.

@Fox, dzięki za przypominajkę, zapomniałem już że się tak sprawdzało w Basicu - przypominam sobie dawne czasy po wielu latach, a mam przyzwyczajenia ze współczesnych języków, głównie z C i podobnych.
Jednak przy tak postawionym warunku mam te same problemy, te same objawy.

Ciekawe jest to, że ten problem pojawia mi się dość rzadko, raz na kilkadziesiąt wprowadzonych liter, lub Returnów.

Testuję to pod Altirrą, może ona robi jakiś problem?
Dziwna sprawa, bo na takim krótkim programiku jak te powyższy od mono nie udaje mi się tego błędu odtworzyć, a dzieje się na długim programie. Mam w nim też bardzo dużo GOSUB-ów jednych w drugich i gdzieś tam głęboko w nich siedzi dopiero ten INPUT A$. Może są jakieś granice stosu i coś się przez to kaszani ze zmiennymi?

W Atari nie:-)

Proszę bardzo.
A jest do 5,25"
B jest do 3,5"

Również obstawiał bym ROM. One po latach padają, tak samo jak OS w kompie, czy Basic. Akurat podmianka tego ROMu jest tania, wsadź sobie jakiś EEPROM, one są tanie i łatwo dostępne. Przy okazji podmianka wskazana, bo możesz sobie Hyper XF wsadzić, jak radził wcześniej perinoid. Polecam również, przyjemny soft.

Natomiast drugą rzecz jaką bym jeszcze sprawdził, to czy przypadkiem kwarc nie padł - też po latach im się zdarza niedomagać.

Stary, co to za porównanie? Oczywiście, że CRT nic nie przebije, ani teraz ani nigdy. A to dlatego, że nasze komputerki były pod takowe projektowane. Chyba nikt zdrowy na umyśle nie używa LCD, żeby mieć lepszy obraz i parametry? LCD używa się dlatego, że zajmuje mniej miejsca i dlatego, że CRT się kończą i nie ma już ich prawie, a jak są to już nie dają rady za bardzo.

Natomiast z tym lagiem, to ja tam nie wiem. Fakt, może scrolle nie sa idealne, ale na 710MP w grach wszystko jest gites, wystarczająco dobrze, żeby sobie normalnie pograć w cokolwiek bądź i nie zastanawiać się w trakcie gry, że coś jest nie tak.