1 Ostatnio edytowany przez mono (2014-01-22 17:01:59)

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.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

2

nie

przechodze na tumiwisizm

3 Ostatnio edytowany przez mono (2014-01-30 04:04:01)

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  ;add

Wynik 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

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

4

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.

@swinkamor12: Amiga tak zresztą jak ST jest 32 bitowa bo procesor jest 32 bitowy, int w C jest 32 bitowy, a to po ilu bitach się komunikuje z resztą jest nieistotne.

5

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

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

6 Ostatnio edytowany przez mono (2014-02-12 12:46:33)

Czy w trybie AND (4) zachodzi optymalizacja z source"=$FF?

Edit: Głupie pytanie. Uprasza się admina o usunięcie cichcem :P

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

7 Ostatnio edytowany przez mono (2018-12-13 14:03:40)

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  ;TRANSPARENTCOPY

Jak 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?

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

8

Dokumentacja nie wspomina o optymalizacji 1, więc stawiam, że 2.

https://www.youtube.com/watch?v=jofNR_WkoCE

9

Tak czułem niestety. Szkoda. Ale zrobię w wolnej chwili jednak test, bo kto wie - może wszyscy będziemy zaskoczeni :) Dzięki.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje