Proste i przyjemne procedurki asemblerowe dla początkujących

[ZbyniuR]

No dobra koledzy, udam że zrozumiałem. Skrócenie wykonania o prawie 1/4 to suuuper, a o ile się wydłużył kod?

Tylko chciałbym wiedzieć ile bajtów zajmują te wersje. I czy ilość przesyłanych bajtów koniecznie musi być wielokrotnością liczby 32 ? - Bo jeśli tak to mi się nie przyda. Czy ja coś źle zrozumiałem? Wolałbym wielokrotność 10 albo 20, czy to tylko zależy od ilości LDI w pętli?

I inna kwestia, kojarzę że są rozkazy które pobierają lub zapisują w pamięci po dwa bajty na raz. Czy użycie ich zamiast LDI nie byłoby szybsze?

[Phonex]

PE tu jedynie zaciemnia obraz, no i przede wszystkim nie spełnia swojego zadania.

Haha, no tak.
U mnie powinno być LD BC, ilość, a nie LD BC, ilość/32. Poprawiłem.
A u RafalM - LD BC, x*32 (wielokrotność 32)

Teraz działa.
I jest szybsza, bo nie ma DEC A w każdej pętli. Czyli zysk (N*4)-6 taktów w stosunku do wersji Tygrysa.

@ZbyniuR: tak to tylko zależy od ilości LDI w pętli. Rozkaz LDI zajmuje 2 bajty. Procedura będzie dłuższa o tyle ile LDI wpiszesz w pętli. A im więcej LDI w pętli tym szybciej działa.

[Sir David]

Kod: [Zaznacz]

ld hl,skad  ; 10
ld de,dokad ; 10
ld b,ile/32 ; 7

petla:
rept 32
  ldi       ; 16
endm
djnz petla  ; 13/8
To jest dosyć ryzykowny kod bo LDI zmienia (zmniejsza) również parę rejestrów BC. Jak C przejdzie przez 0 to zmniejszy się B i pętla wykona się złą ilość razy. Nigdzie nie ustawiasz C więc to tak naprawdę będzie losowa sprawa.

Ja dokładnie tak robię, ustawiając dodatkowo 0 w C i dodając do B tyle, ile razy C będzie przechodzić przez zero.

[Tygrys]

O, z odpowiednim ustawieniem BC to ma sens

Motyw z PE to widziałem że gasman jakiś czas temu 'sprzedał' na WoS.

[RafalM]

A u RafalM - LD BC, x*32 (wielokrotność 32)

Oczywiście, mój błąd.

[Phonex]

To jak jesteśmy rozgrzani - kto napisze najkrótszą procedurę czyszczenia ekranu w Spectrum?
Kiedy nieważna szybkość, a naprawdę jest bardzo mało miejsca.
Nie używając procedur z ROM.

[Tygrys]

w No Skulls mam coś takiego:

Kod: [Zaznacz]

        xor a ; 1b
ld hl,$5B00 ; 3b
cls_loop:
dec hl ; 1b
ld (hl),a ; 1b
cp (hl) ; 1b
jr z,cls_loop ; 2b

Zakłada istnienie ROM poniżej adresu VRAM.

[Phonex]

Drugi fajny patent jednego dnia!
We have a winner!

Ja znalazłem dłuższą (o 1 bajt)

Kod: [Zaznacz]

   ld hl, $5AFF
loop
   ld (hl),0
   dec hl
   bit 6,h
   jr nz,loop


[pear]

To ja z innej beczki.
Mnożenie dwóch liczb całkowitych 16-bitowych.
Mnożna: BC
Mnożnik: DE
Wynik 32-bity: HL, DE
Oryginał pisałem na 8051, ale na Z80 wyszło znacznie zgrabniej

Kod: [Zaznacz]

MUL16   ld  a,16
        ld  hl,0
ML1600  or  a        ;zerowanie CY
        bit 0,e
        jr  z,ML1601
        add hl,bc
ML1601  rr  h        ;w CY przeniesienie z ostatniego dodawania
        rr  l
        rr  d
        rr  e
        dec a
        jr  nz,ML1600


[pear]

Do kompletu dzielenie liczby 32-bitowej przez 16-bitową bez znaku.
Dzielna 32-bity: HL, DE
Dzielnik 16-bitów: BC (nie może być 0 !)
Wynik 16-bitów: DE
Podobnie jak poprzednio oryginał był pisany na 8051, więc proszę mi wybaczyć to EX AF,AF', ale mi rejestrów zabrakło

Kod: [Zaznacz]

DIV32   ld  a,17
DV3200  ex  af,af'
        ld  a,h
        cp  b
        jr  nz,DV3201   
        ld  a,l
        cp  c
        jr  nz,DV3201
DV3201  jr  c,DV3202
        sbc    hl,bc
DV3202  ccf
        rl  e
        rl  d
        rl  l
        rl  h
        ex  af,af'
        dec a
        jr  nz,DV3200
        ret


[sect0r]

Zakłada istnienie ROM poniżej adresu VRAM.

Możecie rozjaśnić Jak dla mnie to ROM zawsze jest od 0 do 16383, VRAM 16384 do 22527/23295

EDIT, chodzi o to, żę jak będzie ROM, to CP(HL) nie ustawi wyzeruje znacznika Z , bo LD (HL),A zera nam w ROM nie wpisze ?

Ale to ciężko zatrybić od razu dla kogoś kto się dopiero uczy. No ale jak zobaczyłem, że czyści ekran od końca, to już sprawa się wyjaśniła.

[Tygrys]

Zakłada istnienie ROM poniżej adresu VRAM.

EDIT, chodzi o to, żę jak będzie ROM, to CP(HL) nie ustawi znacznika Z , bo LD (HL),A zera nam w ROM nie wpisze ?

Procedura działa dopóki, doputy zapisywana wartość jest taka sama jak w A.
ROM nie jest zapisywalny, a do tego pod jego sam koniec ma wartości 255. Sprawdzenie warunku CP (HL) da wynik 'NZ', a przez to wyjdzie z pętli.

[trojacek]

Zakłada istnienie ROM poniżej adresu VRAM.

"VRAM" - ależ to brzmi dumnie
Ten skrót oznaczał tak naprawdę pamięci dwuportowe (dual-port RAM), które pozwalały na jednoczesny odczyt i zapis do pamięci (z reguły zapis był równoległy, odczyt - szeregowy). Czyli VRAM był z definicji szybszy, niż DRAM.
A w ZX48 - jakby odwrotnie...

[RafalM]

Zakłada istnienie ROM poniżej adresu VRAM.

W życiu nie słyszałem tego określenia ale zrozumiałem to jako video ram czyli pamięć ekranu.

A co do ROMu pod adresami 0-16383, cóż zwykle tam jest ale niekoniecznie.

Modele +2A i +3 pozwalały na takie  stronicowanie że pod te adresy można było podpiąć RAM. Zwykły Zx 128 tego nie ma, nie mówiąc o Zx48 który w ogóle nie ma stronicowania i tam ROM jest zawsze na miejscu

Można natomiast coś zakombinować sprzętowo. Wyszła taka jedna, jedyna gra Shadow of The Unicorn (http://www.worldofspectrum.org/infoseekid.cgi?id=0004424) która była sprzedawana razem z jakimś interfejsem który jak rozumiem podmieniał dolne 16 kB na swoje dane.

No a w przypadku jakichś klonów jest tak jak kto zrobi.

[trojacek]

http://pl.wikipedia.org/wiki/VRAM

Polecam ostatnie zdanie