była sobota, jest niedziela. Ludzie chcą jeszcze pożyć. Lub po rzyć :)

Mam gdzieś program od gościa który zniknął z forum pokazujący jakie rozkazy TBXL powodują zwolnienie po kompilacji, ale nie mogę tego odnaleźć, ma to ktoś gdzieś może i mógłby wrzucić ?

Ostatnio zastanawiałem się jak się używa liczb szesnastkowych w Atari BASIC, ale nie mogłem wymyślić sposobu, muszę zajrzeć do jakiegoś podręcznika. Ktoś wie, czy obsługa zapisu szesnastkowego dla liczb jest możliwa w zwyczajnym BASIC? Bo chciałem przetestować jak to działa w BASIC, ale właśnie nie wiem, jak zapisać liczbę szesnastkowo w kodzie programu.

Jeśli w TB XL te czasy są realne, to może to wynika, że CPU potrzebuje tak, czy inaczej liczby dziesiętne w kodzie do wykonania, więc, jak by nie zapisać liczby, najpierw musi być przerobiona na dziesiętną, potem wrzucona w rozkazy i dopiero wykonanie, tak mi się myśli.

Wynik z pierwszego programu jest błędny, bo zabrakło resetu licznika przed hex, więc wynik hex jest sumą dwóch ostatnich testów.

Po dopisaniu brakujących linii na aktualnej Altirrze:

10 DPOKE 18,0:POKE 20,0
11 FOR I=0 TO 10000:NEXT I
12 ? TIME,"DANE DZIESIETNE"
13 DPOKE 18,0:POKE 20,0
14 FOR I=%0 TO 10000:NEXT I
15 ? TIME,"DANE DZIESIETNE ZE STALA"
16 DPOKE 18,0:POKE 20,0
17 FOR I=$00 TO $2710:NEXT I
18 ? TIME,"DANE SZESNASTKOWE"

352       DANE DZIESIETNE
352       DANE DZIESIETNE ZE STALA
352       DANE SZESNASTKOWE

W drugim przypadku:

2349
2349

A w ogóle to ten test nie mierzy tego co potrzeba, bo w tych pętlach operacja konwersji (jeżeli jest) zachodzi tylko raz:

1 A=10:B=20:FOR I=A+%1 TO B+A+$01:A=1000:B=A:? I;" ";:NEXT I:? :? I:? A:? B:END

11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32
1000
1000

Tu  poprawiony test, choć w tym przypadku również identyczne wyniki:

10 MOVE ADR("♥♥♥"),18,3
11 FOR I=%0 TO $FFFF:A=3-3:NEXT I
12 ? TIME,"DANE DZIESIETNE"
13 MOVE ADR("♥♥♥"),18,3
14 FOR I=%0 TO $FFFF:A=3-%3:NEXT I
15 ? TIME,"DANE DZIESIETNE ZE STALA"
16 MOVE ADR("♥♥♥"),18,3
17 FOR I=%0 TO $FFFF:A=3-$03:NEXT I
18 ? TIME,"DANE SZESNASTKOWE"

6824      DANE DZIESIETNE
6824      DANE DZIESIETNE ZE STALA
6824      DANE SZESNASTKOWE

Być może konwersja jest wykonywana raz, a później działania są wykonywane na skonwertowanych wartościach?

Jeszcze jeden test:

10 A=%0:MOVE ADR("♥♥♥"),18,3
11 FOR I=%0 TO $FFFF:A=A+1:NEXT I
12 ? TIME,"DANE DZIESIETNE"
13 A=%0:MOVE ADR("♥♥♥"),18,3
14 FOR I=%0 TO $FFFF:A=A+%1:NEXT I
15 ? TIME,"DANE DZIESIETNE ZE STALA"
16 A=%0:MOVE ADR("♥♥♥"),18,3
17 FOR I=%0 TO $FFFF:A=A+$01:NEXT I
18 ? TIME,"DANE SZESNASTKOWE"

6884      DANE DZIESIETNE
6864      DANE DZIESIETNE ZE STALA
6883      DANE SZESNASTKOWE

Tu są różnice. Myślę, że po kompilacji powinny się zrównać.

Po skompilowaniu (wyniki prawie równe i czasami wychodzą odwrotnie, lub są równe):

2870      DANE DZIESIETNE
2869      DANE DZIESIETNE ZE STALA
2870      DANE SZESNASTKOWE

Dopisałem jeszcze taki wariant - dana przez zmienną:

19 A=%0:B=1:MOVE ADR("♥♥♥"),18,3
20 FOR I=%0 TO $FFFF:A=A+B:NEXT I
21 ? TIME,"DANE DZIESIETNE"
22 A=%0:B=%1:MOVE ADR("♥♥♥"),18,3
23 FOR I=%0 TO $FFFF:A=A+B:NEXT I
24 ? TIME,"DANE DZIESIETNE ZE STALA"
25 A=%0:B=$01:MOVE ADR("♥♥♥"),18,3
26 FOR I=%0 TO $FFFF:A=A+B:NEXT I
27 ? TIME,"DANE SZESNASTKOWE"

7004      DANE DZIESIETNE
7034      DANE DZIESIETNE ZE STALA
7003      DANE SZESNASTKOWE

Ciekawe, poprzedni wynik korzystniejszy dla stałej, a teraz odwrotnie.

Po skompilowaniu odwrotnie - przez zmienną szybciej i bez znaczenie jakie dane:

2635      DANE DZIESIETNE
2635      DANE DZIESIETNE ZE STALA
2635      DANE SZESNASTKOWE

W załączniku ostatnie testy - trzeba chwilkę poczekać, bo program wygląda jakby się zawiesił ;)

Nigdy nie wiadomo jak długo Atari jest włączone i może się tak zdarzyć, że licznik się akurat przekręci, dlatego zerowanie.
Może za każdym razem nie potrzebne, ale wtedy jest niemal identycznie. Poza tym jak zauważyłeś odejmowanie może lekko wpłynąć na wynik. Szczególnie jak odczyta się dokładniej PEEK zamiast TIME.

A dlaczego nie?

Wystarczy w Sparta DOS załadować JIFFY.SYS i uruchomić linię z zegarkiem przez TD ON i widać, co robi resetowanie RTCLOK-a. Od RTCLOK-a zależy też aktualizacja zegara sparcianego co wpłynie na datę i czas tworzonych plików. Podejrzewam że w DOS XE skutek też będzie taki sam.

Twój przykład działa przypadkiem. Stałe liczbowe w Atari Basicu poprzedzone są kodem 14. W Turbo Basicu XL stałe zapisane w notacji szesnastkowej - kodem 13. Wygląda na to, że Atari Basic sprawdza w tym przypadku, czy kod jest mniejszy bądź równy 14.