276

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

@jok gratulacje, ładna grafika

Problem rozwiązany.
Nie wiem czy kogoś to zainteresuje... ale może komuś się kiedyś przyda więc wyjaśnienie poniżej:

Procedura startu i szybszego restartu blitter'a na podanej przeze mnie stronie zdaje się nie być prawidłowa. Po przejściu przez "bliblię blitter'a" by Paradox (http://paradox.atari.org/files/BLIT_FAQ.TXT) doszedłem do wniosku, że aby poprawnie ubsługiwać tryb BLiT pętla zamiast:

            ; set blitter active
            moveq.l    #7,d0
_blit1  bset.b  d0,(a0)
            nop
            bne.s   _blit1            
            ; wait blitter done

musi wyglądać

            ; set blitter active
            moveq.l    #7,d0
            bset.b  d0,(a0)
_blit1  bset.b  d0,(a0)
            nop
            bne.s   _blit1            
            ; wait blitter done

Pierwszy bset startuje blitter i w przypadku trybu BLiT po 64 cyklach dostęp do szyny wraca do CPU i zaczyna ono wykonywać kolejne instrukcje. Wtedy drugi bset będzie probować ustawić wartość jeszcze raz. Jeśli blitter ma jeszcze coś do zrobienia to wartość pola nie zmieni się i flaga Z będzie wyzerowana, więc pętla wykona się wracając do bset'a powodując szybszy restart blitter'a niż pełne 64 cykli. Jeśli jednak w tym czasie trafi się przerwanie to przejmie ono CPU i szyne w miejscu nop'a.
Przed poprawką bset był wykonywany jednokrotnie, więc wartość startowa bitu 7 zawszę wynosiła w pierwszej iteracji 0 (blitter inactive) czyli flaga Z była zawsze ustawiana. Przez co pętla nigdy się nie wykonywała. Oczywiście operacje wykonywane przez blitter były wykonywane - ale na przemian z kolejnymi instrukcjami kodu, więc jeśli dalej następował kod cpu rekonfigurujący blitter to efekt był taki jak w pierwszym poście. Takie przynajmniej jest moje zrozumiene. Na emulatorach zaczęło to działać poprawnie, na testy na real STE nie miałem czasu.

PS. Oczywiście w trybie HOG wszystko działało, ale wtedy to można zapomnieć o pogodzeniu tego z muzyką używającą timer'ów.

Mam dziwny problem z blitter'em, gdy chce wykonać po sobie 2 długie operacje w trybie BLiT. Czyli "wpuszczam" CPU dla przerwań, ale stosuję trick z szybszym restart'em blitter'a.
Mam taki test case:
1) rysuje sobie pół ekranu (cpu) na 4 bitplanach -> mam ekran wypełniony kolor'em 15
2) czyszczę blitter'em bitplan 1
3) czyszczę blitter'em bitplan 2

jako efekt powinienem mieć więć ekran wypełniony kolorem 12 (przecięcie planów 3 i 4).
i teraz jeśli zmodyfikuje kod do tylko jednej z wywołań blitter'a to wszystko jest ok.
mam wtedy ekrany wypełniony odpowiednio kolor'em 13 lub 14 (przecięcia odpowiednich 3 bitplanów) - czyli każda procka używająca blitter z osobna działa ok. Jeśli mam je obie oczywiście coś się wali...

Sam kod wzorowałem na http://s390174849.online.de/ray.tscc.de/blitter.htm

i wygląda on:

blitCleanPlane1:
            ; *** plane 1 clr ***
            ; end masks
            lea.l   BLT_ENDMASK1.w,a0
            moveq.l    #-1,d0
            move.l  d0,(a0)+
            move.w  d0,(a0)+

            ; dest xInc & dest yInc
            move.l  #$00080000,(a0)+

            movea.l    scr1,a1
            ; dest address
            move.l  a1,(a0)+

            ; xCount+1 & yCount
            move.l  #$00290064,(a0)+
            ; HOP & OP
            move.w  #$0200,(a0)+

            ; no HOG
            clr.w   (a0)

            ; set blitter active
            moveq.l    #7,d0
_blit1        bset.b  d0,(a0)
            nop
            bne.s   _blit1            
            ; wait blitter done

            rts

blitCleanPlane2:
            ; *** plane 2 clr ***
            ; end masks
            lea.l   BLT_ENDMASK1.w,a0
            moveq.l    #-1,d0
            move.l  d0,(a0)+
            move.w  d0,(a0)+

            ; dest xInc & dest yInc
            move.l  #$00080000,(a0)+

            movea.l    scr1,a1
            ; plane 2 shift
            add.l    #2,a1
            ; dest address
            move.l  a1,(a0)+

            ; xCount+1 & yCount
            move.l  #$00290064,(a0)+
            ; HOP & OP
            move.w  #$0200,(a0)+

            ; no HOG
            clr.w   (a0)

            ; set blitter active
            moveq.l    #7,d0
_blit2        bset.b  d0,(a0)
            nop
            bne.s   _blit2            

            rts


BLT_SRC_X_INC    equ    $ffff8a20
BLT_ENDMASK1    equ $ffff8a28
BLT_DEST_X_INC    equ $ffff8a2e

Mam wrażenie, że mimo wszystko pętla restartująca blitter do końca zadania coś wariuje w takich sytuacjach, albo coś zle robie. Efekt przynajmniej jest taki, ze mam kilka wierszy faktycznie wyczyszczone oba bitplany, a pózniej tylko bitplan 2 - który teoretycznie czyszcze później wiec jakby druga procedura przerwała działanie pierwszej zanim ona skończy (mimo pętli czekającej na jej koniec)

Efekt podobny i na Steem i Hatari (na STE mogę dopiero sprawdzić w weekend). Jakieś pomysły?


PS. ustawinia endmask sa zbedne, ale nevermind to nie ma znaczenia...

279

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

Super, podoba mi się:)

280

(6,129 odpowiedzi, napisanych Kolekcjonowanie)

Atari Stacy: http://www.ebay.co.uk/itm/ATARI-STACY-2 … 43c8f9ef0f

281

(10 odpowiedzi, napisanych Sprzęt - 16/32bit)

Nice:) Wrzuć jeszcze fotkę gdzie widać i TT i monitor na raz w pełnej okazałości. Ahh, ja też chcę TT;)

282

(69 odpowiedzi, napisanych Fabryka - 16/32bit)

Dzięki, to już kumam jak to jest z Mist'em i HDD. Czekam więc na wyniki testów wydajności. I coraz bardziej intensywnie myślę o tym czy sobie takiego prezentu nie sprawić:)

283

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

To skoro była już mowa o maxYMiser vs musicmon oraz o timer'ach, które są używane do tworzenia dodatkowych brzmień i efektów to jak mam pytanko do kolegów muzyków.
MaxYMiser z tego co wiem umożliwia zdefiniowanie które timer'y zostaną użyte podczas grania muzyki, a które zostaną wyłączone (i zostawione wolne dla kodera gry czy dema - przy prawdopodobnie mniejszej stabilności ale zawsze) - skutek jest taki, że na którymś kanale znikają nam efekty dodatkowe i mamy czyste brzmienie YM.
Czy MusicMon też coś takiego umożliwia? Czy muzyk w nim piszący może np zagwarantować, że np Timer B będzie wolny?

284

(69 odpowiedzi, napisanych Fabryka - 16/32bit)

@marekp
Czyli rozumiem, że właśnie STEroids jest tym "dopalonym" trybem z szybkim CPU, tak?
Mam jeszcze parę pytań. Pisałeś o HDD czyli rozumiem, że MIST ma taką obsługę. Jak to wygląda w praktyce? Masz widoczną jako HDD cała kartę SD (FAT?) jako filesystem. Czy podpinasz jakiś plik z obrazem dysku, który jest na karcie SD?

Czy skoro mamy de facto szybką maszynę to można by na tym postawić MiNT'a?

285

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

stRing napisał/a:

Dlaczego MusicMon nie wczytuje plików SND, mimo że ma taką możliwość? SNG idzie normalnie.
Maxymiser też ma problem z wieloma plikami SND (np kilkoma z SV 2k13)
Jakiego formatu się trzymać?

SNDH to chyba nie jest format a jedynie koperta na song plus embedded player do niego. Tak więc pliki SND generowane przez różne trackery nie będą czytelne dla innych. Koperta umożliwia za to ustandaryzowane odgrywanie przez playery czy z poziomu kodu.

286

(69 odpowiedzi, napisanych Fabryka - 16/32bit)

Gdzieś chyba czytałem, że autor eksperymentował z core'em w którym jest znacznie szybsze CPU (dodał chyba cache'e i podkręcił zegar, nie pamiętam i nie mogę teraz tego znaleźć) i osiągał wyniki niewiele wolniejsze od TT. Miałeś okazję testować taki wsad? i czy w ogóle został on faktycznie wydany?

287

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

YERZMYEY/HOOY-PROGRAM napisał/a:

> Lamers (Maciekm)
----------------------
Kurczę, nie mogę sprawdzić porządnie, bo zawiesiło mi się. Może nie chodzi na emulu.
Jak podłączę sprzęt, to sprawdzę.

Z tego co pamiętam to chodziło na Hatari jak i na moim STE. Ale ale, tytuł tej "produkcji" mówi wszystko, więc...... poczekajmy poczekajmy:)

288

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

A to świetna wiadomość - jedna z moich ulubionych gier... a poza tym jedyna gierka, do grania w którą udaję mi się czasem namówić moją żonę;)
Jedno pytanko - czy ta wersja odpala się z HDD? (po zgraniu zawartości obrazu)

289

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

No właśnie tak mi się wydawało, że widziałem FireBee u jednego z zagranicznych gości. Ale gdy miałem później  się zainteresować to już go nie znalazłem;)

290

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

Adam Klobukowski napisał/a:

Planuję zakup.

To może byś się dał namówić na prezentacje nowego zakupu na SV? Myślę, że wiele osób chętnie by zobaczyło to cacko w akcji:)

291

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

Trochę offtopic'owo... ktoś z forumowiczów posiada FireBee? Chętnie bym posłuchał/poczytał jak to się sprawuje. Sam pewnie i tak nie kupię, ze względu na cenę - więc pytam z czystej ciekawości.

292

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

działa - thanks. w sumie fajna sprawa przy unrollowaniu loop'ów, które zawierają skoki. dotychczas męczyłem się z copy/paste;)

293

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

dzięki. nie znałem tego tricku z \@. jutro sprawdzę czy działa, ale wygląda sensownie:)

294

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

Powiedzmy, że mam blok rept/endr... coś takiego działa (podmieniając offset w move):

.q         set    0
            rept 10
            move.b    #123,.q(a0)
.q         set    .q+16            
            endr

Ale powiedzmy, że chcę wygenerować skok wewnątrz klonowanego kodu - coś ala (co niestety nie działa):

.q         set    0
            rept 10
            ; ................
            tst.w    d0
            ble.s    _foo.q
            ; ...... some code
_foo.q            
.q         set    .q+16            
            endr

czyli chciałbym w kolejnych iteracjach etykieta _foo była wygenerowana z innym indeksem (_foo0, _foo16 itd).
da się to zrobić? oczywiście mogę to obejść jmp *+4 (czy ileś tam) ale wolałbym nie;)

Rewelacja !!! Już nie mogę się doczekać :)

296

(13 odpowiedzi, napisanych Sprzęt - 16/32bit)

Możesz już po zbootowaniu "podmontować" resztę partycji. Klikasz na tą partycję którą masz i pózniej do górnego menu w TOS'ie -> Options -> Install Disk Drive (różnie chyba zależnie od wersji TOSa się to nazywa). Po takiej operacji widzisz inną partycję.

http://www.ppa.pl/forum/amiga/29460/motorola-68000

Panowie, nie idźcie tą drogą;)

298

(3 odpowiedzi, napisanych Bałagan)

Zobacz też Bohemian Rapsody / Queen zrobione przez tego samego gościa: http://www.youtube.com/watch?v=Ht96HJ01SE4
I jest Atari:)

299

(294 odpowiedzi, napisanych Bałagan)

Jak dla mnie, w ogóle dyskusja w kontekście "działu" na forum, gdzie waga całej sytuacji to co najwyżej ominięcie paru wiadomości, które nas nie interesują jest co najmniej śmieszne. Wystarczy tylko odrobina dobrej woli i po problemie;)

Inna sprawa to compos etc. Tutaj chyba sytuacja także dzięki Rapidusowi ulegnie poprawie. Na potrzeby normalnego compo Rapidus ma w sobie 6502 (z tego co zrozumiałem) - i wszystko odbywa się w iście 8-bitowych warunkach. A potem... wystarczy jeden przełącznik oraz nowa kategoria 65816 + 16MB + VBXE - i mamy zrywające berety z głowy kosmosy na ekranie:)

@ming co do godzin postow: http://www.atari.org.pl/forum/viewtopic.php?id=9674 ;)