Przejdź do treści forum
atari.area
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Bibuła - nowa gra na Atari ST Polska w stanie wojennym i podziemna prasa. Klasyczna przygodówka point and click na Atari ST.
Aktualizacja firmware A8PicoCart Nowe wydanie oprogramowania dla taniego kartridża A8PicoCart z obsługą kolejnych typów cartów.
THE 800XL osiągnął status Gold! Zakończono prace nad oprogramowaniem dla THE800XL. Retro Games Ltd rozpoczyna etap produkcji.
PiST 0.11.0 Środowisko programistyczne PiST dla Atari ST doczekało się nowej wersji 0.11.0.
bm800xl 0.5.9 Emulator bm800xl dla Raspberry Pi zyskał szybszy start, scanlines i pełne stany pamięci.
Opcje wyszukiwania (Strona 114 z 196)
Tomasz Wachowiak napisał/a:Dziwne. Trochę zmieniłem includy, więc jeśli wrzuciłeś tylko fillera do katalogu z poprzedniej wersji, to może rzeczywiście coś nie zadziałać. Wrzucę PRG, sprawdź, czy będziesz widział trójkąt.
Twój PRG działa ok. Devpac kompiluje również ok. PRG z VASMa coś nie działa. Jeszcze to sprawdzę i jakby co to zgłoszę problem do Franka Wille
Osobiście dla mnie to jest ok.
Problem z forum AA jest taki że osoba niezalogowana nie pobierze pliku. Czyli ograniczamy się tutaj do garstki osób z PL.
--edycja--
widzę tylko szary ekran
Fajny kod, może da się jeszcze jakoś zoptymalizować.
Miałbym jedną prośbę aby dodać "endif" w pliku ste_blit.s w MACRO "sblit macro".
Teraz za każdym razem gdy kompiluję Twoje testy muszę robić to ręcznie :)
stryker napisał/a:pamiętacie ? ;>
pamiętamy,
% wysłany
no cacy.
maskownica będzie wyzwaniem
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.
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
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ć
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:
wiesz, poszłem i obeszłem :)
słuszna numeracja
Atari 666XL i Atari 666ST
800XL i 1029 - zestaw marzeń :)
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.
w tym samym klubie, parę lat wcześniej zaczęła się moja przygoda z Atari
https://www.youtube.com/watch?v=NaVs3Iurfq8
EOR to XOR?
"source XOR destination" zabiera trzy cykle szyny (odczyt źródła, odczyt celu, zapis celu) - 12 cykli procesora
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.
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.
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
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
:)
i jeszcze coś mi wpadło do głowy. Czy faktycznie poniższa instrukcja jest potrzebna?
"addq.w #1,d3 ;4" robisz w obrębie Word a nie Long
Znalezione posty [ 2,826 do 2,850 z 4,877 ]
