2,701

(14 odpowiedzi, napisanych Programowanie - 16/32bit)

ok.
W necie krąży sporo mitów dot. hardware i kodowania, może to być jeden z nich.

tak na szybko widzę że ustawiasz i Video Base oraz Video Counter. Ja tylko modyfikuję Video Counter.

2,702

(14 odpowiedzi, napisanych Programowanie - 16/32bit)

hmm, no może.
Z tym że o tym HBLu czytałem w jakiejś dokumentacji.

a oto dalszy ciąg kodu:

scrn_poi:
    REPT    2
        nop
    ENDR

    lea        Licznik_Ekranu1+1,A0            ; ustaw nowy adres ekranu
    move.b    (A0)+,$FFFF8205.w
    move.b    (A0)+,$FFFF8207.w
    move.b    (A0)+,$FFFF8209.w

2,703

(14 odpowiedzi, napisanych Programowanie - 16/32bit)

Maciek, gdy z kodu usunę "    STOP    #$2300 ; wait for 1st HBL" przesuwanie ekranu traci stabilność - co jakiś czas ekran skacze. Czyli w moim przypadku zmiana $FFFF8265 od razu w VBLu nie działa prawidłowo.
W wolnej chwili mogę sprawdzić czy ze zmianą $FFFF8265 trzeba czekać do HBLa (512 cykli) czy można wcześniej jej dokonać

2,704

(14 odpowiedzi, napisanych Programowanie - 16/32bit)

obaj macie rację :)

w moim teście zmieniam $FFFF8265 po pierwszym HBLu a $FFFF820F modyfikuję o 8 bajtów ( -8 bajtów dla hscroll==0) i działa to ok

Petla_VBL
    STOP    #$2300 ; wait for 1st HBL
    move.w    #$2500,SR
    addq    #1,D2
    cmp.w    #576,D2
    blt.b    .skip
        moveq    #0,D2
.skip
    moveq    #0,D5
    move.l    D2,D3
    and.b    #$0F,D3
    move.b    D3,$FFFF8265.w
    bne.s     fix_line
        move.l    Adres_Ekranu,Licznik_Ekranu1
        move.b    #224-80,$FFFF820F.w     ; x-words
        move.l    D2,D3
        and.w    #$FFF0,D3
        lsr.l    #1,D3
        add.l    D3,Licznik_Ekranu1
        bra.s     scrn_poi
fix_line:
    move.b    #224-80-4,$FFFF820F.w
scrn_poi:

2,705

(1,653 odpowiedzi, napisanych Bałagan)

skrzyp napisał/a:
Cyprian napisał/a:

obeszłe

Kolega Cyprian zgłosi się na najbliższym party… :)

wiesz, poszłem i obeszłem :)

2,706

(1,653 odpowiedzi, napisanych Bałagan)

obeszłe

2,707

(22 odpowiedzi, napisanych Bałagan)

słuszna numeracja
Atari 666XL i Atari 666ST

2,708

(22 odpowiedzi, napisanych Bałagan)

ta jest :)

2,709

(69 odpowiedzi, napisanych Sprzęt - 8bit)

800XL i 1029 - zestaw marzeń :)

2,710

(22 odpowiedzi, napisanych Bałagan)

były tam głównie 800XL i 1050. potem na jakiś czas pojawiły się dwa Amstrady 464 i 646. a coś koło 90' 286
Chodziłem tam na kurs Atari Basic. Pamiętam że było tam dwóch magików piszących w assemblerze, dzięki jednemu z nich sam zacząłem "kodować".
Do tej pory mam oryginalną dyskietkę QuickAssemblera.

2,711

(22 odpowiedzi, napisanych Bałagan)

w tym samym klubie, parę lat wcześniej zaczęła się moja przygoda z Atari
https://www.youtube.com/watch?v=NaVs3Iurfq8

2,712

(9 odpowiedzi, napisanych Programowanie - 16/32bit)

EOR to XOR?
"source XOR destination" zabiera trzy cykle szyny (odczyt źródła, odczyt celu, zapis celu) - 12 cykli procesora

2,713

(9 odpowiedzi, napisanych Programowanie - 16/32bit)

Tomasz Wachowiak napisał/a:

Jeśli chodzi o wstawianie instrukcji w czasie działania blittera, to chyba zadziała to tylko w przypadku trybu BLIT, czyli trybu dzielonego

Działa w każdym wariancie - BLIT i HOG. Kwestia jest tylko w tym, by wystartować BLiTTERa instrukcją typu "Class 0", np BSET, ASL, ADD itp: http://pasti.fxatari.com/68kdocs/68kPrefetch.html
A tutaj mój mały przykład:
http://www.atari-forum.com/viewtopic.php?p=96197#p96197

Tomasz Wachowiak napisał/a:

No ciekawe, jak wypadłby blitter w 4 planowym fillerze, ale zaczynam odnosić wrażenie, że mógłby być wolniejszy od motorli (jak sobie spojrzycie na 4 bitplanowego fillera z kilku tematów wstecz, to do wypełniania używam tam movemów i przy długich liniach robię bodajże 64 piksele na jednym movie - to może być już dla blittera za dużo).

myślę że warto by to sprawdzić w praktyce. Z tego co widzę w w przypadku wariantu CPU i MOVEMów dla każdej linii dokonujesz jeszcze fline_m i lline_m które są dość kosztowne.

2,714

(0 odpowiedzi, napisanych Bałagan)

http://kotaku.com/atari-engineer-steve- … 1687628442

2,715

(9 odpowiedzi, napisanych Programowanie - 16/32bit)

mkm napisał/a:

Mógłbyś teoretycznie zrobić wersje mieszaną wywołującą kod cpu lub blitter'a w zależności od długości linii. Oczywiście taki warunek to dodatkowy koszt

Wachu zrobił już detekcję w kodzie, są to procedury "line0_XXX" :)  Wystarczy dla odpowiednio długich podmienić kod z CPU na BLiTTERa.

Myślę że dla cztero-bitplanowego fillera proporcje mogą ulec zmianie.
Jest jeszcze jedna niewykorzystana tutaj zaleta BLiTTERa. W czasie blittingu, CPU może wykonać jedną "długą" instrukcję, np rotacje, mnożenie/dzielenie itp. Z tego co widzę w kodzie, na każdy trójkąt przypadają trzy DIVSy. Być może dało by się je sprytnie przesunąć pod blitting.

2,716

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

Tomasz Wachowiak napisał/a:

P.S. Piękny kod swoją drogą, wszystko z minimalną ilością cykli. :)

a dzięki :)

Bober napisał/a:

Ostatnio odbył się kompot z produkcjami na 1bitplan (na ST). Może będzie kolejny. Wtedy z 1bitplanowym fillerem będziecie do przodu :).

ten filler można zastosować również do wielu bitplanów

2,717

(110 odpowiedzi, napisanych Software, Gry - 16/32bit)

jury napisał/a:

Jest tylko uwaga, jak dobrze pamiętam, nie jesteś fanem grania w małych okienkach, a to jest rozdzielczość 160x80, czyli przy najmniejszej rozdzielczości Falcona to jest okienko wielkości 1/4 ekranu. Więc DML zastosował tu chwyt marketingowy ;)

to patrz (i słuchaj) teraz https://www.youtube.com/watch?v=hDXSMgW-r5M
:)

2,718

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

i jeszcze coś mi wpadło do głowy. Czy faktycznie poniższa instrukcja jest potrzebna?

   move.w    d5,d3  ;4

"addq.w    #1,d3  ;4" robisz w obrębie Word a nie Long

2,719

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

w międzyczasie wyedytowałem posta:
przemyślałem to jeszcze raz,  w wariancie xCount = 1 może być problem z zastosowaniem EndMask

2,720

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

no tak, ale możesz dać albo:

  xCount = 40 / yCount = 1

albo:

  xCount = 1 / yCount = 40

z tego co pamiętam efekt jest ten sam operacja dokonywana jest na tych samych 40stu słowach.
Oczywiście w zależności od wariantu trzeba odpowiednio ustawić Destination X/Y increment.

---edycja---

przemyślałem to jeszcze raz,  w wariancie xCount = 1 może być problem z zastosowaniem EndMask

2,721

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

faktycznie masz rację z yCount. 
Ale możesz zamienić xCount z yCount (czyli również Destination X increment oraz Destination y increment) dzięki temu xCount będzie tylko raz inicjowany a yCount przed każdym blitem.
Takie rozwiązanie zastosowałem w mojej procedurze dla sprajtów:

;BLiTTER Init
    move.l    #$00020002,(A0)+        ; source X increment / source Y increment
    move.l    A2,(A0)+            ; source address
    move.l    #-1,(A0)+            ; mask 1 /2
    move.w    #-1,(A0)+            ; mask 3
    move.l    #$00080080,(A0)+        ; destination X increment / destination Y increment
    lea        2(A0),A4            ; remember source destination
    move.l    A3,(A0)+            ; destination address
    move.w    #$0005,(A0)+        ; count X surface
    movea.l    A0,A1                ; remember count Y surface
    move.w    D0,(A0)+            ; count Y surface
    move.w    #$0204,(A0)+        ; HOP / LOP
    move.w    D4,(A0)                ; BUSY / HOG / SMUDGE / LINE NUMBER // FXSR / NFSR / SKEW


; Copy MaskSprite to Screen
    move.b    D2,(A0)                ; start blitter

    REPT    3
        lea        2(A3),A3
        move.w    A3,(A4)            ; destination address
        move.w    D0,(A1)            ; count Y surface
        move.b    D2,(A0)            ; start blitter
    ENDR

;
;BLITTER RE-INIT Sprite to Screen
    lea        $FFFF8A3C.w,A0
    move.l    A5,A3
    move.w    #$0207,$FFFF8A3A.w        ; HOP / LOP

; Copy Sprite to Screen
    move.w    A3,(A4)                ; destination address
    move.w    D0,(A1)                ; count Y surface
    move.b    D2,(A0)                ; start blitter

    REPT    3
        lea        2(A3),A3
        move.w    A3,(A4)            ; destination address
        move.w    D0,(A1)            ; count Y surface
        move.b    D2,(A0)            ; start blitter
    ENDR

2,722

(22 odpowiedzi, napisanych Programowanie - 16/32bit)

z tego co widzę to masz parę rejestrów adresowych wolnych.
tak więc, tutaj mógłbyś przypisać każdej masce osobny An i zejść z 24 do 16 cykli:

                    move.w    d0,endmsk1(a6)        ;first line mask
                    move.w    d1,endmsk3(a6)        ;last line mask

tutaj również dedykowany An, dodatkowo nie ma potrzeby zmiany yCount, więc zamiast Longa możesz zapisać Word:

                    move.l    d3,xCount(a6)        ;xcount = d3, ycount = 1 at once

czyli zamiast 16 mamy 8 cykli

tu również dedykowany An:

                    move.b    #$a0,lineNum(a6); HOG   16

zamiast 16 mamy 12 cykle


Czyli z 82 cykli inicjalizacji mógłbyś zejść do 62.

2,723

(57 odpowiedzi, napisanych Scena - 16/32bit)

dyskietki od nastu lat leżą gdzieś na strychu. muszę odszukać pudło, potem przeczesać każdą dyskietkę. robota na cały weekend...

2,724

(51 odpowiedzi, napisanych Scena - 16/32bit)

Tomasz Wachowiak napisał/a:

Może gouraud pod mono? Chyba jeszcze nikt tego nie zrobił? :P Kiedyś napisałem sobie na PieCa całkiem fajną procedurę do ditheringu. Można by ją przenieść na mono STeka. :)

w Mono? Brzmi ciekawie.
Ditherowany gouraud widziałem tylko w ST-LOW w demie: http://www.pouet.net/prod.php?which=19628 i w grze Interphase: https://www.youtube.com/watch?v=DtUfQEp … lpage#t=16

To pierwsze zrobił Martin Griffiths, źródła są dostępne w sieci. Jakby co to je mam.

2,725

(3 odpowiedzi, napisanych Programowanie - 16/32bit)

tak, tak na szybko pod emu. Wieczorem będę miał więcej czasu i sprawdzę na realnym sprzęcie.
Co do blittera to słuszny kierunek.

---edycja---

działa.
ok, wiem gdzie leżał problem, popierdzielił mi się pecetowy "caps lock" z STkowym "ctrl", są one w tym samym miejscu klawiatury...