Tricki na Amstradzie

[McArti0]

Ale, że seryjnie 2x LD SP,nn na sztywno? przecież dla 16kb taki program, sie nie zmieści w pamięci 

Ale 12,5 ? 

[matofesi]

Ale ja nie mówię czy się zmieści czy nie. Podliczam tylko jak szybko można to zrobić używając stosu. I nie widzę w wyliczeniach 12.5 - moje 13.75 to teoretyczna maksymalna przepustowość. Można by ciut skrócić używając jeszcze AF. Dodając AF' już niekoniecznie, bo wtedy trzeba też robić EX AF,AF'. A... i można zrezygnować z drugiego EXX - nie ma znaczenia którego bloku rejestrów używamy w kolejnym cyklu.

Natomiast jeśli chcesz oszczędzić rozmiar kodu to musisz używać pętli i od razu cała prędkość idzie do śmieci

Odpowiednio wyważony ciąg LDI i szybka pętla to najekonomiczniejsze rozwiązanie jeśli chodzi o w miarę szybkie przerzucanie dużych bloków danych.

[ZbyniuR]

znowu do odwolania nie mam stacjonarnego neta, 1szy raz w zyciu korzystam z neta w tel, siedzac w chodzie pod sklepem bo tu jest net darmo.
ledwo rozumiem co piszesz ale powiem tylko ze po rem mozesz uzywac dowolne kody oprucz zero, bo to konczy linijke basica. Powodzenia
Kody od 1 do 31 za na klawiszach z CTRL, jedynie 13 trzeba najpierw wyswietlic w chr$ a potem skopiowac go drugim kursorem

[matofesi]

To w zapisie programu w BASICu Amstrada nie ma pola z długością linii? On naprawdę polega na tym, że w środku tekstu znajduje konkretny znak i to jest dla niego koniec linii? Dziwne...

[tooloud]

a propos liczenia taktów - wyjadaczom to nie pomoże, ale ja jako laik używałem tego:

http://www.overtakenbyevents.com/tstates/

[matofesi]

To odpowiem sam sobie... pierwsze dwa bajty zapisu linii BASICa to długość stokenizowanej linii z uwzględnieniem tej długości oraz numeru linii (następne 2 bajty) i znacznika końca linii. Nie wiem jak to się zachowa a praktyce, ale moim zdaniem tak jak na Spectrum - można zrobić linię REM z odpowiednią liczbą np. spacji, żeby się zmieścił nasz kod a potem zapisać właściwy kod przez POKE do tejże linii za znacznikiem REM a na koniec kod wywołać w kolejnej linii odpowiednim CALLem. I jeśli nie spaprzemy kodu i wstępnego przygotowania linii to moim zdaniem zawartość REMa nie ma znaczenia (znowu - nie wiem jak na Amstradzie, ale Spectrum BASIC po napotkaniu tokena REM od razu przeskakuje do następnej linii).
Jedyne ograniczenie jakie znalazłem to 255 znaków, które w jednej linii można wprowadzić z edytora - biorąc jednak pod uwagę fakt, że długość linii ma dwa bajty nic nie powinno stać na przeszkodzie, żeby dłuższą niż 255 znaków linię "wygenerować" odpowiednim POKE łącząc ze sobą dwie albo więcej linii.

a propos liczenia taktów - wyjadaczom to nie pomoże, ale ja jako laik używałem tego:

http://www.overtakenbyevents.com/tstates/

Przyjemne. Taki automatyczny przeglądacz do tabeli... Choć średnio użyteczny do bardziej skomplikowanych konstrukcji, bo nie sumuje całości oraz transferów blokowych, pętli warunkowych itp. Ale na pewno ułatwia przeliczenia jak komuś się nie chce jeździć po dokumentacji

[tooloud]

matofesi, używałem tylko do liczenia małych fragmentów kodu, ale któryś debugger do z80 ma opcję licznika t-statów na bierząco z kodem, poszukam w wolnej chwili który.

[KWF]

ZASM coś takiego potrafi: https://k1.spdns.de/Develop/Projects/zasm/Documentation/z7.htm#A

[tooloud]

nie, to co innego - to zlicza Tstaty tak jakby w linii asemblacji kodu, nie jego wykonywania. Nie poda Ci Tstatów z 32 pętli przepisywania jakiegoś powtórzenia. Ale któryś debugger to robił - puszczałem kod i leciał licznik Tstatów, jak ustawiałem breakpoint to miałem zliczone do danego miejsca z każdym wykonanym rozkazem. To mogł być jakiś plugin do VS Code nawet - postaram się przypomnieć sobie co to było.

[tooloud]

to chyba to, można nawet ustawić określoną liczbę Tstatów do wykonania.

http://www.zxspectrum4.net/help/debugger.php

[KWF]

Chyba to samo, ZASM zlicza takty od początku danej etykiety kumulacyjnie.

Frament kodu zliczając stronką, która podałeś:

M   T1   T2   Code
3   17        call cls
3   10        ld de,banner
3   10        ld bc,banner_l
3   17        call print_str
3   10        ld de,text1
3   10        ld bc,text1_l
3   17        call print_str

Z pliku .lst wygenerowanego przez ZASM:

3E80: CD240A   [17]        call cls
3E83: 110000   [27]        ld de,banner
3E86: 010000   [37]        ld bc,banner_l
3E89: CD7F09   [54]        call print_str                       
3E8C: 110000   [64]        ld de,text1
3E8F: 010000   [74]        ld bc,text1_l
3E92: CD7F09   [91]        call print_str

[tooloud]

Tak, ale jak zrobisz pętlę i ileś wywołań procki to ZASM nie zliczy wszystkiego, bo robi asemplację kodu, a nie jego emulację z tsatami.

[KWF]

Sorki za moją niewiedzę, ale chyba inaczej rozumiemy:

"Instructions with varying execution time are given with their run-through time in first place and the branching or repeating time as a second value."

[tooloud]

Klaud nie sil się na złośliwość i zabawy w słówka tylko odpal jakiś kod z pętlami i zobacz, gdzie kod wyląduje po zadanej ilości t-statów przekraczających pętlę. Zliczyć t-staty z kodu potrafi arkusz Excela albo skrypt ze strony www, którą linkowałem wcześniej.

https://www.oshonsoft.com/z80.html#screenshot

to jeszcze mam zapisane pod hasem tstates

[KWF]

Pytam, bo twierdzisz coś innego niż autor asemblera, skoro przy pętlach pierwsza wartość to czas wykonania a druga podaje czas dla ponownego wykonania lub przeskoku do innego wątku.