No i chyba problem się wyjaśnił choć niestety nie rozwiązał... Wychodzi mi, że zassemblowany kod ma w środku coś, co powoduje, że - mimo REMa na początku linii - parser BASICowy dziczeje. Jeśli kod się wczytuje do REMa i od razu wykonuje to wszystko jest OK. Jeśli po wczytaniu kod się zatrzyma a potem damy RUN, albo GOTO, które wymusi przejście przez pierwszą linię to parser idzie gdzieś w kartofle i potem zmienna indeksowa nie działa jak należy - wyświetlanie posortowanej tablicy zatrzymuje się po jednym ekranie.
W związku z tym żeby sorter zadziałał poprawnie nie możesz dopuścić do tego, żeby kod parser analizował pierwszą linię. Czyli... po wczytaniu do REMa sortera musisz od razu zapisać program z LINE 10 - załadowany w ten sposób nie przechodzi (w odróżnieniu od goto 10 czy run 10) przez pierwszą linię i działa poprawnie. Jakiekolwiek zatrzymanie i ponowne uruchomienie wymagające od BASICa przeglądania pamięci kaszani dane w dziwny sposób.
W załączniku wszystko co potrzebne
sort_b.tap to pełne demo - kod startuje od linii 9999, wczytuje sorter do REMa i skacze do linii 10. Ustawia parametry, wczytuje dane i wyświetla przed posortowaniem. Potem READY, klawisz, sortowanie, klawisz i wyświetla jeszcze raz posortowane. Nazwę tablicy POKEujesz pod 23296, liczbę pozycji z początku, które ma ci przesortować pod 23298 - demo pokazuje w praktyce sortowanie pierwszej połowy stupozycyjnej tablicy.
sort.bas to źródło BASICowe tego samego programu
sort.asm to właściwy sorter
sort_asm.tap to sam skompilowany sorter w formie TAPa
sort.bin to to samo jako czysty kod binarny
