Procedura scrollująca ekran

[matofesi]

Wracając do Twojego pytania: napisałem procedurę przewijającą linię z adresu zapisanego w HL i kopiującą znikający pixel. Wynik: 27 bajtów.

EDIT: Kolejne 15 minut główkowania i udało się zejść do 20 bajtów!

No to całkiem nieźle

Mnie tak z głowy wyszło 17 Ale stawiam na to, że da się to jeszcze zoptymalizować

Kod: [Zaznacz]

scroll_line
        push hl           ; zapamiętujemy adres początku, żeby potem odtworzyć ostatni bit
        ld b,31           ; długość pętli
        ld a,(hl)         ; pobieramy pierwszy bajt
        rra               ; i najstarszy bit z niego wysuwamy do CY
        inc l             ; przeskakujemy o bajt  a następnie w pętli...
scroll_line1
        ld a,(hl)         ; pobieramy kolejny bajt
        rra               ; przesuwamy bit w prawo równocześnie wsuwając z CY poprzedni
        ld (hl),a         ; odkładamy przesunięty bajt
        inc l             ; przeskakujemy do następnego
        djnz scroll_line1 ; i zamykamy pętlę
        pop hl            ; podnosimy adres pierwszego bajtu - w CY mamy ostatnio wysunięty bit z prawej strony
        ld a,(hl)         ; pobieramy pierwszy bajt
        rra               ; przesuwamy wsuwając z CY zapętlony bit
        ld (hl),a         ; odkładamy
        ret               ; i kończymy

A poza tym to gratulacje dla tych (zwłaszcza początkujących), którym się chciało i mieli czas/zapał U mnie jak często ostatnio zabrakło tych dwóch ostatnich bo chęć miałem

[ZX Freeq]

Jak napisałeś to pochwal się rozwiązaniem.

Przewija o jeden pixel wiersz wskazany przez HL, uciekający pixel kopiuje na początek.
Pierwsza linia LD HL, 16384 wlasciwie do usunięcia, (bo potrzebna mi byla do testów), więc rozwiązanie ma 17 bajtów.
Czy da się zejść niżej z liczbą bajtów?

Pozdro.

[ZX Freeq]

Mnie tak z głowy wyszło 17 Ale stawiam na to, że da się to jeszcze zoptymalizować

  Też mam 17! (czytaj powyżej)

 Niestety moja wiedza co do instrukcji Z80 się kończy, nie wiem jak to bardziej upakować.

[tdu]

No tak, na pewne rzeczy trzeba po prostu wpaść,
cały czas wydawało mi się że ten bit trzeba gdzieś zapamiętać,
ale wygląda na to że najlepszą pamięcią dla niego jest właśnie ekran.

[matofesi]

Też mam 17! (czytaj powyżej)

Ale widzisz jaka była kolejność postów?
Jak pisałem swój to u ciebie było 20

No tak, na pewne rzeczy trzeba po prostu wpaść,
cały czas wydawało mi się że ten bit trzeba gdzieś zapamiętać,
ale wygląda na to że najlepszą pamięcią dla niego jest właśnie ekran.

Nawet nie ekran - czasem trzeba zwrócić uwagę jakie flagi procesora są modyfikowane przez poszczególne rozkazy. CY jest modyfikowane w zasadzie wyłącznie przez przesunięcia i arytmetykę. Proste inc/dec go nie ruszają i czasem jest to bardzo przydatne

edit: A w ogóle to 15

zamiast

Kod: [Zaznacz]

ld a,(hl)
rra
ld (hl),a

można użyć

Kod: [Zaznacz]

rr (hl)


[ZX Freeq]

14 bajtów.

Matofesi, dzięki za podpowiedź z rr (hl).

Kod: [Zaznacz]

;prosta procedura dla tdu
;da sie skrocic na pewno :)
org 32768
init:
;ld hl, 16384 ;ustawmy hl na poczatek odpowiedniego wiersza; linia do usuniecia jesli przed wywolaniem procedury HL jest juz ustawione!!!!
push hl ;odkladamy na stos
ld b, 32 ;ustawiamy b, potrzebne do wykonania petli 32 rqazy
loop1:
rr (hl) ;przesun bajt ekranu w prawo o 1 pixel
inc l ;przejdz do nastepnego bajtu; nie wplywa na flage C
djnz loop1 ;zapetlamy; nie wplywa na flage C
pop hl ;przywroc hl
jr nc, koniec ;jesli pixel "nie wyszedl", konczymy
set 7, (hl) ;zapalamy pierwszy bit
koniec:
ret



[matofesi]

No widzisz... To jeszcze zrób...

Kod: [Zaznacz]

ret nc
set 7,(hl)
ret

I będziesz miał 13

Tylko właśnie zauważyłem, że chyba popełniasz jeden błąd... Przed pierwszym RR (HL) nie masz gwarancji stanu CY, co może powodować, że ci się będzie wsuwać na pierwszy bit coś, co nie powinno się wsuwać. Wymuszenie CY na zero to przynajmniej jeden bajt extra (np. OR A) więc w sumie będzie 14.

[ZX Freeq]

Faktycznie.... 

[matofesi]

Z ciekawości policzyłem sobie też czasy wykonania twojego kodu i mojego. U mnie wychodzi 1055 taktów, a u ciebie 1062 albo 1081 (zależnie od stanu ostatniego bitu) po uwzględnieniu OR A na początku procedury. W krótszym przypadku u ciebie mniej czasu zajmuje to, co poza pętlą, ale dorzuca ci czasu dodatkowy przebieg pętli (dodatkowe 32 takty).

Dochodzi też różnica czasów, która w ekstremalnej sytuacji - gdybyś liczył takty do jakiegoś multicolora albo czegoś w tym stylu - może powodować rozjazd wykonania i trudności z synchronizacją. Choć oczywiście w takiej sytuacji raczej odpuściłbym sobie pętlę i zrobił całość w jednym długim ciągu

[tdu]

No i jaka fajna dyskusja się rozwinęła, i jaka pouczająca.
Parę zdań i można się wiele nauczyć.

Ja bym proponował, stworzenie banku takich prostych procedur
z komentarzami do różnych typowych zastosowań.

[matofesi]

Już to kiedyś dyskutowaliśmy

Wniosek był taki, że ci, którym się chce nie mają zacięcia, żeby tworzyć "bank". Ale jest Wiki więc nie widzę powodu, żebyś nie miał się tym zająć

Ja ze swojej strony chętnie odpowiem na konkretnie postawione - tak jak w tym wypadku - pytanie techniczne, ale składać tego w coś większego na pewno mi się nie będzie chciało

[Phonex]

Bez instrukcji warunkowych, a więc z równym czasem wykonania, można zrobić tak.
Przy okazji: skoro nie zmienia się H, to nie trzeba zapamiętywać pary HL
Długość: 14, czas: 1066 taktów.

Kod: [Zaznacz]

        LD C, L                 ; 4Ts
        XOR A                   ; 4Ts
        LD B, 32                ; 7Ts
L1      RR (HL)                 ; 15Ts
        INC L                   ; 4Ts
        DJNZ L1                 ; 8/13Ts
        LD L, C                 ; 4Ts
        RRA                     ; 4Ts
        OR (HL)                 ; 7Ts
        LD (HL), A              ; 7Ts
        RET                     ; 10Ts


[matofesi]

O. I to jest chyba najładniejsza procedurka. A w każdym razie mnie się najbardziej podoba

A jak u siebie zastąpię push/pop użyciem c to oszczędzam jeszcze 13 taktów

[tdu]

Dziękuje za tyle ciekawych pomysłów i wypowiedzi.
Zastosuje to w moim demie, zobaczę na ile przyśpieszy swoje działanie.