25.10 15:41
[#1]
PCMCIA GPU P-vision
dokopalem sie dzis do takiego newsa : https://youtu.be/FWHhrI3Z9jo?si=ia8Fy9pFIus9ib--
dla tych co nie maja warpa to moze być ciekawa alternatywa
Ostatnia aktualizacja: 25.10.2025 15:43:10 przez fibi
dla tych co nie maja warpa to moze być ciekawa alternatywa
Ostatnia aktualizacja: 25.10.2025 15:43:10 przez fibi
25.10 19:42
[#4]
Re: PCMCIA GPU P-vision
@michal_zukowski, post #3
Może zatem lepiej by się spisywała karta muzyczna. Mniej danych do przesłania. Ostatnio po raz pierwszy od ponad 20 lat puściłem MP3. Tym razem z dobrego sprzętu audio i nawet z AHI w 14b brzmi to tragicznie. Pomyśleć, że kiedyś na 030/50MHZ i obciętych parametrach mi się podobało. 
26.10 17:26
[#10]
Re: PCMCIA GPU P-vision
@fibi, post #9
Karta zapewne może dużo więcej niż 720p. Bo przy dzisiejszych cenach pamięci (niskich) i mnogości układów fpga, nie jest problemem wyrzeźbić układ graficzny wyświetlający np. 1920x1080. Taką przykładowo rozdzielczość potrafi wyświetlić w trybie karty graficznej IndivisionECS v4.
Problemem w przypadku Amigi jest niska prędkość przesyłania danych między komputerem a kartą podpiętą przez PCMCIA, siedzącą na miejscu Denice (jak Indi), czy w Zorro II. Zresztą nawet w przypadku rozwiązania tego problemu pojawi się od razu kolejny: prędkość CPU, który nie jest w stanie mielić tak dużej ilości danych celem wysłania tego na ekran (i nie mam na myśli przesuwania okien, bo od tego GPU mają wydajne blittery, ale np. przygotowanie danych do wyświetlenia GUI jakiegoś softu w wysokiej rozdzielczości).
Problemem w przypadku Amigi jest niska prędkość przesyłania danych między komputerem a kartą podpiętą przez PCMCIA, siedzącą na miejscu Denice (jak Indi), czy w Zorro II. Zresztą nawet w przypadku rozwiązania tego problemu pojawi się od razu kolejny: prędkość CPU, który nie jest w stanie mielić tak dużej ilości danych celem wysłania tego na ekran (i nie mam na myśli przesuwania okien, bo od tego GPU mają wydajne blittery, ale np. przygotowanie danych do wyświetlenia GUI jakiegoś softu w wysokiej rozdzielczości).
27.10 16:43
[#15]
Re: PCMCIA GPU P-vision
@michal_zukowski, post #14
Nie znam się na technikaliach wyświetlania grafiki , ale autor P-vision podobno ma jakiś sposób na ominięcie problemu niskiej przepustowości czy dotyczy to tylko WB czy gier też tego nie wiem , ale wg jego ostatnich wpisów sam Workbench działa szybko nawet bez blittera w 1024x768 w 256 kolorach i to na A1200 z fastem..
Ostatnia aktualizacja: 27.10.2025 16:43:51 przez lukzer
Ostatnia aktualizacja: 27.10.2025 16:43:51 przez lukzer
27.10 17:33
[#17]
Re: PCMCIA GPU P-vision
@wali7, post #13
Jaki jest max transfer po PCMCIA w Ami? Nie przypadkiem tyle, co Zorro II, czyli coś w okolicach 4 MB/s?
Bo AGA to ma tak 4x więcej....
Nie spodziewam się żeby było szybciej niż po Zorro II. Nie mam żadnej karty graficznej na ZII, ale w wysokiej rozdzielczości. Czyli takie 640x480 w 256 kolorach powinna taka karta być dwa razy szybsza od AGA w Highres Laced, czyli 640x512 w 256 kolorach. Jeśli się mylę to proszę mnie uświadomić, bo to są tylko moje rozważania teoretyczne nie poparte praktyką.
27.10 17:39
[#18]
Re: PCMCIA GPU P-vision
@koczis, post #17
AGA jest spowalniana przez wiele rzeczy, ale pasmo przepustowości dla grafiki (chip RAM>>Alice>>Lisa) jest circa 4x wyższe niż Zorro II.
To ze karty graficzne wyświetlają sprawniej grafikę 8 i więcej bitową jest wynikiem wyposażenia w szybką, własną (a więc nie wywłaszczaną przez resztę chipsetu) pamięć, a do tego ma dużo szybszy blitter niż AGA.
Efekt przyspieszenia grafiki jaki za pomocą FBlit daje wyłączenie blittera w AGA i zastąpienia go szybszym prockiem (od 68030) pokazuje, jak wielkim kamieniem na szyi jest dla chipsetu AGA stary Blitter.
No chyba, że mówimy o prędkości dostępu CPU do chip RAM, to zupełnie inna sprawa.
Ostatnia aktualizacja: 27.10.2025 17:47:07 przez wali7
To ze karty graficzne wyświetlają sprawniej grafikę 8 i więcej bitową jest wynikiem wyposażenia w szybką, własną (a więc nie wywłaszczaną przez resztę chipsetu) pamięć, a do tego ma dużo szybszy blitter niż AGA.
Efekt przyspieszenia grafiki jaki za pomocą FBlit daje wyłączenie blittera w AGA i zastąpienia go szybszym prockiem (od 68030) pokazuje, jak wielkim kamieniem na szyi jest dla chipsetu AGA stary Blitter.
No chyba, że mówimy o prędkości dostępu CPU do chip RAM, to zupełnie inna sprawa.
Ostatnia aktualizacja: 27.10.2025 17:47:07 przez wali7
27.10 17:55
[#19]
Re: PCMCIA GPU P-vision
@wali7, post #18
Nie w tym rzecz. Przepustowość pamięci drastycznie spada w AGA gdy zwiększysz rozdzielczość. Dlaczego? Ano dlatego, że Cooper musi z pamięci Chip pobrać olbrzymią ilość danych. W związku z tym pozostaje nie wiele czasu na jej wypełnienie. Na takich zestawach jak Mc68060 100 Mhz w rozdzielczości 640x480 na AGA w interlace uzyskuje się max 5 ramek. PiStorm RPI4 - 5,5 ramki. W pierwszym przypadku mamy transfer rzędu 1.5 MB. PCMCIA na MC68030 uzyskuje przy odczycie danych w Sysinfo 3.2 MB. Powiedzmy że zapis będzie podobny. Zapis do takiej karty graficznej na PCMCIA nie posiada wiele przeszkód. Wystarczy przesyłać dane z prawie maksymalną prędkością. Więc teoretycznie będzie to około 3MB na sekundę. Stąd bierze się mój wniosek o tym, że będzie dwa razy szybciej.
27.10 18:26
[#20]
Re: PCMCIA GPU P-vision
@koczis, post #19
No widzisz, ty mówisz copper, ja dodaję blitter (używanie blittera w AGA, z uwagi na jego powolność i wymagany w związku z tym długi dostęp do chip RAM czyni wszelkie operacje z jego użyciem wyjątkowo nieefektywnymi) i mamy efekt w postaci powolności AGA. Jednak Lisa ma zawsze priorytet jeśli chodzi o dostęp do chip RAM (w przeciwnym wypadku mielibyśmy migający ekran), i zawsze dostanie go tyle ile trzeba. Policz sobie ile danych trzeba pobrać z chip RAM w ciągu sekundy, jeśli masz przykładowo 800x600 Multiscan Productivity Nolace 8 bit... i to się dzieje - chip RAM w AGA jest naprawdę szybki.
Efekt powolności zaś to skutek tego, gdy po zabraniu cykli dostępu Coppera i Blittera, jak mało przepustowości zostanie dla CPU (on ma najniższy priorytet). A przecież CPU musi wypełnić sensowną treścią to co Lisa wyrzuci na ekran.
Fajnym rozwiązaniem jest Indivision ECS v4 - on ma tryb karty graficznej, ma własny VRAM, ma własny blitter, szynę między Agnusem a Denise wykorzystuje do zapisu tego VRAMu przez CPU (ona ma przepustowość około 4 MB/s w ECS, więc szybciej niż dostęp CPU w AGA do chip RAM który też pełni rolę VRAM). Efektem są całkiem sensowne tryby 8 bit (16 bit już trochę skrzeczą) - 800x600 8 bit jest dużo szybszy niż podobny tryb AGA.
Mam nadzieję, że nie istnieje jakiś nieprzekraczalny problem w wykorzystaniu tego rozwiązania w maszynach AGA. Z uwagi na 4x szybszy transfer magistralą Alice>>Lisa (to daje ponad 16 MB/s!) mielibyśmy kartę graficzną osiągami kładącą każdą kartę Zorro II, a i pewnie niejedną Zorro III (bo przecież mało która karta pod ZIII osiąga naprawdę przyzwoite transfery). Jeśli pojawi się Indivision AGA z ficzerem w postaci RTG, to kupuję od razu do A1200.
Efekt powolności zaś to skutek tego, gdy po zabraniu cykli dostępu Coppera i Blittera, jak mało przepustowości zostanie dla CPU (on ma najniższy priorytet). A przecież CPU musi wypełnić sensowną treścią to co Lisa wyrzuci na ekran.
Fajnym rozwiązaniem jest Indivision ECS v4 - on ma tryb karty graficznej, ma własny VRAM, ma własny blitter, szynę między Agnusem a Denise wykorzystuje do zapisu tego VRAMu przez CPU (ona ma przepustowość około 4 MB/s w ECS, więc szybciej niż dostęp CPU w AGA do chip RAM który też pełni rolę VRAM). Efektem są całkiem sensowne tryby 8 bit (16 bit już trochę skrzeczą) - 800x600 8 bit jest dużo szybszy niż podobny tryb AGA.
Mam nadzieję, że nie istnieje jakiś nieprzekraczalny problem w wykorzystaniu tego rozwiązania w maszynach AGA. Z uwagi na 4x szybszy transfer magistralą Alice>>Lisa (to daje ponad 16 MB/s!) mielibyśmy kartę graficzną osiągami kładącą każdą kartę Zorro II, a i pewnie niejedną Zorro III (bo przecież mało która karta pod ZIII osiąga naprawdę przyzwoite transfery). Jeśli pojawi się Indivision AGA z ficzerem w postaci RTG, to kupuję od razu do A1200.
27.10 20:21
[#21]
Re: PCMCIA GPU P-vision
@lukzer, post #15
No wlasnie Workbench nigdy nie bedzie problemem w nowych kartach. Przy dobrze zrobionej akceleracji wszystkie bitmapty (ikonki, tla, ...) siedza sobie w pamieci karty graficznej i ona je szybko rysuje. Problem jest przy grach pelnoekranowych. Jesli mamy doomopodobne to generujesz cala ramke w fastramie i kopiujesz do VRAMu, ewentualnie robisz c2p i lecisz do chipu dla AGA/ECS. Czyli masz ciagly strumiem kopiowania danych i od predkosci magistrali zalezy jaki bedzie limit fpsow.
27.10 22:26
[#24]
Re: PCMCIA GPU P-vision
@wali7, post #20
Efekt powolności zaś to skutek tego, gdy po zabraniu cykli dostępu Coppera i Blittera, jak mało przepustowości zostanie dla CPU (on ma najniższy priorytet). A przecież CPU musi wypełnić sensowną treścią to co Lisa wyrzuci na ekran.
DMA Blittera oraz DMA Coppera można swobodnie wyłączyć i wówczas nie mają one dostępu do pamięci graficznej Amigi. Pytanie tylko czemu to robić? Nie ma potrzeby ich wyłączać. Oba koprocesory graficzne wspomagają operacje rysownicze i wideo. Co więcej zwiększają wydajność grafiki odciążając procesor.
Copper zajmuje się ustawieniem rejestrów sprzętowych. Co ramkę (klatkę animacji) ładowana jest copperlista. Copper może wywołać przerwanie procesora, jeżeli zestaw jego instrukcji jest niewystarczający.
Blitter natomiast jest koprocesorem który jest relatywnie szybki, bo przerzuci troszkę mniej niż ~4MB/s, czyli dwukrotność całej pamięci graficznej Amigi 1200 w ciągu sekundy.
Bitmapy w Amidze tym róznią się od PC że są podzielone na bitplany, ale nadal dostęp jest w postaci prostokątów. Po prostu wypełnimy ekran grafiką szybciej, bo możemy optymalizować liczbę kopiowanych bitplanach. Szerokość operacji musi wynosić przynajmniej 16 pikseli by było to efektywne.
Niestety w pojedynczym buforowaniu może wyglądać to słabiej, bo widać proces rysowniczy. Po użyciu podwójnego buforowania problem znika. Po użyciu bitmap interleaved problem w pojedynczym buforowaniu jest zmniejszony.
Bitmapy w wysokich rozdzielczościach są podzielone na bitplany więc wypełnianie może być bardzo szybkie, szczególnie jak zastosujemy optymalizację.
Przykład Settlers II na Amiga OS pokazuje, że rozwiązanie w postaci siłowego wykorzystania procesora głównego (CPU) może skończyć się bardzo wysokimi wymaganiami, nawet na Amidze z PPC lub NG.
Bo ta gra pochodzi z roku 1996 i w oryginale z PC wymagała 486DX/66 MHz dla wysokich rozdzielczości. Wspominam tylko dlatego, że porównujemy platformy i architektury graficzne z tamtych lat.
Ja rozumiem, że dzisiaj silniki obrosły w różne dodatkowe warstwy, które zwiększają wymagania.
Gra typu Settlers II opiera się na bitmapie dwuwymiarowej. Tutaj nie trzeba wysyłać całego bufora co ramkę. Mamy efekty typu przesuw mapy, przesuw okienek oraz animacje - drzewek, budynków i osadników. Jak się przyjrzymy, to zobaczymy, że osadnicy na pewno nie są animowani w 50 fps, tylko rzadziej (chodzą po ścieżkach bardziej skokowo).
Z tego co wiem, w takich grach obsługa obiektów odbywa się właśnie rzadziej, dzięki czemu możemy obsłużyć bardzo dużo takich obiektów.
Przesuw, animacja bitmapy to domena Amigi.
Dodam, że w Amidze operacja zapisu pikseli w postaci chunky korzysta z bufora o rozmiarze jednej linijki. Piksele są konwertowane, a następnie Blitter kopiuje tę linijkę na bitmapę docelową. Chunky przydaje się do mapowania pikseli, ale z powodzeniem możemy w takich grach korzystać z bitmap już skonwertowanych dla Blittera.
Wydaje mi się, że Amiga 4000/040 powinna obsłużyć taką grę natywnie, szczególnie właśnie po zastosowaniu optymalizacji.
Wykorzystanie AHI wysoko-poziomowo i kopiowanie całego bufora zamiast animowanej części może mieć negatywny wpływ na szybkość działania gry.
Ja cieszę sie, że u Kolegów gra Settlers II działa dobrze na Warp1260/100MHz, PiStorm czy Vampire.
Ja chętnie przyjąłbym choć Settlers I w 256 kolorach, który natywnie z pewnością śmigałby na 68030/50MHz i nawet mniej niż 16 MB RAM, który posiadam w swojej głównej Amidze.
Ostatnia aktualizacja: 27.10.2025 22:33:05 przez Hexmage960
27.10 23:00
[#25]
Re: PCMCIA GPU P-vision
@Hexmage960, post #24
Blitter jest najgorszą częścią chipsetu AGA. Nie dlatego, że jest zły, bo zasadniczo jest dobry... a właściwie był. Gdyż jest to dokładnie ten sam blitter, który J.Miner zaprojektował blisko 10 lat wcześniej, z tą samą wydajnością, która w 1985 była rewelacyjna, ale w 1992 już nie. Kości AGA mogą wyświetlać więcej kolorów, więcej pikseli, obsługują też więcej RAMu niż pierwsze chipsety Amigi. Pasmo dostępu DMA chipsetu AGA jest 4x większe niż ECS... ale blitter jest dokładnie taki sam i tragicznie spowalnia działanie całości.
27.10 23:35
[#27]
Re: PCMCIA GPU P-vision
@michal_zukowski, post #26
Tak, post wcześniej pisałem o tym - FBlit z 68030 50 MHz oferuje solidne przyspieszenie operacji graficznych. Tu mamy dwa efekty - szybsze blitowanie, a więc blitowane elementy odrysowują się szybciej, a dwa, wydajne operacje blitowania wykonywane przez 68030 powodują że powolny blitter nie odbiera tak wiele pasma przepustowości innym elementom chipsetu AGA.
28.10 13:01
[#28]
Re: PCMCIA GPU P-vision
@wali7, post #25
Pasmo dostępu DMA chipsetu AGA jest 4x większe niż ECS... ale blitter jest dokładnie taki sam i tragicznie spowalnia działanie całości.
Blitter pracuje asynchronicznie względem CPU i według mnie nie spowalnia działania operacji graficznych.
Po prostu zlecamy Blitterowi operację, podczas której procesor może liczyć inne rzeczy.
Jeżeli nie chcemy czekać na wynik operacji możemy użyć przerwania Blittera. Okazuje się jednak, że Blitter jest na tyle szybki, że lepiej jest wywoływać kolejne operacje w pętli i czekać na zakończenie, szczególnie w przypadku małych operacji.
Akceleracja Blitterem jest wtedy najbardziej widoczna. Procesor nie musi długo czekać na zakończenie kolejnych blitów.
W przypadku dużych operacji jest też OK, szczególnie jeżeli po uruchomieniu operacji robimy inne obliczenia lub użyjemy przerwania.
W systemie Amigi (biblioteki layers, graphics) Blitter nie spowalnia operacji rysujących, tylko operacje wyglądają po prostu brzydko (efekt animacji). Powody:
- Blitter czyści najpierw obszar kolorem tła, mimo że za chwilę będzie go wypełniać grafiką (funkcja ScrollRaster używana przy przesuwaniu okienek),
- Modyfikacja po bitplanach jest widoczna w pojedynczym buforowaniu.
W banalny sposób można to usprawnić. Zaprogramowanie tego to 30 minut.
Podsumowując moim zdaniem Blitter pomaga usprawnić rysowanie i skorzystamy z tego przede wszystkim na procesorze 68020 ale też na 030 i 040. Oczywiście na tych wyższych procesorach zapis pikseli Chunky jest bardzo szybki, mimo to Blitter jest w stanie pomóc. Sam posiadam 68030 i używam Blittera w praktyce w swoim kodzie.
Blitter potrafi:
- Skopiować obszar,
- Przesunąć obszar,
- Połączyć dwa obszary za pomocą maski prostokątnej lub dowolnej,
- Wypełnić obszar ograniczony znacznikami,
- Narysować linie proste i te znaczniki.
Warto korzystać z Blitter DMA, żeby procesor nie musiał wielu rzeczy obliczać.
Surowa moc CPU jest w porządku, ale dlaczego nie zlecić pracę koprocesorom. Przykładów jest sporo (AHI, RTGMaster bazują na mocy CPU, ale zupełnie niwelują DMA Amigi). Jestem też pewien, że optymalizacja po bitplanach daje naprawdę bardzo wiele.
Ostatnia aktualizacja: 28.10.2025 13:06:46 przez Hexmage960
28.10 16:22
[#30]
Re: PCMCIA GPU P-vision
@Hexmage960, post #28
Tak, blitter wszystko to potrafi. Wiadomo, amigowy blitter jest całkiem zaawansowaną konstrukcją na tle ówczesnej konkurencji np. z Atari STE. Potrafi robić funkcje logiczne, itp... Wiadomo też, że w Amidze chipset zasadniczo ma cykle dostępu do chip RAM przepleciony z cyklami dostępu CPU, tak aby nie musieć (zbyt często) wywłaszczać CPU z szyny.
To wszystko prawda, ale jedynie w przypadku chipsetu ECS i procesora 68000 7,14 MHz.
Bowiem w przypadku chipsetu AGA blitter wykonuje swoje operacje tak samo szybko, jak w chipsecie ECS. W przypadku chipsetu AGA mamy zazwyczaj do czynienia z większą ilością danych graficznych do obróbki, a wtedy prędkość blittera idealnie obliczona na potrzeby trybów OCS/ECS jest zbyt mała. Z uwagi na fakt, że kanały DMA blittera mają najniższy priorytet z całego chipsetu (tylko CPU jest niżej) w przypadku większego obciążenia przez Lisę (przy większej ilości kolorów w HiRes), czy chociażby przez Copper, blitter musi czekać z każdą jedną operacją, a na domiar złego będzie ją wykonywał bardzo długo (bo jest wolny). W takiej sytuacji chipset dostaje dodatkowe cykle dostępu, normalnie przeznaczone CPU, więc następuje dodatkowe spowolnienie działania całego komputera. A blitter i tak musi czekać na Lisę, Copper czy Paulę.
Zaoszczędzenie na przekonstruowaniu blittera jest zdecydowanie największym błędem, który Commodore popełnił przy projektowaniu układów AGA. Odbija się to czkawką w wielu przypadkach: przesuwaniu okien, czy BOBów, jak również bardzo wolnym dostępem CPU do chip RAM. Szybki blitter wykonywałby swoją robotę szybko, nie widzielibyśmy odrysowujących się okien, a CPU miałby dłuższe okresy dostępu do chip RAM.
Od jakiegoś czasu chodzi mi po głowie taki pomysł/idea. Otóż, gdyby zaprojektować dodatkowy, zewnętrzny blitter nakładany na któryś z układów chipsetu tak, aby mieć dostęp do szyny chipsetu (Amiga ma osobną magistralę dla chip RAM pod pełną kontrolą Agnus/Alice). Układ ten wyposażony byłby we własny kontroler DMA i zdolny byłby robić wszystko to, co oryginalny blitter, tylko dużo szybciej. Aby system mógł z niego korzystać (bo niesystemowe gry wiadomo że nie) należałoby napisać programik wyłączający oryginalny blitter i przekierowujący wszelkie jego operacje do tego układu nowego blittera. Sposób działania tego programu byłby dokładnie taki sam jak FBlit, tyle że operacje robiłby sprzętowo nowy blitter, a nie CPU. Efektem byłoby, podobnie jak w przypadku FBlit odciążenie kanałów DMA dla grafiki i tym samym jej znaczne przyspieszenie, oraz zwiększenie ilości cykli dostępu do chip RAM dla CPU (bo nowy blitter potrzebowałby ich znacznie mniej niż stary).
Dodatkowo, taki układ blittera można by wyposażyć w dodatkowe funkcje np. konwersję C2P i w drugą stronę, także konwersję formatów pikseli, overlay, czy bardziej zaawansowane funkcje w rodzaju cieniowania Gourauda, teksturowania i prostych efektów 3D na teksturach. To są wszystko dosyć proste rzeczy. Oczywiście, wszystkie takie dodatkowe funkcje wymagały by dodatkowej biblioteki systemowej, ale być może dałoby się to ogarnąć na poziomie jakiegoś Warp3D. Aż dziwne, że Commodore mając blitter zintegrowany od zawsze z chipsetem nie wpadł na to, aby wykorzystać go do tak prostej rzeczy jak konwersja C2P i musiał wymyślić kulawy układ Akiko, który ma dość kiepską wydajność i jest tylko w CD32.
Plusem takiego podejścia jest to, że taki nowy blitter byłby wykorzystywany przez całość oprogramowania systemowego, bez potrzeby przepisywania, czy patchowania czegokolwiek. Oczywiście musiałby być napisany programik a'la FBlit przekierowujący odwołania do blittera na ten nowy.
Jedyne czego nie wiem, co być może stanowiłoby problem, to czy da się zewnętrznym kanałem DMA wjechać w obszar pod kontrolą Agnus/Alice.
Oczywiście, dzisiaj te wszystkie rzeczy, i więcej, można osiągnąć robiąc kartę graficzną, chociażby tak, jak w przypadki Indivision ECS v4, gdzie mamy blitter (tyle że operujacy wyłącznie na lokalnym VRAM karty) i lepsze tryby graficzne.
Ale to taki pomysł, który w przypadku powodzenia pokazałby, że Commodore miał na wyciągnięcie ręki rozwiązanie, które byłoby o wiele lepsze, bardziej perspektywiczne, rozwiązałoby masę problemów z chipsetem i uczyniło go lepszym. Wystarczyło zrobić lepszy blitter, zamiast nie zrobić nic (bo robotę zrobił wczesniej J. Miner projektując blitter, który 1:1 został bez żadnych unowocześnień użyty w AGA).
Takie coś obecnie można ogarnąć nie tylko FPGA, ale chyba prościej za pomocą ARMa wyposażonego w kontroler DMA pozwalający mu szaleć po chip RAMie. Tak jak np. karta ZZ9000 wszystkie swoje sprzętowe operacje wykonywane na danych graficznych tak naprawdę robi jednym rdzeniem ARM. I oczywiście, wtedy najlepiej byłoby od razu iść na całość i zamiast ograniczać się starą LISĄ, po prostu dać VRAM i dodać możliwość generowania z tego obrazu. Ale wtedy po prostu mielibyśmy kolejną kartę graficzną, konieczność robienia sterowników....
A nie o to chodzi w tej zabawie, tu chodzi o pokazanie że można było.
Kto wie, może kiedyś taka zabawa dojdzie do jakiegoś etapu realizacji?
Ostatnia aktualizacja: 28.10.2025 16:28:52 przez wali7
To wszystko prawda, ale jedynie w przypadku chipsetu ECS i procesora 68000 7,14 MHz.
Bowiem w przypadku chipsetu AGA blitter wykonuje swoje operacje tak samo szybko, jak w chipsecie ECS. W przypadku chipsetu AGA mamy zazwyczaj do czynienia z większą ilością danych graficznych do obróbki, a wtedy prędkość blittera idealnie obliczona na potrzeby trybów OCS/ECS jest zbyt mała. Z uwagi na fakt, że kanały DMA blittera mają najniższy priorytet z całego chipsetu (tylko CPU jest niżej) w przypadku większego obciążenia przez Lisę (przy większej ilości kolorów w HiRes), czy chociażby przez Copper, blitter musi czekać z każdą jedną operacją, a na domiar złego będzie ją wykonywał bardzo długo (bo jest wolny). W takiej sytuacji chipset dostaje dodatkowe cykle dostępu, normalnie przeznaczone CPU, więc następuje dodatkowe spowolnienie działania całego komputera. A blitter i tak musi czekać na Lisę, Copper czy Paulę.
Zaoszczędzenie na przekonstruowaniu blittera jest zdecydowanie największym błędem, który Commodore popełnił przy projektowaniu układów AGA. Odbija się to czkawką w wielu przypadkach: przesuwaniu okien, czy BOBów, jak również bardzo wolnym dostępem CPU do chip RAM. Szybki blitter wykonywałby swoją robotę szybko, nie widzielibyśmy odrysowujących się okien, a CPU miałby dłuższe okresy dostępu do chip RAM.
Od jakiegoś czasu chodzi mi po głowie taki pomysł/idea. Otóż, gdyby zaprojektować dodatkowy, zewnętrzny blitter nakładany na któryś z układów chipsetu tak, aby mieć dostęp do szyny chipsetu (Amiga ma osobną magistralę dla chip RAM pod pełną kontrolą Agnus/Alice). Układ ten wyposażony byłby we własny kontroler DMA i zdolny byłby robić wszystko to, co oryginalny blitter, tylko dużo szybciej. Aby system mógł z niego korzystać (bo niesystemowe gry wiadomo że nie) należałoby napisać programik wyłączający oryginalny blitter i przekierowujący wszelkie jego operacje do tego układu nowego blittera. Sposób działania tego programu byłby dokładnie taki sam jak FBlit, tyle że operacje robiłby sprzętowo nowy blitter, a nie CPU. Efektem byłoby, podobnie jak w przypadku FBlit odciążenie kanałów DMA dla grafiki i tym samym jej znaczne przyspieszenie, oraz zwiększenie ilości cykli dostępu do chip RAM dla CPU (bo nowy blitter potrzebowałby ich znacznie mniej niż stary).
Dodatkowo, taki układ blittera można by wyposażyć w dodatkowe funkcje np. konwersję C2P i w drugą stronę, także konwersję formatów pikseli, overlay, czy bardziej zaawansowane funkcje w rodzaju cieniowania Gourauda, teksturowania i prostych efektów 3D na teksturach. To są wszystko dosyć proste rzeczy. Oczywiście, wszystkie takie dodatkowe funkcje wymagały by dodatkowej biblioteki systemowej, ale być może dałoby się to ogarnąć na poziomie jakiegoś Warp3D. Aż dziwne, że Commodore mając blitter zintegrowany od zawsze z chipsetem nie wpadł na to, aby wykorzystać go do tak prostej rzeczy jak konwersja C2P i musiał wymyślić kulawy układ Akiko, który ma dość kiepską wydajność i jest tylko w CD32.
Plusem takiego podejścia jest to, że taki nowy blitter byłby wykorzystywany przez całość oprogramowania systemowego, bez potrzeby przepisywania, czy patchowania czegokolwiek. Oczywiście musiałby być napisany programik a'la FBlit przekierowujący odwołania do blittera na ten nowy.
Jedyne czego nie wiem, co być może stanowiłoby problem, to czy da się zewnętrznym kanałem DMA wjechać w obszar pod kontrolą Agnus/Alice.
Oczywiście, dzisiaj te wszystkie rzeczy, i więcej, można osiągnąć robiąc kartę graficzną, chociażby tak, jak w przypadki Indivision ECS v4, gdzie mamy blitter (tyle że operujacy wyłącznie na lokalnym VRAM karty) i lepsze tryby graficzne.
Ale to taki pomysł, który w przypadku powodzenia pokazałby, że Commodore miał na wyciągnięcie ręki rozwiązanie, które byłoby o wiele lepsze, bardziej perspektywiczne, rozwiązałoby masę problemów z chipsetem i uczyniło go lepszym. Wystarczyło zrobić lepszy blitter, zamiast nie zrobić nic (bo robotę zrobił wczesniej J. Miner projektując blitter, który 1:1 został bez żadnych unowocześnień użyty w AGA).
Takie coś obecnie można ogarnąć nie tylko FPGA, ale chyba prościej za pomocą ARMa wyposażonego w kontroler DMA pozwalający mu szaleć po chip RAMie. Tak jak np. karta ZZ9000 wszystkie swoje sprzętowe operacje wykonywane na danych graficznych tak naprawdę robi jednym rdzeniem ARM. I oczywiście, wtedy najlepiej byłoby od razu iść na całość i zamiast ograniczać się starą LISĄ, po prostu dać VRAM i dodać możliwość generowania z tego obrazu. Ale wtedy po prostu mielibyśmy kolejną kartę graficzną, konieczność robienia sterowników....
A nie o to chodzi w tej zabawie, tu chodzi o pokazanie że można było.
Kto wie, może kiedyś taka zabawa dojdzie do jakiegoś etapu realizacji?
Ostatnia aktualizacja: 28.10.2025 16:28:52 przez wali7