22.11.2013 11:48
[#34]
Re: Róznice w chipsetach Amigi
@ZbyniuR, post #26
A mi się wydawało że póki się nie pojawiła ECS to spryciarze pisali pod hardware a nie pod system, licząc że tak będzie szybciej chodzić.
noi dobrze kalkulowali, bo tez bedzie lepiej dzialac. Mozna powiedziec, ze w Amidze 500/600/1000/1200 i 1200 z 020/14Mhz/FAST to ma jeszcze sens pelne wykorzystanie chipsetow, ew. moze jeszcze slaba 030/28Mhz dla jakis typow bardziej rozbudowanych w logike gier akcji... Powyzej pewnej wydajnosci CPU uklady specjalizowane Amigi tylko spowalniaja cala procedure (szczegolnie tyczy sie 040/60), skoro w Fast niemal wszystko jest szybciej, wygodniej i tez latwiej, a potem przerzuca sie tylko to co trzeba do Chip i wio, a jeszcze lepiej jak programista korzysta z OS, bo moze ktos ma jakas karte graficzna i odczuje znaczaca poprawe... Nawet stare uklady np: TsengET6000 czy CL GDxxx itd. (nie mowiac o dzwiekowkach np: GUS), znacznie lepiej radza sobie niz AGA.... Wspolczesne nawet kilkuletnie uklady wycofane dawno z produkcji to juz w ogole kosmos
22.11.2013 15:08
[#37]
Re: Róznice w chipsetach Amigi
@cholok, post #32
Jak widziałeś te shoty z gry http://hol.abime.net/2545 to teraz obejrzyj film http://www.youtube.com/watch?v=eB5kk9w1Os8 i porównaj...
22.11.2013 17:31
[#39]
Re: Róznice w chipsetach Amigi
@Radov, post #27
Blitter i Copper są wciąż 16bitowe...
To że coś jest 16-bitowe, nie znaczy, że jest powolne, w przypadku pamięci oznacza to jej szerokość a w przypadku procesora rozmiar rejestru, jego wydajność nie rózni się niczym od 32-bitowego póki nie operuje na liczbach większych niż 16 bitowych (czyli ponad 64 tys.) co w takim razie oznacza 16-bitowość w odniesieniu do LISY, DENISE, blittera lub coppera?
Nie do końca rozumiem założenia tego testu.
Rysowanie okien i ikon na ekranie? Te elementy są rysowane przez funkcje systemowe, więc tym bardziej widać jak jest różnica w dostępie do pamięci.
Jest to istotna kwestia, gdy wyświetlasz coś więcej niż statyczny obrazek. Na przykład grę 3D i musisz co ramka odrysować obraz.
A od kiedy to Lisa ma w sobie bufor ramki? Lisa mieli pamięć chip na okrągło każda klatka jest czytana z pamięci od nowa, więc nie ma tutaj znaczenia, czy dane w pamięci chip się zmieniły czy nie.
To że coś jest 16-bitowe, nie znaczy, że jest powolne, w przypadku pamięci oznacza to jej szerokość a w przypadku procesora rozmiar rejestru, jego wydajność nie rózni się niczym od 32-bitowego póki nie operuje na liczbach większych niż 16 bitowych (czyli ponad 64 tys.) co w takim razie oznacza 16-bitowość w odniesieniu do LISY, DENISE, blittera lub coppera?
Nie do końca rozumiem założenia tego testu.
Rysowanie okien i ikon na ekranie? Te elementy są rysowane przez funkcje systemowe, więc tym bardziej widać jak jest różnica w dostępie do pamięci.
Jest to istotna kwestia, gdy wyświetlasz coś więcej niż statyczny obrazek. Na przykład grę 3D i musisz co ramka odrysować obraz.
A od kiedy to Lisa ma w sobie bufor ramki? Lisa mieli pamięć chip na okrągło każda klatka jest czytana z pamięci od nowa, więc nie ma tutaj znaczenia, czy dane w pamięci chip się zmieniły czy nie.
22.11.2013 23:34
[#40]
Re: Róznice w chipsetach Amigi
@] SKOLMAN_MWS ˇ agrEssOr [, post #37
Nie wiem co mi to ma uświadomić. Na filmiku widzę tylko duże artefakty kompresji. Słabo nadaje się do oglądania, a na pewno do porównywania wcale. Ja po prostu sam uruchomiłem sobie grę i obejrzałem. No i sprawdziłem ilość kolorów w samej grze i raczej nie jest to HAM6, zbyt mało kolorów.
23.11.2013 07:12
[#41]
Re: Róznice w chipsetach Amigi
@rafgc, post #39
Nie mam na myśli oczywiście, że LISA to jakiś cud natury, ale przynajmniej udało się uzyskać trochę więcej niż tyci przeskok z OCS na ECS, który nie wniósł specjalnie nic pożytecznego z czego korzystaliby programiści. Więcej bitplanów i lepszy dostęp do pamięci, to już coś. Blitter i copper nawet jak się nie zmieniły, to procesor i tak ma większą swobodę dostępu do pamięci i może modyfikować więcej danych graficznych niż ma to miejsce w przypadku ECS przy 16-bitowej szynie danych gdzie powyżej 8 procesor musi czekać na swoją kolejkę.
24.11.2013 12:53
[#42]
Re: Róznice w chipsetach Amigi
@rafgc, post #41
(*) na wstępie chciałbym podkreślić, że nie uważam, że zjadłem wszystkie mózgi świata 
Możliwe, że moja interpretacja nie wszędzie jest prawidłowa, staram się jednak do danych podchodzić jak najbardziej racjonalnie. Możliwe, że do części ograniczeń podchodzę zbyt rygorystycznie, ale jeśli mam rację to....
1) w kontekście blittera - rozmiar próbki danych jaka przetwarzana w jednym cyklu operacji. Nie ma to związku z szerokością rejestrów i prędkością szyny. Blitter AGA, nawet jakby miał 128bitowy rejestr/bufor, będzie przetwarzał dane w 16 bitowych paczkach. Prosty blit wiersza 320 bit zajmie 20 cykli (od 80 do 160 taków zegara 7MHz, zależnie od liczby kanałów blittera). Tak jak przy OCS/ECS. Blitter 32 bitowy potrzebowałby na to 10 cykli. Im większa wydajność blittera, tym większa część ekranu będzie mogła się zmienić w przeciągu 1 ramki obrazu. Chyba czujesz tą różnicę? Choćby na dwukrotnym skróceniu czasu zajętości szyny?
2) w przypadku coppera - rozmiar słowa jakim operuje. 16 bitowy copper potrzebuje 2 dostępów do RAM (polecenie+wartość) dla polecenia MOVE. 32 bitowemu wystarczyłby 1 dostęp dla 16bitowych rejestrów.
16 bitowy copper nie jest w stanie w jednej operacji zmodyfikować wpisu rejestrów koloru LISY. Oczywiście taka podmiana w AGA nie jest tak spektakularna jak w ECS, ale jednak w efekcie na AGA przestaje działać trick "CHUNKY MODE" - 12 bitowy ekran CHUNKY o rozdzielczości bodajże 80x256.
Inna kwestia to, że 32 bitowy copper również by nie mógł tego zrobić... Ale to już raczej należy przenieść do dyskusji "dlaczego aga nie ma chunky mode w ogóle?"
3) W przypadku LISY - szerokość rejestrów kontrolujących układ, a więc prędkość i elastyczność "konfiguracji". Część z nich musisz konfigurować dwoma operacjami 16bit, zamiast jedną 32 bit. Oznacza to większą zajętość procesora/coppera niż jest konieczne. Oczywiście, podstawowe pytanie - jak często taka (re)konfiguracja następuje? To już zależne od indywidualnych przypadków....
4) W przypadku Alice - 16bit - szerokość dostępu do szyny danych, a w efekcie: ilość danych przekazywanych do układów chipsetu "w jednym takcie". Nie jest to związane z interfejsem LISY (jak mniemam...). Gdyby wykorzystywała pełną dostępną(!) szerokość, "karmienie" układów chipsetu zajmowałoby do dwóch razy mniej czasu. Podkreślam "do" - układy chipsetu też musiałby być na to odpowiednio przygotowane...
Tu ponownie nie do końca jestem pewien co masz na myśli w tych słowach. Co ma piernik do wiatraka?
Jeśli chcesz wyświetlić obraz, to musisz go umieścić w X bitplanach wskazywanych Lisie przez 16bitowe rejestry SPRxPTH : SPRxPTL. Możesz to zrobić za pomocą CPU i blittera. Nie ma to jednak bezpośrednio żadnego związku z tym czy LISA ma swój bufor (a tak w zasadzie to ma) i z jaką prędkością odczytuje dane.
To od programisty zależy ile i jakich danych wyświetli. Jeśli wystarczy mu, że 80% ekranu będzie przedstawiać statyczny obrazek, a pozostałą część skrolowany tekst - to problemu nie ma. Jeśli jedak zechcesz chcesz wyświetlić 256 kolorową animacje, to musisz w przeciągu 1 ramki obrazu - 20 ms PAL - skopiować nowe dane do 8 bitplanów. Ewentualnie pobawić się rejestrami LISY, zaimplementować proste podwójne buforowanie i uzyskać dodatkowy czas dla animacji o mniejszej ilości FPS. Pomińmy kwestię, czy w ogóle dałoby się odświeżanie ramek zrobić "chipsetowo", ale to że LISA sobie cały czas bangla w tle, nie wyręcza nas z konieczności dogrywania nowych danych.
To właśnie jest ta podstawowa kwestia: to że AGA potrafi wyświetlić 8 bitplanów to pewne i nie ulega wątpliwości! ...ale czy jest ona jednocześnie w stanie przygotować dane (wgrać nowe tło, uaktualnić nie-sprajtowe boby itp.) dla 8 planów (256 kolorów) 320x256 w 50 fps? Odpowiedź brzmi: nie jest. Bez wsparcia ze strony CPU AGA osiągnie (ponad) 50fps tylko dla 4 planów. Albo tylko dla części widocznego obszaru. Tak mi to wynika z tego zestawienia ECSu z AAA: An Overview of the Advanced Amiga Architecture and Other Future Directions (strona 12).
Oczywiście - jest jeszcze procesor. Ma więcej czasu, swobody i dostępu do szyby. I możemy w ogóle zamontować tak szybki żeby wyłączyć AGA (w cholerę...
) i robić wszystko programowo. Co się z resztą robi... Możesz mi tylko wyjaśnić jak w takim kontekście mówić o pożyteczności AGA dla programistów jeśli główną radą jest, jak się okazuje, nie używać tego chipsetu i zastąpić go procesorem?
A przecież 10 lat temu OCS projektowany był właśnie po to, żeby CPU nie był potrzebny do tego typu operacji....
PS. To ja tutaj też podkreślę: Nie zrozumcie mnie, że chcę udowodnić, że AGA to jakieś barachło. Nic z tych rzeczy. Wątek, jak jest wyraźnie napisane, po prostu dotyczy różnic pomiędzy chipsetami. Relacjonuję tylko, że w dużej części AGA jest bardzo mocno osadzona w swoim poprzedniku. Nie oceniam tego. Ma to swoje złe strony, ale i dobre: kompatybilność. Historia potoczyła się tak jak potoczyła i nie jestem w stanie stwierdzić, czy gdyby Commodore poprawiło wszystkie wytykane tym kościom niedostatki kosztem kompatybilności (wypuszczając szybszą maszynę, ale bez oprogramowania) to byśmy wyszli na tym lepiej....
Ostatnia aktualizacja: 24.11.2013 12:55:31 przez Radov
Możliwe, że moja interpretacja nie wszędzie jest prawidłowa, staram się jednak do danych podchodzić jak najbardziej racjonalnie. Możliwe, że do części ograniczeń podchodzę zbyt rygorystycznie, ale jeśli mam rację to....To że coś jest 16-bitowe, nie znaczy, że jest powolne, (...) co w takim razie oznacza 16-bitowość w odniesieniu do LISY, DENISE, blittera lub coppera?
1) w kontekście blittera - rozmiar próbki danych jaka przetwarzana w jednym cyklu operacji. Nie ma to związku z szerokością rejestrów i prędkością szyny. Blitter AGA, nawet jakby miał 128bitowy rejestr/bufor, będzie przetwarzał dane w 16 bitowych paczkach. Prosty blit wiersza 320 bit zajmie 20 cykli (od 80 do 160 taków zegara 7MHz, zależnie od liczby kanałów blittera). Tak jak przy OCS/ECS. Blitter 32 bitowy potrzebowałby na to 10 cykli. Im większa wydajność blittera, tym większa część ekranu będzie mogła się zmienić w przeciągu 1 ramki obrazu. Chyba czujesz tą różnicę? Choćby na dwukrotnym skróceniu czasu zajętości szyny?
2) w przypadku coppera - rozmiar słowa jakim operuje. 16 bitowy copper potrzebuje 2 dostępów do RAM (polecenie+wartość) dla polecenia MOVE. 32 bitowemu wystarczyłby 1 dostęp dla 16bitowych rejestrów.
16 bitowy copper nie jest w stanie w jednej operacji zmodyfikować wpisu rejestrów koloru LISY. Oczywiście taka podmiana w AGA nie jest tak spektakularna jak w ECS, ale jednak w efekcie na AGA przestaje działać trick "CHUNKY MODE" - 12 bitowy ekran CHUNKY o rozdzielczości bodajże 80x256.
Inna kwestia to, że 32 bitowy copper również by nie mógł tego zrobić... Ale to już raczej należy przenieść do dyskusji "dlaczego aga nie ma chunky mode w ogóle?"
3) W przypadku LISY - szerokość rejestrów kontrolujących układ, a więc prędkość i elastyczność "konfiguracji". Część z nich musisz konfigurować dwoma operacjami 16bit, zamiast jedną 32 bit. Oznacza to większą zajętość procesora/coppera niż jest konieczne. Oczywiście, podstawowe pytanie - jak często taka (re)konfiguracja następuje? To już zależne od indywidualnych przypadków....
4) W przypadku Alice - 16bit - szerokość dostępu do szyny danych, a w efekcie: ilość danych przekazywanych do układów chipsetu "w jednym takcie". Nie jest to związane z interfejsem LISY (jak mniemam...). Gdyby wykorzystywała pełną dostępną(!) szerokość, "karmienie" układów chipsetu zajmowałoby do dwóch razy mniej czasu. Podkreślam "do" - układy chipsetu też musiałby być na to odpowiednio przygotowane...
A od kiedy to Lisa ma w sobie bufor ramki? Lisa mieli pamięć chip na okrągło każda klatka jest czytana z pamięci od nowa, więc nie ma tutaj znaczenia, czy dane w pamięci chip się zmieniły czy nie.
Tu ponownie nie do końca jestem pewien co masz na myśli w tych słowach. Co ma piernik do wiatraka?
Jeśli chcesz wyświetlić obraz, to musisz go umieścić w X bitplanach wskazywanych Lisie przez 16bitowe rejestry SPRxPTH : SPRxPTL. Możesz to zrobić za pomocą CPU i blittera. Nie ma to jednak bezpośrednio żadnego związku z tym czy LISA ma swój bufor (a tak w zasadzie to ma) i z jaką prędkością odczytuje dane.
To od programisty zależy ile i jakich danych wyświetli. Jeśli wystarczy mu, że 80% ekranu będzie przedstawiać statyczny obrazek, a pozostałą część skrolowany tekst - to problemu nie ma. Jeśli jedak zechcesz chcesz wyświetlić 256 kolorową animacje, to musisz w przeciągu 1 ramki obrazu - 20 ms PAL - skopiować nowe dane do 8 bitplanów. Ewentualnie pobawić się rejestrami LISY, zaimplementować proste podwójne buforowanie i uzyskać dodatkowy czas dla animacji o mniejszej ilości FPS. Pomińmy kwestię, czy w ogóle dałoby się odświeżanie ramek zrobić "chipsetowo", ale to że LISA sobie cały czas bangla w tle, nie wyręcza nas z konieczności dogrywania nowych danych.
To właśnie jest ta podstawowa kwestia: to że AGA potrafi wyświetlić 8 bitplanów to pewne i nie ulega wątpliwości! ...ale czy jest ona jednocześnie w stanie przygotować dane (wgrać nowe tło, uaktualnić nie-sprajtowe boby itp.) dla 8 planów (256 kolorów) 320x256 w 50 fps? Odpowiedź brzmi: nie jest. Bez wsparcia ze strony CPU AGA osiągnie (ponad) 50fps tylko dla 4 planów. Albo tylko dla części widocznego obszaru. Tak mi to wynika z tego zestawienia ECSu z AAA: An Overview of the Advanced Amiga Architecture and Other Future Directions (strona 12).
Oczywiście - jest jeszcze procesor. Ma więcej czasu, swobody i dostępu do szyby. I możemy w ogóle zamontować tak szybki żeby wyłączyć AGA (w cholerę...
) i robić wszystko programowo. Co się z resztą robi... Możesz mi tylko wyjaśnić jak w takim kontekście mówić o pożyteczności AGA dla programistów jeśli główną radą jest, jak się okazuje, nie używać tego chipsetu i zastąpić go procesorem? A przecież 10 lat temu OCS projektowany był właśnie po to, żeby CPU nie był potrzebny do tego typu operacji....
PS. To ja tutaj też podkreślę: Nie zrozumcie mnie, że chcę udowodnić, że AGA to jakieś barachło. Nic z tych rzeczy. Wątek, jak jest wyraźnie napisane, po prostu dotyczy różnic pomiędzy chipsetami. Relacjonuję tylko, że w dużej części AGA jest bardzo mocno osadzona w swoim poprzedniku. Nie oceniam tego. Ma to swoje złe strony, ale i dobre: kompatybilność. Historia potoczyła się tak jak potoczyła i nie jestem w stanie stwierdzić, czy gdyby Commodore poprawiło wszystkie wytykane tym kościom niedostatki kosztem kompatybilności (wypuszczając szybszą maszynę, ale bez oprogramowania) to byśmy wyszli na tym lepiej....
Ostatnia aktualizacja: 24.11.2013 12:55:31 przez Radov
24.11.2013 13:42
[#43]
Re: Róznice w chipsetach Amigi
@Radov, post #42
Blitter 32 bitowy potrzebowałby na to 10 cykli.
taki blit to raczej skrajnosc w normalnym uzyciu blittera przy takiej rozdzielczosci tj. 320x256. w przypadku 32bit blittera wszystko musi byc przyciete do min. 32bitow, a wiec zuzyje sie wiecej pamieci, czy rzeczywiscie bedzie wtedy 2x szybciej ?. np: blit 36bitow to 3 op. 16bit i 2 op. 32bit, w pierwszej op. dane zrodlowe do wykonania op. zajmuja min. 6 bajtow, a w drugiej min. 8 bajtow. To tyczy sie wszystkich kanalow zrodlowych, docelowy moze czasami potrzebowac 1 op. wiecej. Teraz trzeba policzyc jak to wyglada dla roznych dlugosci blitow w przypadku przesuwania o n bitow itd. zeby miec jakies porownanie...
ps. oczywiscie czym wiekszy blit tym wieksza bedzie przewaga 32bit blittera itd.
24.11.2013 14:31
[#44]
Re: Róznice w chipsetach Amigi
@sigma2pi, post #43
w przypadku 32bit blittera wszystko musi byc przyciete do min. 32bitow, a wiec zuzyje sie wiecej pamieci
Jesteś pewien? Wydaje mi się, że możesz ustawić stałą maskę (na kanał B?), dobrać minterma i spokojnie blitować z szerokością mniejszą niż 32 bity... DMA kanału B będzie wyłączone, więc maska będzie stała i nie będzie potrzebny dodatkowy dostęp do szyny...
oczywiscie czym wiekszy blit tym wieksza bedzie przewaga 32bit blittera itd.
To oczywiście prawda. Dobrałem jednak ten przykład ze względu na chęć oceny maksymalnych, teoretycznych możliwości AGA (względem poprzedników) starając się nie zaśmiecać wątku zbyt dużą ilością pomysłów "co by było gdyby". Oraz: w kontekście wyręczania CPU z operacji. Po to przecież mamy chipset
Kwestia małych blitów to z resztą osobna historia i w tym kontekście bardziej bym zwracał uwagę na stosunkowo duży czas potrzebny do konfiguracji blittera-planar (i zarządzania nim) względem ilości wykonanych operacji niż różnicę jednej operacji dla danych o szerokości 33-48bit między trybami 16, a 32 bit.
Jestem świadom, że w skrajnym przypadku: danych o szerokości do 16bit (nie powinno się tego załatwiać sprite'ami?) oba rozwiązania uzyskają podobną wydajność, jednak cała idea 32bit blittera była/jest powiązana z 'brakującym' trybem chunky, gdzie na przeniesienie danych wystarczy 1 ciągła operacja, a nie sekwencja Start-Stop powtarzana dla X planów. W takim przypadku uzyskalibyśmy PONAD dwu krotny wzrost wydajności z racji braku kar za wywołanie przerwania, re-konfigurację i wznawianie pracy...
Ostatnia aktualizacja: 24.11.2013 14:33:33 przez Radov
24.11.2013 15:16
[#45]
Re: Róznice w chipsetach Amigi
@Radov, post #44
Jeszcze precyzując, odnośnie "uzyciu blittera przy takiej rozdzielczosci tj. 320x256":
Nie zapominajmy, że blit o szerokości 16 bitów dla 320x256 ma taką użyteczność jak 32 bitów w rozdzielczości 640x256 - o którą to już w kontekście gier tym wątku padło pytanie. Z punktu widzenia LISY i szyny obsługa nie byłaby tu problemem... Zakładałbym więc, że 2x szerszy blitter współgrałby z 2x większą użyteczną rozdzielczością stosowaną w grach - kwestia blitów 32-48 bitów by nie była częsta. Na poziomie przenoszenia 16-24 bitów przy obecnej architekturze. Czy ktoś ma z tym problem i sugerowałby przejście na 8bitowy blitter bo się zaoszczędzi 1 cykl?
PS. A gdyby jeszcze podbili dwukrotnie bazową częstotliwość.... mógłby chyba tak jeszcze długo
Nie zapominajmy, że blit o szerokości 16 bitów dla 320x256 ma taką użyteczność jak 32 bitów w rozdzielczości 640x256 - o którą to już w kontekście gier tym wątku padło pytanie. Z punktu widzenia LISY i szyny obsługa nie byłaby tu problemem... Zakładałbym więc, że 2x szerszy blitter współgrałby z 2x większą użyteczną rozdzielczością stosowaną w grach - kwestia blitów 32-48 bitów by nie była częsta. Na poziomie przenoszenia 16-24 bitów przy obecnej architekturze. Czy ktoś ma z tym problem i sugerowałby przejście na 8bitowy blitter bo się zaoszczędzi 1 cykl?
PS. A gdyby jeszcze podbili dwukrotnie bazową częstotliwość.... mógłby chyba tak jeszcze długo
25.11.2013 08:38
[#46]
Re: Róznice w chipsetach Amigi
@Radov, post #44
Jesteś pewien? Wydaje mi się, że możesz ustawić stałą maskę (na kanał B?)
no nie wiem czy adres nie musialby byc wyrownany do 32bitow. poza tym taka maska to dodatkowe 2 takty, no chyba, ze 32bitowy blitter robilby to za free, poza tym szkoda kanalu, a B potrzebne jest do przesuniec:)
w tym kontekście bardziej bym zwracał uwagę na stosunkowo duży czas potrzebny do konfiguracji blittera-planar
juz przy kilku bitplanach w trybie rawblit i podobnej wysokosci do szerokosci nie jest to juz duzy czas.
jednak cała idea 32bit blittera była/jest powiązana z 'brakującym' trybem chunky, gdzie na przeniesienie danych wystarczy 1 ciągła operacja
chunky jest 8 bitowe i znow jest to skrajny przypadek kiedy przenoszona jest cala zawartosc, a nie fragmenty. moim zdaniem to dopiero dla trybow 640x512 i wyzszych 32bitowy blitter dalby wyraznego kopa :).
25.11.2013 08:55
[#47]
Re: Róznice w chipsetach Amigi
@Radov, post #45
Czy ktoś ma z tym problem i sugerowałby przejście na 8bitowy blitter bo się zaoszczędzi 1 cykl?
Raczej nie. W obecnej architekturze takie blittery operuja na szerokosci slowa pamieci np: 128bit. Wielokrotne odczytywanie pojedynczych bajtow nie mialoby sensu, a wielkosci obszarow na ktorych operuje taki blitter sa wzglednie b.duze.
25.11.2013 13:25
[#48]
Re: Róznice w chipsetach Amigi
@sigma2pi, post #47
Ogólnie, AGA potrafi wyświetlić wyższe rozdzielczości i pobrać szybciej dane do przetworników C/A (żeby w ogóle mogły być wyświetlone te wyższe rozdzielczości w 256 kolorach).
Ale problem jest taki, że im więcej DMA jest włączonych, tym dłuższy dostęp procesora do pamięci CHIP. I teraz jeżeli mamy 640x512 w 256 kolorach, to według tego co podaje sysinfo (nie pamiętam dokładnie, ale chyba zapis 32-bit nawet na 68060 do chip jest w granicy 6MB/s), a dla 25FPS w tej rozdzielczości potrzebne jest przepchnięcie prawie 8MB danych aby odświeżyć cały ekran, to nie ma szans na płynną animację na pełnym całym ekranie. Nawet przy szybkich procesorach, ograniczeń transferu pamięci CHIP się nie przeskoczy.
Tak z ciekawości można by zrobić test na A2000 z 68060 i na A1200 lub A4000 z 68060, w tej samej rozdzielczości, w tylu samych kolorach, żeby zobaczyć czy transfery do CHIP jakoś się różnią na maszynach OCS/ECS vs AGA.
Wynik dla A4000D mogę tutaj wrzucić.
W A4000, żeby przyspieszyć AGAtę można zrobić trick i wymienić 50MHz kwarc, na np. 66MHz. U mnie był w podstawce i dla testu wymieniłem. Był wzrost prędkości AGAty i szyny Zorro.
Ale problem jest taki, że im więcej DMA jest włączonych, tym dłuższy dostęp procesora do pamięci CHIP. I teraz jeżeli mamy 640x512 w 256 kolorach, to według tego co podaje sysinfo (nie pamiętam dokładnie, ale chyba zapis 32-bit nawet na 68060 do chip jest w granicy 6MB/s), a dla 25FPS w tej rozdzielczości potrzebne jest przepchnięcie prawie 8MB danych aby odświeżyć cały ekran, to nie ma szans na płynną animację na pełnym całym ekranie. Nawet przy szybkich procesorach, ograniczeń transferu pamięci CHIP się nie przeskoczy.
Tak z ciekawości można by zrobić test na A2000 z 68060 i na A1200 lub A4000 z 68060, w tej samej rozdzielczości, w tylu samych kolorach, żeby zobaczyć czy transfery do CHIP jakoś się różnią na maszynach OCS/ECS vs AGA.
Wynik dla A4000D mogę tutaj wrzucić.
W A4000, żeby przyspieszyć AGAtę można zrobić trick i wymienić 50MHz kwarc, na np. 66MHz. U mnie był w podstawce i dla testu wymieniłem. Był wzrost prędkości AGAty i szyny Zorro.
25.11.2013 15:08
[#49]
Re: Róznice w chipsetach Amigi
@flops, post #48
W A4000, żeby przyspieszyć AGAtę można zrobić trick i wymienić 50MHz kwarc, na np. 66MHz. U mnie był w podstawce i dla testu wymieniłem. Był wzrost prędkości AGAty i szyny Zorro.
O to ciekawe, nie slyszalem o tym. I co, stacja dyskietek, dzwiek i ogolna synchronizacja audio/wideo bylo ok? Ile dalo to kopa?
Ostatnia aktualizacja: 25.11.2013 15:08:59 przez marianoamigo
25.11.2013 15:17
[#50]
Re: Róznice w chipsetach Amigi
@marianoamigo, post #49
15% - 20% szybciej, większość operacji graficznych przyspieszyła, ale nie wszystkie według sysspeed. Taka zmiana, o ile dobrze pamiętam, zwiększa przepustowość pamięci CHIP, ale nie wiem czy blitter jest szybciej goniony też. U mnie nie było żadnego problemu z synchronizacją, ale problem jest taki, że nie wszystkie karty na Zorro dadzą radę chodzić przy takim taktowaniu Zorro. Teraz mam z powrotem 50MHz kwarc.
26.11.2013 12:04
[#54]
Re: Róznice w chipsetach Amigi
@flops, post #52
Ten kwarc 50 MHz nie taktuje chipsetu AGA (ten jest taktowany kwarcem 28 MHz z groszami). Przetaktowałeś sygnał CPUINT, pobieżna analiza schematu wskazuje, że przyspieszyłeś przede wszystkim taktowanie 16 MB FastRAM, po problemach z kartami rozszerzeń wnosze także, że magistralę Zorro też. Nic dziwnego, że testy wyszły szybciej.
A przetaktowanie AGAty (możliwe, był o tym artek), poprzez zmianę generatora 28 MHz na szybszy, ma dosyć kłopotliwe skutki: problemy z synchronizacja obrazu, niewłaściwe odliczanie czasu przez rejestry sprzętowe (wszystko taktowane jest tym przebiegiem 28 MHz), zmiana wysokości dźwięku generowanego przez Paulę, możliwe problemy z napędami FDD i IDE. Co więcej, można zainstalować jedynie generator o kilka % szybszy, potem juz się komputer nie uruchamia.
Nie warto. Ale oczywiście jak ktoś lubi eksperymenty, czemu nie. :)
Ostatnia aktualizacja: 26.11.2013 12:05:15 przez wali7
A przetaktowanie AGAty (możliwe, był o tym artek), poprzez zmianę generatora 28 MHz na szybszy, ma dosyć kłopotliwe skutki: problemy z synchronizacja obrazu, niewłaściwe odliczanie czasu przez rejestry sprzętowe (wszystko taktowane jest tym przebiegiem 28 MHz), zmiana wysokości dźwięku generowanego przez Paulę, możliwe problemy z napędami FDD i IDE. Co więcej, można zainstalować jedynie generator o kilka % szybszy, potem juz się komputer nie uruchamia.
Nie warto. Ale oczywiście jak ktoś lubi eksperymenty, czemu nie. :)
Ostatnia aktualizacja: 26.11.2013 12:05:15 przez wali7
26.11.2013 17:35
[#58]
Re: Róznice w chipsetach Amigi
@wali7, post #54
No to czy ta słynna SuperAGA z Natami mogła działać czy to raczej ściema? Jeżeli nie mieli oryginalnych schematów, to jakoś nie chce mi się wierzyć, że wyeliminowali wszystkie wady AGA-ty i poprawili ją, no chyba, że amputowali jakieś funkcje, które uznali za zbędne. A skoro jesteśmy przy AGA/SuperAGA, to jak to jest z tajemniczym Akiko z CD32 w kwestii grafiki, odkryli jakieś nowe możliwości tego układu, bo raczej więcej domysłów do tej pory niż faktów było?
26.11.2013 17:56
[#60]
Re: Róznice w chipsetach Amigi
@Ender, post #58
Dlaczego miałaby nie działać? Cała praca nad SuperAGA polegać może jedynie na backengineeringu i znajomości mapy rejestrów - tak jak zrobiono chipset dla MiniMiga. Możesz zaimplementować dowolne funkcje, byle system nie zgłupiał na tym całkowicie: blitter może być znacznie szybszy (i szerszy niż 16 bit), nowe funkcje graficzne (chunky, jakieś 3d....). Może dema będą się wykrzaczać, ale póki rejestry chipsetu są tam gdzie powinny być, a timingi też są jak trzeba, to będzie działać. Ale to dotyczy hipotetycznego, nowego chipsetu, elementy rzeczywistej AGA pracują synchronicznie, więc jakakolwiek ingerencja w oryginalny chipset musi mieć mniej lub więcej skutków ubocznych.