Przejdź do treści forum
atari.area forum
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
RespeQt 5.4.1 Nowa wersja darmowego emulatora urządzeń SIO z poprawkami błędów.
Edytor MCM od TeBe/Madteam TeBe/Madteam prezentuje pierwszą wersję edytora map w trybie Multi Color Map na Atari.
Test7800 0.7.3 Nowa wersja emulatora Atari 7800 z obsługą kontrolerów Paddle, Trakball oraz poprawkami rdzenia CPU.
HDDRIVER 12.76 Nowa wersja sterownika HDDRIVER poprawia obsługę Fast-RAM i zapowiada przełomową współpracę z EmuTOS.
Fujisan 1.1.1 Nowa wersja emulatora Fujisan stawia na integrację z FujiNet-PC i porzuca wsparcie dla Windows.
Opcje wyszukiwania (Strona 109 z 192)
git,
ja testuję EmuTOS pod Winuae
Skrzyp, pewnie masz rację. Amigę widziałem ostatni raz w '92, więc mogę się mylić.
No ale z tego co pamiętam to np. Vampire 600/500, PAK 68/3 jaki i właśnie Furia 600 montuje się na CPU.
ZbyniuR napisał/a:A czy ST ma w sobie port rozszerzeń w tym stylu co Amigi czy jedynie port na kości pamięci Ram oraz ROM w kartridżu?
w amidze rozszerzenia CPU montuje się tak samo jak w Atari - nakładając na CPU, więc tu nie powinno być problemu.
Z tego co pamiętam to problemem może być typ podstawki, kwadrat (STE/A600) vs prostokąt (STfm/A500), oraz to że procesor w amidze jest wykastrowany z istotnych sygnałów (np A600 z E-clock i jeśli się nie mylę to z sygnałów FC0-2).
Tomasz Wachowiak napisał/a:W najbardziej krytycznej czasowo części kodu dużo miejsca na optymalizację już nie było, a zawsze będzie 3 linie mniej :)
ok, na dzień dzisiejszy mamy 10 linii mniej dla tej figury (lewa strona BT4PC_C, prawa kod zoptymalizowany):
Figura ta wykorzystuje wyłącznie "multi_words", więc nie wiem jak optymalizacja wygląda w przypadku krótkich wektorów.
Widzę jeszcze miejsce na optymalizację, np. aktualnie generowanie nowej tablicy leftEdge/rightEdge/leftMask/rightMask wymaga inicjalizacji dla każdego wielokąta osobno. gdyż odbywa się ono pomiędzy "compute_triangle_dx" a "fill_triangle".
Można by spróbować wykonać tylko jedną inicjalizację dla wszystkich wielokątów. Czyli wykonać "compute_triangle_dx" dla wszystkich wielokątów, potem tylko jedna inicjalizacja BLiTTERa, a następnie dla każdego wielokąta generowanie nowej tablicy leftEdge/rightEdge/leftMask/rightMask. No i na koniec "fill_triangle" dla każdego wielokąta.
A jak sprawdzić ile watów ma zasilacz w TT?
grey/msb napisał/a:Who knows...
Słusznie!
xxl napisał/a:Ten nowy sprzet to prawdziwy amiga killer.
czemu używasz brzydkich słów na "am" ? :P
Pin napisał/a:Nie istnieje coś takiego jak XEX. Jest to aplikacja pod Spartę X która łyka dowolną bitmapę 256/256/256 i nią kręci. O, czyli zapomniałem, że Sparta też jest tu potrzebna :P
brzmi spoko, zapodaj jakąś binarkę :)
Duddie napisał/a:A monitor SC1435 mogę Ci naprawić.
dał byś radę rzucić okiem na mój SC1435?
Pinex, ja też poproszę. zapodaj jakiegoś xexa
ok, zgłaszam zaległy iwenty
"Zeszło-Zeszłotygodniowe łikendowe piwko"
Miejsce: u mnie
Organizatorzy: Cyprian i Ja
Termin: zeszły zeszły łikend
Cena piwka: <zakładana cena>
Jedynie Irish Beer i Black Beer Stout warte uwagi.
Nowy termin:
"Zeszłotygodniowe łikendowe piwko"
Miejsce: u mnie
Organizatorzy: Cyprian i Ja
Termin: zeszły łikend
Cena piwka: <zakładana cena>
Wszystkie cacy
Nowy termin:
"Dziś bania"
Miejsce: u mnie
Organizatorzy: Cyprian i Ja
Termin: dziś a w zasadzie to już trwa :)
Cena piwka: <zakładana cena>
Na razie git
mały OT. Tutaj nowość od konkurencji :)
https://youtu.be/ZQ3-nnoXGng?t=49
Sprawdziłem w debuggerze winuae no i jeden obiekt generowany jest w cztery ramki
Wczoraj w nocy udało mi się dodać optymalizację w której BLiTTER generuje nową tablicę leftEdge address/rightEdge address/leftMask/rightMask. Skraca ona czas całości o trzy linie skaningowe. Nie jest to powalający wynik, ale nowy kod daje miejsce na dalsze optymalizacje.
.poly_fill_line wygląda teraz tak:
.poly_fill_line:
movem.w (A0)+,D0-D3 ; D0 - left; D1 - right; D2 - left mask; D3 - right mask
movea.l a5,a4
lea logLine(a5),a5 ;next y offset line
lea (a4,d0.w),a4 ;add line x offset
sub.w d0,d1 ;line width
asr.w #3,D1
bgt.s .multi_words
Kod jest brudny, wieczorem siądę by go oczyścić i jutro wrzucę go na forum.
Super, widzę że sprawy idą w słusznym kierunku. Wprowadziłeś kawał niezłego kodu, jutro siadam do studiowania :)
Ja niestety dopiero dzisiaj miałem okazję znowu siąść do kodu.
Bazuję teraz na ostatnim BT4PC_C. Dodałem nową procedurę BLiTTERa - inicjalizacja i generowanie nowej tablicy leftEdge/rightEdge/leftMask/rightMask oraz nową wersję poly_fill_line bazującą na tej tablicy. Pierwszy etap - generowani tablicy działa poprawnie, niestety drugi - poly_fill_line już nie. Dziś już nie dam rady, ale może jutro wieczorem uda mi się siąść do debuggera i przejść przez poly_fill_line.
Co do clippingu to czy on zawsze jest on potrzebny? Np. dla glenz nie wychodzącego poza ramki ekranu?
Naprawdę słuszna koncepcja :)
jeśli chodzi o moją część to, mam działający kod ale niestety nie miałem jeszcze czasu zintegrować go z trianglefi. Muszę jeszcze raz przemyśleć użycie rejestrów gdyż w trianglefi większośc jest wykorzystana.
Te dwa słowa na linię w przypadku 16 punktowych linii wynikało z tego że rejestry Halftone inicjowałem tylko jeden raz, ale za to wartościami dla wszystkich kolorów.
By wypełnić cztery bitplany w jednym strzale (z uwzględnieniem Mask1/Mask3) musiałem dać ujemne dstYinc, co powoduje że Halftone są dekrementowane. Działa to dobrze w "multi_words" ale nie w wariancie z tylko jednym słowem (<=16 punktów) na bitplan. Tak więc dla linii 16 punktowej musiałem zwiększyć szerokość linii do dwóch słów by móc zastosować ujemne dstYinc.
Widzę że w 5_C inicjujesz Halftone częściej, ale za to tylko jednym kolorem. To daje możliwośc poprawienia 16 punktowych linii.
Niestety dopiero wieczorem będę miał więcej czasu, siądę do Twojego ostatniego kodu i zrobię parę testów.
Jeśli chodzi o wybraną ilość planów to jasne, zapodawaj :)
Jakby co to też mam kod, tylko jeszcze go nie publikowałem. W sumie są to kosmetyczne zmiany do aktualnej procedury blittera.
Tomasz Wachowiak napisał/a:Hmm... 2? A nie 4? A co z danymi do wypełniania zawartymi w halftonach?
cykl szyny (z punktu widzenia CPU/BLiTTERa) czyli 4 cykle CPU :)
17 cykli szyny na załadowanie danych z pamięci do D0-D7 i drugie 17 na przesłanie z D0-D7 do Halftone
Potem generowanie leftMask/rightMask na podstawie Halftone i leftEdge/rightEdge - 2 cykle szyny (Jeden odczyt i Jeden zapis) - 8 cykli procesora na jedną maskę
Tomasz Wachowiak napisał/a:Tylko pamiętaj, że na lsrze stracisz. Ja poszedłem w drugą stronę i zrobiłem oddzielne tablice dla prawej i lewej strony, dzięki czemu zamieniłem lsra na dwa addy. No i sam movem sporo zabiera.
Chodziło mi o to by BLiTTER na podstawie leftEdge/rightEdge wygenerował tablicę leftMask/rightMask,
oraz by uniknąć lsl/addów BLiTTER dokonał na leftEdge/rightEdge operacji - AND $FFF0 i rotacji o 3 bity w prawo.
Najprościej będzie jak w wolnej chwili siądę do assemblera i sprawdzę czy to działa.
A tutaj napisany z palca, tak na szybko, szkic kodu fill_triangle_line_loop:
fill_triangle_line_loop
movem.w (A0)+,D0-D3 ; D0 - left; D1 - right
; D2 - left mask; D3 - right mask
move.l D6,A4 ; current line address
add.l #160,D6 ; next line address
lea (A4,D0.w),a4 ; add line x offset
sub.w D0,D1 ; line width
asr.w #1,D1 ; words number
bgt.s .multi_words
and.w D2,D3
move.w D3,endmsk1(a6) ;only mask
...
No ciekawe. Chodzi o usprawnienie compute_triangle_dx?
Jakby co to mam ideę na zmianę w fill_triangle_line_loop. BLiTTER, na podstawie leftEdge/rightEdge może wygenerować left mask/right mask. Koszt to 34 cykle szyny na inicjalizację rejestrów Halftone a potem tylko 2 cykle szyny na maskę.
A jeszcze jakby udało się przeorganizować tablice leftEdge/rightEdge na taką:
REPT rezY
ds.w leftEdge, rightEdge, leftMask, right Mask.
ENDR
to w fill_triangle_line_loop można by jednym zgrabnym "movem.w (A0)+,D0-D3" ładować od razu wszystkie potrzebne dane.
YERZMYEY/HOOY-PROGRAM napisał/a:Btw, co prawda nie znam się zupełnie na SID-dzie i nigdy nic na to nie pisałem, ale zrobiłem dziś parę patternów, żeby sprawdzić, jak chodzą SID-owe procedury na Raspberry Pi 2 (GoatTracker).
No i wydaje mi się, na moje drewniane ucho, że chodzą prawidłowo.
http://yerzmyey.i-demo.pl/yerz_SID_rasp … i_test.mp3
brzmi git
ok, a kto robił te pacze?
git,
może pamiętasz z którego roku są te polskie produkcje?
Tomasz Wachowiak napisał/a:Nie bądź taki skromny... :) Te kilkanaście linijek jest przykładem na to, jak myśląc w nieszablonowy sposób można uzyskać świetne rezultaty. Jak dla mnie, to numer jeden od naprawdę długiego czasu.
:)
Tomasz Wachowiak napisał/a:Myślę jeszcze o czymś innym :) Tyle, że dużo roboty i muszę cały kod napisać, żeby się przekonać, czy będzie szybciej. A krótkich linii bym nie ruszał, bo kod blittera jest zbyt piękny, żeby go prymitywną motorolą zastępować :P
zapodawaj :)
widzę jeszcze miejsce na drobne optymalizacje, typu:
- Jeśli ekran jest w obrębie 16bitowej strony to można:
"move.l a4,dstAddr(a6) ; Destination Addr" --> "move.w a4,dstAddr+2(a6) ; Destination Addr"
- zmienić adresowanie dla kodu blittera z:
move.w D0,hop(A6)
...
move.w #0,endmsk3(a6) ; EndMask3
move.w #-6,dstYinc(a6) ; DestYInc
move.l a4,dstAddr(a6) ; Destination Addr
move.w #2,xCount(a6) ; xCount
move.w d4,yCount(a6) ; yCount
move.b D7,lineNum(a6) ; Do Blit, start with 3rd Half-Tone
na:
lea $FFFF8A3A.w,A6 ;HOP
move.w D0,(A6)
...
move.w d4,-(a6) ; yCount
move.w #2,-(a6) ; xCount
move.l a4,-(a6) ; Destination Addr
move.w #-6,-(a6) ; DestYInc
move.w #0,-2(a6) ; EndMask3
move.b D7,$10(a6) ; Do Blit, start with 3rd Half-Tone
Ale to urywa zaledwie kilkanaście cykli na linię.
Znalezione posty [ 2,701 do 2,725 z 4,789 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.163 sekund, wykonano 15 zapytań