Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
Czy zadając blit w trybie 2 (ADD) można spowodować, żeby operacja ta odbywała się Z PRZENIESIENIEM?
Edit: Przeniesienie mogłoby działać tylko w obrębie pojedynczej linii.
Ostatnio edytowany przez mono (2014-01-22 17:01:59)
Szkoda.
Zadanie: dokonać rotacji w lewo bloku "len" danych zaczynającego się we "from"; wynik umieścić w "to"
0: to+len=0 ;clear bit shifted into end of buffer (1 if bit should be set)
1: mode=0, and=$00, xor=$7f, src=xxx, dst=to ;fill buf with $7f
2: mode=1, and=$80, xor=$00, src=from, dst=to ;copy $80 to buf when source value has highest bit set
3: mode=2, and=$00, xor=$81, src=xxx, dst=to ;buffer contains shifted out bits shifted into lowest bits
4: mode=2, and=$ff, xor=$00, src=from, dst=to+1 ;add
5: mode=2, and=$ff, xor=$00, src=from, dst=to+1 ;addWynik operacji znajduje się w "to"+1.
"from" nie jest modyfikowany.
"to" powinien mieć rozmiar o 1 bajt większy niż "from".
Jeśli dobrze liczę VBXE będzie realizować rol pojedynczego bajtu w 7/8 cykli (czy można by prosić o diagramy dla operacji blittera tak, żeby można było sobie precyzyjnie policzyć czasochłonność blitów).
Edit: styl
Ostatnio edytowany przez mono (2014-01-30 04:04:01)
Może to będzie pomocne.
Ja liczę cykle dla blittera tak:
Całe vbxe ma do dyspozycji 14min cykli na sekundę
Blitter ma do swojej dyspozycji połowę tego, jeśli vbxe wyświetla obraz. Jeśli nie wyświetla to pewnie więcej
To daje nam 14 000 000 / 2 / 50 = 140 000 cykli dla blitera w 1 ramce
Teraz ile zjada blitter:
- odczyt BCB to 21 cykli
- każdy dostęp do pamięci to 1 cykl (nieistotne czy chodzi o src czy o dst) przykładowo dla operacji add dla bloku 1x1 mamy 21 cykli na bcb i 3 cykle na samą operacje (dwa odczyty i jeden zapis)
Możliwe, że mechanizm detekcji kolizji zjada coś jeszcze ale tego nie wiem.
Warto dodać, że w sytuacji gdy operacja blittera wykonywana jest na pamięci która aktualnie podłączona jest do okna MEMA lub MEMB to gubione są kolejne cykle potrzebne na jakąś synchronizacje między Atari a Vbxe.
Z prywatnych obserwacji mogę dodać, że blitter emulowany w altirze działa wolniej od tego z real vbxe.
Dzięki ajcek. Późno już było, lecz dziś jest nowy lepszy dzień w związku z czym poszukałem forum i oto: http://www.atari.org.pl/forum/viewtopic.php?id=10265
Czy w trybie AND (4) zachodzi optymalizacja z source"=$FF?
Edit: Głupie pytanie. Uprasza się admina o usunięcie cichcem :P
Ostatnio edytowany przez mono (2014-02-12 12:46:33)
Mamy taki BCB:
bcb_transfer:
?srcad .long SOURCE
?srcdy .word 1
?srcdx .byte 0
?dstad .long TARGET
?dstdy .word 1
?dstdx .byte 0
?width .word 1-1
?height .byte 64-1
?and .byte %00000000
?xor .byte %00000000
?coll .byte %00000000
?zoom .byte $00
?patt .byte %00000000
?mode .byte 1 ;TRANSPARENTCOPYJak VBXE to wykona? Czy pobierze BCB i:
1. zorientuje się że w wyniku AND i XOR jest zawsze 0 i pominie wykonanie blita - czyli skończy tylko na pobraniu BCB?
2. będzie pobierać dane z SOURCE 64 razy, ale nie zapisze niczego w TARGET?
Ostatnio edytowany przez mono (2018-12-13 14:03:40)
Dokumentacja nie wspomina o optymalizacji 1, więc stawiam, że 2.
Tak czułem niestety. Szkoda. Ale zrobię w wolnej chwili jednak test, bo kto wie - może wszyscy będziemy zaskoczeni :) Dzięki.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 7.420 sekund, wykonano 10 zapytań ]