Valamit megnézhetnétek igazi EP-n. Van az Orkdemo3 és abban a DEMO3H.DAT, ami a valahányadik rész indítója. Na ebbe raktam bele asszem egy LPT trükköt, ami azt csinálja hogy a szöveg felső pár pixeljét eltolja pixelenként. Emu alatt sajna nem műxik, de gyanítom, hogy minden tévével se.
Nem tudom már mit csinál ez a trükk, de az biztos hogy csak véletlen jöttem rá ahogy próbálgattam az LPT értékeket.

Képet hogy tudunk konvertálni a scroll-rutinhoz?

epimgconv (232 karakter x 200 sor méretű kimeneti file, 16 színű PIXEL formátumban, fix palettával), és aztán egy rövid C programmal konvertáltam a scroll.bin file-t. Ennek a formátuma:
- keret szín (1 byte)
- FIXBIAS * 8 (1 byte)
- paletta (8 byte)
- a 464 byte oszlop, az egyes oszlopok felülről lefelé (200 byte), és aztán balról jobbra

Úgy fest 50Hz mellett a byte-onkénti scroll is jó, lehet 25 Hz-en se látszik darabosnak.

Elsősorban a sebesség számít, a 25 fps még elfogadható (nem darabos), de byte-onként túl gyors lehet a scroll. A 12.5 fps-es byte-onkénti scroll pedig már kissé darabos a 12.5 fps miatt.

Elsősorban a sebesség számít, a 25 fps még elfogadható (nem darabos), de byte-onként túl gyors lehet a scroll. A 12.5 fps-es byte-onkénti scroll pedig már kissé darabos a 12.5 fps miatt.

és tényleg , a képkimozfató cuccomban karakterenként mozgatok ki, és mégse darabos

Csak érdekességként, a fenti scroll.com programban így történik a belépő oszlopok feltöltése (ez egy sor mindkét képernyő pufferbe):
       pop     bc
        ld      l, c
        ld      a, b
        ld      (de), a
        set     6, d
        and     55h
        rla
        or      (hl)
        ld      (de), a
        ex      de, hl
        ld      bc, 0c000h + 80
        add     hl, bc
        ex      de, hl

Az SP egy átmeneti pufferre mutat, amely két egymás melletti oszlopot tartalmaz (jobbról balra és felülről lefelé), a H pedig egy táblázat címének a felső byte-ja az egy pixel eltoláshoz. A DE a video memória cím, a 2. lapon található az egyik képernyő puffer, a 3. lapon pedig az egy pixellel balra eltolt verzió.

Az átmeneti puffer feltöltése így történik (két byte egy oszlopban):
       pop     de
        ld      (hl), e
        set     1, l
        ld      (hl), d
        inc     l
        inc     l
Ez a kód négyszer van "kiírva" a ciklusban, és az utolsó két INC L helyett INC HL-t használ (16 byte-os határra igazított puffert feltételezve). Az SP a kép adatra (scroll.bin tartalma) mutat, a HL pedig az átmeneti pufferre. A másolás pazarol némi CPU időt, és lehetne optimalizáni (pl. felváltva az egyik képkockában másolni, a másikban pedig rajzolni, így egyenletesebb és a legrosszabb esetben alacsonyabb lenne a CPU használat), bár a rajzoló ckilus (fent) CPU igénye nagyobb.

A pufferbe miért hagyod ki minden páratlan bájtot?
Ott még végzel minden egyes bájton egy eltolást, és oda csordul a kitolt bit?

Ja,a BC'-t használod, mert ha nem, akkor még azzal lehetne gyorsítani, hogy BC'-nek értéket adsz az oszlopkiírás előtt, nem?

EXX
LD BC,0c000h+80h
EXX

A BC' nem lenne jó, mert akkor nem tudom a DE-hez hozzáadni. Viszont van egy másik lehetőség a gyorsításra:

Code: [Select]

       ld      bc, 0c000h + 80
        ...
        pop     hl
        ld      a, h
        ld      h, high scrollTable
        ld      (de), a
        set     6, d
        and     55h
        rla
        or      (hl)
        ld      (de), a
        ex      de, hl
        add     hl, bc
        ex      de, hl

bocs, tényleg