Autor Wątek: Tricki na Amstradzie  (Przeczytany 76415 razy)

tooloud

  • *****
  • Wiadomości: 3185
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: Tricki na Amstradzie
« Odpowiedź #75 dnia: 2021.02.15, 21:46:42 »
Pytania nie zauważyłem, ale chyba ja nie rozumiem dlaczego taki nacisk na to kładziesz, bo jest to dosyć oczywiste:

http://z80-heaven.wikidot.com/instructions-set:jr

weźmy skok warunkowy JR NZ, NN

jeżeli jest spełniony warunek to zajmuje to prockowi 12 tstatów, jeżeli nie jest - tylko 7. Dlatego dwa wyliczenia dla pętli. Ale czy policzy ile razy zrobi pętlę i jaka jest suma tsatów na wyjściu z pętli? Raczej nie, ale jestem otwarty na zmianę myślenia o ZASM jeżeli jest inaczej.

I teraz jeszcze raz - o czym pisałem - DEBUGGER, nie assembler, pozwala na śledzenie kodu wraz z przyrostem tstatów/rejestrów etc. Assembler może Ci w raporcie wyliczyć tabelkowe dane jak te powyżej, ale w praktyce - chcesz się zmieścić z czymśtam w 250 tstatach - albo zobaczyć gdzie wypada ta ilość tstatów w Twoim kodzie - wtedy ma sens narzędzie o którym pisałem. Kompletnie dwa różne zastosowania i potrzeby.
dużo sprzętu mało czasu.

KWF

  • *****
  • Wiadomości: 6823
  • Miejsce pobytu:
    trzecia planeta od Słońca
  • "I co ja robię tu, u-u, co Ty tutaj robisz ..."
    • Insta do lasownia
Odp: Tricki na Amstradzie
« Odpowiedź #76 dnia: 2021.02.16, 07:02:14 »
Chyba qmam. Dla mnie programowanie jest poza moim poziomem abstrakcji, dlatego nie jestem informatykiem lub programistą. Dzięki.
KWF
-----
R Tape loading error 0:1
Moje zabawki: https://github.com/McKlaud76

matofesi

  • *****
  • Wiadomości: 2048
  • Miejsce pobytu:
    Toruń/Poland
Odp: Tricki na Amstradzie
« Odpowiedź #77 dnia: 2021.02.16, 08:58:48 »
Problem statycznego vs dynamicznego zliczania czasów wykonania to stosunkowo skomplikowana kwestia. Bo z jednej strony jest to, czego nie zrozumiał Klaud - czyli proste statyczne choćby z warunkowymi wynikami zliczanie można zrobić choćby podczas assemblacji ale nie da się tego zrobić sensownie bez pełnej symulacji/emulacji wykonania kodu. Debuggery o których wspomina tooloud też nie do końca będą potrafiły to zrobić dobrze jeśli nie mają np. mechanizmów "podkładania" danych zewnętrznych. Dla "prostego" kodu liczącego jakieś rzeczy, przerzucającego dane itp. można policzyć czasy wykonania stosunkowo prosto. Ale co z kodem, który robi jakieś I/O i chcielibyśmy wiedzieć jak się czasowo zachowa zależnie od danych, które dostanie z zewnątrz?... Profilowanie wykonania kodu to cała szeroka gałąź i to o czym dyskutujemy to oczywiście tylko malutki jej wycinek :)

Myślałem kiedyś, żeby sobie spróbować zrobić taki "profiler" (ale raczej właśnie do dynamicznego zliczania taktów niż do analizy które gałęzie kodu jak się wykonują), ale po przemyśleniu uznałem, że ilość pracy jaką trzeba by w to włożyć żeby było zrobione dobrze przekracza użyteczność otrzymywanych wyników w zastosowaniach, do których chciałbym takiego narzędzia używać ;) Zadziałała więc klasyczna zasada "jeśli chcesz coś zrobić, to usiądź i przemyśl... przejdzie ci" ;)

Gryzor

  • *****
  • Wiadomości: 2009
  • Miejsce pobytu:
    Warszawa
Odp: Tricki na Amstradzie
« Odpowiedź #78 dnia: 2021.02.16, 11:05:17 »
Profiler zatrzymal sie w 2016 roku  :D
https://www.speccy.pl/forum/index.php?topic=2346.0

Warunki i dane mozna symulowac w roznych przebiegach, ale dodajac przerwania wszystko sie znacznie komplikuje.
Moim zdaniem dobry statyczny profiler jest wystarczajacy - reszte mozna analizowac w emulatorze podczas normalnego wykonania programu. Tu bardziej przydaja sie narzedzia analizy/prezentacji niz same Tstates. Np. co mi z tego ze w funkcja f zajmuje lacznie 20% czasu wykonania, jak nie wiem skad i ile razy do niej wchodze. Tyle, ze na 8bitach procedury to nie jest normalnosc, bo na call/ret traci sie czas. I zostaje nam caly piekny kod z naduzywaniem GOTO...

matofesi

  • *****
  • Wiadomości: 2048
  • Miejsce pobytu:
    Toruń/Poland
Odp: Tricki na Amstradzie
« Odpowiedź #79 dnia: 2021.02.16, 11:08:56 »
Liczenie taktów ma w praktyce dwa zastosowania: porównywanie wydajności różnych algorytmów albo metod implementacji tego samego algorytmu oraz liczenie time-sensitive efektów graficznych. Do pierwszego przydać się może profiler albo debugger liczący dynamicznie, drugie zwykle trzeba jednak policzyć ręcznie ewentualnie posiłkując się maszynkami podobnymi do "kalkulatora" do którego link dał tooloud.

tooloud

  • *****
  • Wiadomości: 3185
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: Tricki na Amstradzie
« Odpowiedź #80 dnia: 2021.02.16, 19:05:04 »
Tzn. ten kalkulator to takie bardzo proste narzędzie (użyłem tylko do sprawdzenia paru prostych kodów) - wg mnie debuggerem z licznikiem tstatów robi się to lepiej i bardziej uniwersalnie typu limit tstatów do zbadania na żywym kodzie etc. czyli z obiema rzeczami, które wymieniłeś używałbym debuggera, a nie tego kalkulatora (to taka bardziej ciekawostka - mam gdzieś na dysku wspomniany arkusz do Excela, który generalnie robi to samo, wklejasz kod, a on generuje kolumnę obok tstaty) - chociażby z racji tego, co próbowałem Klaudowi wytłumaczyć.
dużo sprzętu mało czasu.

matofesi

  • *****
  • Wiadomości: 2048
  • Miejsce pobytu:
    Toruń/Poland
Odp: Tricki na Amstradzie
« Odpowiedź #81 dnia: 2021.02.17, 08:17:45 »
Ja wiem, że proste, ale na co dzień jak potrzebuję policzyć takty to otwieram PDFa z manualem Z80 (albo po prostu przywołuję otwarte okno - gdzieś tam prawie zawsze wisi ;)) i liczę na piechotę przewijając PDFa w te i we wte ;)
Co do zasady uważam, że takie liczenie ma sens w kilku dość ograniczonych przypadkach - głównie akademickich dyskusji oraz efektów na borderze na Spectrum - i w praktyce dotychczas właściwie nie odczuwałem potrzeby używania bardziej zaawansowanych narzędzi tego typu.

McArti0

  • ***
  • Wiadomości: 113
Odp: Tricki na Amstradzie
« Odpowiedź #82 dnia: 2021.02.17, 23:46:22 »
kopiowanie ekranu  &c000-&FFFF do banku 1 &4000-&7FFF

musimy mieć 3 linie rem wypełnione do końca

kopiowanie przez stos z prędkością 15,6 T/byte - szybszy od LDI ! ;-)

org #277
di

push AF
push hl ;11
push bc ;11
push de ;11
push iy ;15
push ix ;15
exx ;4
EX AF, AF' ;4
push AF
push hl ;11
push bc ;11
push de ;11

;-------------------

ld (#8002),SP
ld sp,#fff0      ;źródło

ld ix,#7fff       ;cel-1
inc ix
ld a,170          ;170*16*6+16*4=16384

petla:
EX AF, AF'  ;4

macro kopia            ;246T/16byte

pop af ;10
pop de ;10
pop bc ;10
pop hl ;10

exx ;4

pop iy ;14
pop de ;10
pop bc
pop hl

ld sp,ix ;10

push hl ;11
push bc ;11
push de ;11
push iy ;15

exx ;4

push hl ;11
push bc
push de
push af

ld hl,#7ff0 ;10
add hl,sp   ;11
ld sp,hl    ;6

ld de,#fff0 ;10
add ix,de ;15

mend

kopia
kopia

ost_4:
kopia
kopia
kopia
kopia

EX AF, AF' ;4
dec a ;4

jp nz,petla ;10    170*6*16 byte=16320

inc a

ex af,Af'

jp nz,ost_4 ;10  4*16 byte=64

ld sp,(#8002) ;20

jp linia_3

org #377

linia_3:
pop de
pop bc
pop hl
pop af

ex af,af'
exx

pop ix
pop iy
pop de
pop bc
pop hl
pop af

ei
koniec:
ret

McArti0

  • ***
  • Wiadomości: 113
Odp: Tricki na Amstradzie
« Odpowiedź #83 dnia: 2021.02.19, 23:22:53 »
Ja pisywałem tylko w Basicu a

LD HL
LD DE
LD BC
LDIR
RET

to najbardziej zaawansowany kawałek kodu jaki zdarzało mi się używać świadomym znaczenia każdego bajta. :)
Czy potraficie tak zmodyfikować powyższą metodę bym mógł ją wywoływać w Basicu podając jednocześnie parametry?
czyli CALL adrprocedury,adrźródła,adrdocelowy,ileprzesłać 
a nie jak teraz, że muszę POKE-ami ją modyfikować i wywołać prostym CALL adrprocedury

I skoro trafiłem na takich speców to zapytam, ile by zajął kod do przeniesienia 16KB tą metodą LDI?

ostatni parametr jest od razu w DE jeżeli, skorzystać z tego to nie mógł by to być "ile przesłać", tylko adres docelowy.
można też skopiować DE do BC.

generalnie rejestr IX zawiera adres w pamięci gdzie znajduje się słowo (integer) z ostatnim (u nas trzecim) parametrem.

(IX+2) to adres przedostatniego parametru
(IX+4) to adres przed-przedostatniego parametru czyli pierwszego.

w rejestrze A jest ilość parametrów.

można by karmić rejestry długą sekwencją

LD C,(IX+0)
LD B,(IX+1)
LD E,(IX+2)
LD D,(IX+3)
LD L,(IX+4)
LD H,(IX+5)

;19*6=114 taktów

LDIR

RET

to przy założeniu, że na pewno są 3 parametry, bo nie sprawdzamy akumulatora.


Wersja przez stos

DI               ;4
LD IY, 00     ;14
ADD IY,SP   ;15

LD SP,IX     ;10

POP BC      ;10
POP DE      ;10
POP HL      ;10

LD SP,IY    ;10

EI             ;4

;  ^  87 taktów

LDIR

RET

ps. nie da się umieścić w rem niestety ;-), bo są zera w jednym i drugim.

ZbyniuR

  • *****
  • Wiadomości: 3333
  • Miejsce pobytu:
    Carlisle w UK
  • CPC AGA PSX
Odp: Tricki na Amstradzie
« Odpowiedź #84 dnia: 2021.03.05, 21:49:13 »
Komenda LIST toleruje kod zero w miejscu gdy jest parametrem np jednym z bajtów liczby podanej jako parametr, ale w innych niespodziewanych miejscach sprawia że LIST kończy działanie i daje Ready. A jeśli to nie ostatnia linia to dalszy ciąg listingu można wyświetlić podając kolejny nr linii jako parametr np LIST 30-
Jest to też trick by ukryć możliwość wylistowania programu. Oczywiście takie zero można wstawić tylko za pomocą POKE.
- Jeśli masz w domu światło i wodę, tzn. że masz światłowód. ;)

McArti0

  • ***
  • Wiadomości: 113
Odp: Tricki na Amstradzie
« Odpowiedź #85 dnia: 2021.03.08, 14:47:49 »
To znaczy, że ma to być w środku linii? w zmiennej tekstowej np?

McArti0

  • ***
  • Wiadomości: 113
Odp: Tricki na Amstradzie
« Odpowiedź #86 dnia: 2021.03.09, 19:38:11 »
Wrzucam procedurę używającą, przerwań. Postarałem się podłączyć ją przed firmwarową obsługa przerwań żeby złapać je jak najszybciej. Wyszło na to, że CPC w większości skacze z &0038 do &B941 rozkazem z ROMu a nie RAMu. Dlatego rozkaz skoku do swojej procedury umieściłem pod &B942 a zniszczone w ten sposób rozkazy istniejące odtworzyłem na końcu swojej procedury, żeby procedura firmwarowa nie ucierpiała.

procedura przechowywana jest w rem. Potem kopiowana do miejsca gdzie działa czyli &9000.

Z ciekawostek to w rem kłopotliwe jest przechowywanie bajtów chr$(&80), bo wyglądają identycznie jak chr$(&20) czyli jest to spacja. Takiego bajtu nie da się skopiować klawiszem COPY. zatem postanowiłem unikać w REM  kodu 0 i 128 (&80).

Jestem zaskoczony jak wysoko zaczynają się przerwania. Przeważnie ekran krojony jest na 6 kawałków w tym bitmapa na 4. Tutaj po paskach bordera widać, że przerwaniami można np odkroić ostatnią 25 linię tekstu.

;oryginalna procedura CPC od #B941 do której skacze CPC z &0038
;di
;EX AF,AF'
;JR C,#B978
;--^-- czesc nadpisana
;B945:
;EXX
;...

;zmiana startu procedury przerwania
;org #B941
;DI
;JP int ;#9010

org #9000

set_:
di
ld HL,#B942

ld (HL),#C3 ;kod JP
inc hl
ld (hl),#10 ;kod adres L
inc hl
ld (hl),#90 ;kod adres H
ei
ret

org #900E
color0:
db #55

org #900F
color1:
db #54

org #9010
;nowa procedura przerwania
int:
push bc
push AF

ld b,#1  ;
;org #9013
;db #01
loop:
djnz loop

ld a,(color0)
ld c,#7F
inc c
ld b,a
and c
JR NZ,jedynka
zero:
ld a,b
or c
ld (color0),a
ld a,(color1)
jR omin

jedynka:
ld a,b
and #7F
ld (color0),a

omin:
ld bc, &7f10
out (c), c
out (c), a

pop AF
pop bc

;odtworzenie funkcjonalnosci czesci nadpisanej procedury oryginalnej.
EX AF,AF'
JP C,#B978
JP #B945

;oryginalna procedura CPC od #B941
;di
;EX AF,AF'
;JR C,#B978
;--^-- czesc nadpisana
;B945:
;EXX
;...

Procedura kopiująca z REM do &9000 bez zer i &80 wygląda tak:

org #260
xor a
ld b,a  ;#00
ld c,#B0
ld d,#90
ld e,a ;#00
ld hl,#017F
inc hl ;#0180
ldir
ret

McArti0

  • ***
  • Wiadomości: 113
Odp: Tricki na Amstradzie
« Odpowiedź #87 dnia: 2021.03.09, 22:49:13 »
No to teraz prawdziwy TRICK.  :D

w kernelu jest wiele procedur, w których parametr trzeba podać w rejestrze akumulatora.

zróbmy to tak:

10 DIM kod%(2):kod%(0)=&CD7B:kod%(2)=&C9:DEF FNkernel=@kod%(0)

i teraz

20 kod%(1)=&BD1C : CALL FNkernel,2  : REM zmiana trybu wyświetlania na 2.

ps. w prostym przypadku można jeszcze sprytniej

call &BD1C,1,1  <dwa parametry oznaczają tryb 2
call &BD1C,1     <jeden parametr oznacza tryb 1
call &BD1C        <brak parametrów oznacza tryb 0

« Ostatnia zmiana: 2021.03.10, 00:38:29 wysłana przez McArti0 »

ZbyniuR

  • *****
  • Wiadomości: 3333
  • Miejsce pobytu:
    Carlisle w UK
  • CPC AGA PSX
Odp: Tricki na Amstradzie
« Odpowiedź #88 dnia: 2021.03.10, 00:42:06 »
Nie ogarniam tych czarów.
Dotąd takie coś robiłem dodając po CALL &bd1c tyle dowolnych parametrów jaki MODE chciałem.

PS.: Ten DIM jest zbędny bo w CPC trzeba to używać tylko gdy któryś z wymiarów tabelki ma mieć więcej niż 10.
PS2.: Żeby kursor kopiował kod 128, wpisz SYMBOL AFTER 128:SYMBOL 128,1  :)
PS3.:  A to widziałeś?  (tzn. obrazki pod tym postem)   https://www.speccy.pl/forum/index.php?topic=1363.msg21296#msg21296

« Ostatnia zmiana: 2021.03.10, 01:01:49 wysłana przez ZbyniuR »
- Jeśli masz w domu światło i wodę, tzn. że masz światłowód. ;)

McArti0

  • ***
  • Wiadomości: 113
Odp: Tricki na Amstradzie
« Odpowiedź #89 dnia: 2021.03.10, 13:34:46 »
Nie ogarniam tych czarów.

Te czary dają możliwość napisać kawałek kodu w tablicy integer. i wywołać go call @tablica,akumulator

kod 7B to rozkaz kopiowania rejestru E do A. więc CD czyli call ma przygotowaną zawartość akumulatora zgodną z pierwszym parametrem. np. &C0. Nie podasz 192 parametrów basicowemu CALL, żeby przekazać taką wartość. 8)

PS2.: Żeby kursor kopiował kod 128, wpisz SYMBOL AFTER 128:SYMBOL 128,1  :)

czyli musze najpierw run a dopiero potem list. bo inaczej copy jest z błędem.

PS3.:  A to widziałeś?  (tzn. obrazki pod tym postem)   https://www.speccy.pl/forum/index.php?topic=1363.msg21296#msg21296

Dużo tego. W weekend ogarnę. :)