Sprawdziłem, nie pomaga. Wiem co robi, przywraca 255 w buforze klawiatury po wciśnięciu jakiegoś klawisza, bo tam zostaje ostatnio wciśnięty klawisz. Nie pomyślałem o tym, ale tak jak mówię, teraz przetestowałem i nic to niestety nie daje w tym wypadku.

Testowałem teraz jeszcze wielokrotnie temat na różne sposoby i widzę, że problem pojawia się jak próbuję sprawdzić czy nie ma pustego stringa po wciśnięciu Return na INPUT. Może w takim wypadku jest coś dziwnego/losowego w A$ czasami, bo właśnie w wypadku jak testuję taki warunek, to również inne warunki potem się sypią.

Próbowałeś IF LEN(A$)=0 ?

A musisz mieć warunek tekstowy? Pod Turbo Basikiem użyj GET KEY po prostu (zamiast KEY można dowolną zmienną podstawić, ale KEY się pamięta) - jest to kod wciśniętego klawisza. Potem wyzeruj klawisz i tyle. ha, instrukcja zwraca kos wciśniętego klawisza.
A w swoim programie dodaj po input testowo PAUSE %1 (lub "pętlę" w Basicu liczącą od zera do jednego, pustą). Po mojemu za szybkie wywołanie, ale mogę się mylić.

Czy jest jakaś sytuacja kiedy A$="" nie zadziała, ale zadziała LEN(A$)=0 ?

@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ł.

Dobra, nowy wpis, aby nie umknął"

Odpal ten program. Jak dałeś A$=" " to oczywiście sprawdzasz spację, nie RETURN. Jak widać w załączonym kodzie - samo wciśnięcie RETURN powoduje przepisanie ostatnio wciśniętego klawisza (ASC(A$) nam to sprawdza), za to... Nie przypisuje zmiennej A$ żadnej wartości. Widać to w tym kawałku kodu. Niestety, poke 764,255 nie wymazuje ostatniego znaku (czyli chyba jest trzymany cały czas na stosie lub w buforze klawiatury, raczej w tym drugim). Nie pamiętam sposobu na jego wyczyszczenie.

@Sikor, no to może jakiś taki zbieg właśnie u mnie zachodził. Ale u mnie kod żyje, a jak nad czymś siedzę, to po kilku godzinach mam już zupełnie coś innego niż miałem na początku, więc nawet nie mam już jak swojego błędu odtworzyć.

Natomiast odpaliłem Twój programik, zmodyfikowałem mu tylko linię, żeby po return wpisywał K=9.

1 DIM A$(1)
2 Z=0
10 GOSUB 100
12 GOTO 10
100 K=0
101 INPUT A$:IF A$="" THEN K=9
102 IF A$="X" THEN K=1
104 Z=Z+1:? A$,K,ASC(A$),Z
105 RETURN

READY
RUN
?X
X         1         88        1
?A
A         0         65        2
?
          9         65        3
?

I faktycznie to będzie ten problem.
Za pierwszym razem wpisałem X i się K ustawiło na 1,
za drugim razem wpisałem A i się K ustawiło na 0,
za trzecim razem dałem tylko return - i zadziałał warunek sprawdzający A$="", ale ASC(A$) pokazał kod poprzedniego klawisza, czyli A.
No i tu jest pies pogrzebany, mamy z jakiegoś powodu sytuację, że A$ jest jednocześnie pusty i niepusty. Nie mam pod ręką żywego Atari, żeby sprawdzić, czy też się tak zachowa. Testy robiłem na Altirra 3.20 w zwykłym Basicu.

@Pin, PROC i EXEC jest fajny, przejrzystość kodu bez dwóch zdań itd. Jak robisz pojedynczy skok, to też PROC EXEC zajmie Ci mniej pamięci niż GOSUB RETURN, bo PROC/ENDPROC zajmuje mniej niż RETURN. Ale za to EXEC zajmuje więcej niż GOSUB, więc jak masz do wykonania dziesiątki skoków do tego samego podprogramu, to każdy EXEC zajmuje więcej pamięci niż GOSUB i zaczyna program puchnąć. Akurat to co grzebię jest na tyle duże, że zależy mi na pamięci i każdy bajt się liczy, więc robię GOSUB.

@Mq, po prostu zaciekawił mnie temat. Zamiast tego pewnie zadziała zbadanie długości A$ - i przy zerowej dać 9, bo tak to chyba działa w tym wypadku. Swoją drogą ciekawa sprawa.

Tak. Przypomniało mi się jeszcze, że ważna często była kolejność działań w IF pod Basiciem - tak ku potomności.
ok, myślę, że ten wątek można zamknąć - jak myślisz Mq?

To błąd BASIC-a - ASC nie sprawdza długości ciągu i bierze zawsze pierwszy znak ze zmiennej tekstowej (czyli starą wartość, albo nieustaloną jeśli zmienna nie była zainicjalizowana wcześniej w pamięci). Uzupełniłem Atariki: http://atariki.krap.pl/index.php/Atari_ … ri%20BASIC