1

Temat: Testy niektórych właściwości TBXL

Zainspirowany wątkiem http://www.atari.org.pl/forum/viewtopic … 54#p248754  popełniłem krótki test I tak - interpretując, jeśli podajemy dane szesnastkowo zamulamy program - wyniki poniżej:

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

po kompilacji:

TBTEST.COM
240       DANE DZIESIETNE
240       DANE DZIESIETNE ZE STALA
482       DANE SZESNASTKOWE

Czyli - poza podawaniem adresów nie jest dobrze... Warto wiedzieć - adresy ok, działania nie bardzo...
Btw - może jeszcze sprawdzę kiedyś czytanie (peek) po pamięci...

Sikor umarł...

Odp: Testy niektórych właściwości TBXL

To na pewno jest dobry listing?

3

Odp: Testy niektórych właściwości TBXL

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

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

4

Odp: Testy niektórych właściwości TBXL

@VAsko, prawie - kopiowałem pod altirrą. Ale każdy wie o co chodzi, wyniki ważne są ;)

Sikor umarł...

5

Odp: Testy niektórych właściwości TBXL

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

6

Odp: Testy niektórych właściwości TBXL

A pro po - tak sobie sprawdziłem, że maksymalna wartość w HEX to po przeliczeniu 65535, czyli jest to konstrukcja wyłącznie do korzystania z adresowania pamięci, stąd pewnie w obliczeniach działa wolniej...

Ostatnio edytowany przez Sikor (2019-03-11 22:07:35)

Sikor umarł...

7

Odp: Testy niektórych właściwości TBXL

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.

8

Odp: Testy niektórych właściwości TBXL

10 DPOKE 18,0:POKE 20,0
11 FOR I=$00 TO $FFFF:NEXT I
12 ? TIME
13 DPOKE 18,0:POKE 20,0
14 FOR I=0 TO 65535:NEXT I
15 ? TIME:? :GOTO 10

Na emulatorze wygląda to tak, że przez jakiś czas wynik jest na korzyść HEX, potem się to zmienia i tak w kółko.
Generalnie nie można przewidzieć wyniku. Dlaczego tak się dzieje ?

Ostatnio edytowany przez Cobol (2019-11-03 08:45:06)

9

Odp: Testy niektórych właściwości TBXL

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ł ;)

Ostatnio edytowany przez QTZ (2024-07-06 07:31:59)

Post's attachments

VTEST.TB 665 b, nikt jeszcze nie pobierał tego pliku. 

VTEST.XEX 11.4 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.

10

Odp: Testy niektórych właściwości TBXL

Za to zerowanie RTLCOCKa należy Wam się po łapach.

10 T=TIME
...
99 ? TIME-T

Jak komuś przeszkadza, że odejmowanie także zajmuje czas, to przypominam, że wykonywane jest raz, a FOR ze swoim narzutem - ile, kto wskaże.

Zawsze mam rację, tylko nikt mnie nie słucha.

11

Odp: Testy niektórych właściwości TBXL

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?

12

Odp: Testy niektórych właściwości TBXL

Zerowanie, bo i tak się przekręci? Cóż to za f**k logic?!  Odejmowanie zresztą ma taki sam wpływ na wynik, co "? TIME", bo wartość RTCLOCK jest pobierana przed każdą z tych operacji. Jak chcesz być bardzo dokładny, to czekaj na początek ramki.

QTZ napisał/a:

Szczególnie jak odczyta się dokładniej PEEK zamiast TIME.

"Dokładniej"? Co masz na myśli? Bo chyba nie "PEEK(20)+256*PEEK(19)+65536*PEEK(18)"?

QTZ napisał/a:

A dlaczego nie?

W przypadku programów, które zostawiają syf w systemie, gdzie tylko reset pomoże, faktycznie nie ma znaczenia stan tego rejestru. Inaczej sprawa wygląda, gdy program ma wrócić grzecznie do systemu, w którym mogą być programy rezydentne, korzystające z tego licznika.

=== Suplement ===

TIME$="205733":? TIME$:POKE 18,%0:DPOKE 19,%0:? TIME$
205732
000000

Ostatnio edytowany przez Lizard (2024-07-06 20:00:05)

Zawsze mam rację, tylko nikt mnie nie słucha.

13

Odp: Testy niektórych właściwości TBXL

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.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

14

Odp: Testy niektórych właściwości TBXL

Nie ma żadnej konwersji. Atari BASIC (i kuzyni, jak TBXL) nie przechowuje programów w pamięci w postaci tekstowej, tylko stokenizowanej. Liczby, o których tu mowa zapisane są jako 6-bajtowe liczby FP. Wyjątki to %0, %1, %2 i %3, które w ogóle nie są liczbami, tylko tokenami funkcji - każda z nich zwraca wartość, odpowiednio, 0, 1, 2 lub 3.

Proponuję mały eksperyment. To:

10 FOR I=$0 TO $FFFF:A=A+$01:NEXT I

Proszę wklepać w TBXL, zapisać program na dysk przez SAVE, a potem wczytać do Atari BASIC-a i zrobić LIST. A potem RUN.

Zdziwko, co? :)

KMK
? HEX$(6670358)

15

Odp: Testy niektórych właściwości TBXL

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.

Zawsze mam rację, tylko nikt mnie nie słucha.

16

Odp: Testy niektórych właściwości TBXL

Jak to działa, to osobna sprawa i jest to w gruncie rzeczy obojętne, bo to nie ma nawet działać, tylko ilustrować tezę, że "nie ma żadnej konwersji". Myślałem, że dostatecznie jasno wynika to z całości mojego posta.

KMK
? HEX$(6670358)