Ok, to wtrącę swoje 3 grosze, bo widzę, że tu są prawie sami pozytywnie nastawieni. Dodawałem obsługę CTPCI w SDL (SuperVidela też), nawet grafx2, Scummvm na tym poszedł kiedyś tam i nawet próbowałem używać tego drewnianego api Didiera w programie testowym chyba 12 lat temu (double buffering te sprawy: https://vimeo.com/manage/videos/21062096). Zgadzam się z Willym. Uważam, że CTPCI jest pomyłką na poziomie hardware'u i software'u, cieszę się, że kiedyś przypadkowo spaliłem tę kartę.
Transfery na kartę i z powrotem po mostku pci są mega powolne, miał być poprawiony tryb burst (maglowałem autora karty o to od samego początku jak karta wyszła), ale mimo zapewnień nie zostało to poprawione przez wiele lat, więc autor nie dostarczył tego co na początku obiecywał. No i to jest sp**** hardware'owa. Idea traktowania karty z gpu jako większy bufor ramki jest słaba (te karty Radeon mają akcelerację 3d, prymitywną, ale mają), startup jest powolny, bo jest emulacja kodu x86 z romu karty, żeby ją zainicjalizować (wiecie, mamy motkę w Atari, nie Intela), to wpływa na długość inicjalizacji. Api graficznie musiałoby być gruntownie przeprojektowane, żeby można było korzystać z Radeona i ograniczyć przewalanie danych po mostku PCI, który jest wolny (jw., im więcej danych przewalamy tym jest gorzej). Żeby to zrobić trzeba by było poprawić driver, którego źródła nie są (łatwo) modyfikowalne (jakiś copy/paste z linuxa), no i trzeba patchować tos ct60 (sorry, ale żonglowanie firmwarem jest słabe). Dodam jeszcze, że development jest zabawny, bo żaden debugger nie działa poprawnie z 060, co przekłada się na czas developmentu (trwa dłużej niż powinien). Ale to też dotyczy SV i procka 060, nie ma supportu do debuggowania w OSie. Co za tym idzie trzeba by było być niespełna rozumu, żeby się do tego w ogóle dotknąć. Są jeszcze drobne smaczki typu odpytywanie karty graficznej o dostępne tryby graficzne, które trwa wieki i jest wywołaniem blokującym. Update palety kolorów w trybach 8-bit, zapomnijcie (jest to tak wolne) - a byłaby szansa na lepsze gry 256 kolorów, z normalnym layoutem ekranu w którym można jednym zapisem zmodyfikować piksel ekranu (= mniej przewalania danych po mostku). Nie dało się tego poprawić, to tak działa i koniec :). Nie ma opcji modyfikowania palety jak to na ST się zwykle dawało, żeby mieć więcej kolorów (,ale wiadomo to karta z 24/32-bitowym kolorem, ale do tego potrzebna jest jakaś sensowna przepustowość.
Kombinacja SV + ct60 jest lepszą opcją, bo nie trzeba żadnych idiotycznych sterowników, żeby coś zrobić (no dobra, mam zastrzeżenie, że support SV nie jest jeszcze w tosie CT60, bo autor kisi źródła od wielu lat, staram się mu to regularnie przypominać).
CTPCI do starych aplikacji w GEM się może nadaje (nowych już prawie nikt nie pisze), ale poza tym to do niczego. To samo sądzę o Eclipse PCI, tylko o tej karcie mam jeszcze gorszą opinię. Oczywiście cieszymy się wszyscy, że CTPCI w ogóle działa, Kroll np. się cieszy.
Żeby CTPCI miało sens, musiałyby być wprowadzone poprawki, które sugerował autor przy publikacji dokumentacji sprzętu (=przerobiony hardware, większe cpld, porawienie obecnej skomplikowanej burdelozy, której prawdopodobnie nikt nie odkręci), dodany tryb burst, musiałoby powstać jakieś sensowne api do komunikacji z kartą (driver, są jakieś źródła? Chyba nie, bo Dider przepadł i zabrał. I api graficzne z prawdziwego zdarzenia, żeby można było używać akceleracji sprzętowej (nie to api stworzone do torturowania ludzi i zwierząt).
:D Dziękuję za uwagę...
Ostatnio edytowany przez saulot (2023-03-15 22:34:56)
=========================================
[www]
https://nokturnal.pl[ 16/32 bit Atari development wiki]
https://bus-error.nokturnal.pl
