Komentowana treść: Apollo A6000 "Unicorn"
20.09 20:53
[#91]
Re: Apollo A6000 "Unicorn"
@KM_Ender, post #86
A gdzie ja napisalem, ze Amiga to tylko chipy?
Czesc osob za to uwaza, ze Amiga to tylko system.
A dla mnie Amiga to calosc: system, chipy (w tym procesor), rozwiazania tylko Amigowe i rozwiazania uniwersalne (HD, net itp).
Amiga byla prekursorem chocby w obsludze plyt CD czy kart PCMCIA, pomimo, ze nie byly to pomysly Commodore.
Czesc rozwiazan uzytych w Amigach sie przyjelo, czesc upadlo.
PPC to nie byl pomysl Commodore.
I sie nie sprawdzil.
Apple jako pierwsze to zrozumialo, pomimo ze mialo prawa do tworzenia G5 czy nawet G6.
To jest po prostu NIEWYDAJNY procesor.
Nadrabiajacy swoje braki taktowaniem.
Czesc osob za to uwaza, ze Amiga to tylko system.
A dla mnie Amiga to calosc: system, chipy (w tym procesor), rozwiazania tylko Amigowe i rozwiazania uniwersalne (HD, net itp).
Amiga byla prekursorem chocby w obsludze plyt CD czy kart PCMCIA, pomimo, ze nie byly to pomysly Commodore.
Czesc rozwiazan uzytych w Amigach sie przyjelo, czesc upadlo.
PPC to nie byl pomysl Commodore.
I sie nie sprawdzil.
Apple jako pierwsze to zrozumialo, pomimo ze mialo prawa do tworzenia G5 czy nawet G6.
To jest po prostu NIEWYDAJNY procesor.
Nadrabiajacy swoje braki taktowaniem.
20.09 21:54
[#93]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #91
Apple nie produkowało procesorów. Ich rola w całym "AIM" była taka, że mieli te procesory brać ;) IBM dało podwalinę w postaci architektury POWER, a Motorola była odpowiedzialna za odpowiednią skalę produkcji (i drugie źródło dostaw). Nie kojarzę by Apple było licencjobiorcą Power ISA. Poszli w intela bo to było rozwiązanie z półki które wystarczyło ładnie opakować. A w międzyczasie rozwijali ARM w mobilkach na tyle dobrze, że przyszła pora na laptopy i desktopa.
Pisanie, że PowerPC to niewydajny procesor to jak pisanie, że ARM to niewydajny procesor, albo x86 to niewydajny procesor. To nie ISA gwarantuje wydajność tylko architektura wewnętrzna, która z ISA jest trochę związana, ale nie aż tak jak się niektórym wydaje. Taktowanie, ilość potoków wykonawczych i układ przewidywania rozgałęzień robią swoje. Czemu więc nie ma powerpc na każdym rogu? Bo x86 wychodzi taniej, IBM PPC nie rozwija wcale (tylko Power), Freescale PPC rozwija tyle co nic, bo do telekomuny wcale wydajność obliczeniowa nie jest najważniejsza, a odpowiednie peryferia. AMCC się zwinęło z rynku, a BAE robi rad hardened dla przemysłu kosmicznego. Innymi słowy PPC po wtopie IBM z G5 nie miało klienta dla którego warto byłoby się starać. A nie dlatego, że architektura jest kiepska. G4 z Altivec lał równo PIII z SSE!
Procesor z Xbox360 czy PPE z PS3 też były bardzo wydajne (tutaj MS i Sony akurat na wydajności zależało i ona była dostarczona). Zwyczajnie MS i Sony uznali, że development jest za drogi i taniej po prostu kupić trochę zmodyfikowanego APU z PC (i też łatwiej portować gry z PC na konsole i vice versa).
Ostatnia aktualizacja: 20.09.2025 21:56:42 przez abcdef
Pisanie, że PowerPC to niewydajny procesor to jak pisanie, że ARM to niewydajny procesor, albo x86 to niewydajny procesor. To nie ISA gwarantuje wydajność tylko architektura wewnętrzna, która z ISA jest trochę związana, ale nie aż tak jak się niektórym wydaje. Taktowanie, ilość potoków wykonawczych i układ przewidywania rozgałęzień robią swoje. Czemu więc nie ma powerpc na każdym rogu? Bo x86 wychodzi taniej, IBM PPC nie rozwija wcale (tylko Power), Freescale PPC rozwija tyle co nic, bo do telekomuny wcale wydajność obliczeniowa nie jest najważniejsza, a odpowiednie peryferia. AMCC się zwinęło z rynku, a BAE robi rad hardened dla przemysłu kosmicznego. Innymi słowy PPC po wtopie IBM z G5 nie miało klienta dla którego warto byłoby się starać. A nie dlatego, że architektura jest kiepska. G4 z Altivec lał równo PIII z SSE!
Procesor z Xbox360 czy PPE z PS3 też były bardzo wydajne (tutaj MS i Sony akurat na wydajności zależało i ona była dostarczona). Zwyczajnie MS i Sony uznali, że development jest za drogi i taniej po prostu kupić trochę zmodyfikowanego APU z PC (i też łatwiej portować gry z PC na konsole i vice versa).
Ostatnia aktualizacja: 20.09.2025 21:56:42 przez abcdef
21.09 01:49
[#95]
Re: Apollo A6000 "Unicorn"
@abcdef, post #93
Ciekawe, bo sam pamietam artykul(y) o przejeciu produkcji procesorow G5 od Freescale przez Apple.
Moze to nie wyszlo, nie wiem. Ale takie plany byly.
Meynaf twierdzi, ze PPC jest niewydajny bo taki sam kod jest okolo 2x razy wiekszy niz dla innych procesorow, przez to wymaga 2x wiekszego cache.
I z tego co pamietam to oryginalny exek gry HOMM2 w wersji na Mac PPC jest okolo 2x wiekszy niz w wersji na Mac 68k czy x86.
Ostatnia aktualizacja: 21.09.2025 01:51:22 przez Don_Adan
Moze to nie wyszlo, nie wiem. Ale takie plany byly.
Meynaf twierdzi, ze PPC jest niewydajny bo taki sam kod jest okolo 2x razy wiekszy niz dla innych procesorow, przez to wymaga 2x wiekszego cache.
I z tego co pamietam to oryginalny exek gry HOMM2 w wersji na Mac PPC jest okolo 2x wiekszy niz w wersji na Mac 68k czy x86.
Ostatnia aktualizacja: 21.09.2025 01:51:22 przez Don_Adan
21.09 06:13
[#96]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #95
Meynaf twierdzi, ze PPC jest niewydajny bo taki sam kod jest okolo 2x razy wiekszy niz dla innych procesorow, przez to wymaga 2x wiekszego cache.
A efekt był taki, że to co było pisane na Amigę pod PPC działało szybciej niż na 68k. Także to że wymagał 2x większy cache i że kod więcej zajmował, nie miało to zbyt do rzeczy. Działało szybciej.
Generalnie do wszystkiego można się przyczepić, bo coś tam.
21.09 08:19
[#98]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #95
Przecież PPC ma długość instrukcji taką samą jak ARM (4 bajty) więc kod będzie tak samo rozlazły na jednych i drugich. Gdzie to ma przełożenie na wydajność? No nie ma. Właśnie stała długość instrukcji była tym co pozwoliło pod koniec lat 80 robić RISCowe procesory masakrujące jakiekolwiek CISC. Dlaczego? Bo KAŻDY RISC w tamtym czasie korzystał z przetwarzania potokowego a niektóre miały już też architekturę superskalarną, a popularne CISC (z 68k włącznie) dopiero brodziły po kostki bo trudno w x86 zrealizować przetwarzanie potokowe jak mamy rozkazy zajmujące od 1 do 31 bajtów (heh).
I co z tego, że kod był większy jak mimo wszystko procesor był kilka razy szybszy? Teraz są czasy takie, że czy CISC, czy RISC to nie ma znaczenia, bo wszystkie procesory mają te same usprawnienia (i po zdekodowaniu wszystkie mikroinstrukcje i tak są generalnie jak RISC dlatego x86 wszystkie rozkazy dekoduje na 1-4 mikroinstrukcje!). To co się liczy to jest ile ma potoków wykonawczych i jak dobrze jest je w stanie zapełniać podczas wykonywania typowego kodu - a to zależy od sod struktur fetch & decode, podsystemu pamięci podręcznej i wreszcie samych potoków wykonawczych. Dlatego procesor z 4 potokami wykonawczymi taktowany 4GHz będzie miał szczytowo podobną wydajność czy by wykonywał 68k, x86, arm, ppc, mips, whatever... a jak będzie się przeciętne wydajność kształtować zależy nie od ISA a od tego jak w środku te rozkazy będą sprytnie dekodowane by wykarmić ALU. Intel z AMD stawali na głowie by ten fetch&decode zoptymalizować do granic absurdu, ale mają i działa. Z drugiej strony M3 od Apple też działa, a zużywa mniej prądu (i wykonuje rozlazły kod). PPC jak najbardziej mogło być zamiast ARM w procesorach desktopowych Apple, tylko skoro zaczynali od mobilek, a PPC nie chciało się skalować w dół to jaki był sens? Lepiej było wziąć energooszczędnego ARM i dopakować w górę.
I co z tego, że kod był większy jak mimo wszystko procesor był kilka razy szybszy? Teraz są czasy takie, że czy CISC, czy RISC to nie ma znaczenia, bo wszystkie procesory mają te same usprawnienia (i po zdekodowaniu wszystkie mikroinstrukcje i tak są generalnie jak RISC dlatego x86 wszystkie rozkazy dekoduje na 1-4 mikroinstrukcje!). To co się liczy to jest ile ma potoków wykonawczych i jak dobrze jest je w stanie zapełniać podczas wykonywania typowego kodu - a to zależy od sod struktur fetch & decode, podsystemu pamięci podręcznej i wreszcie samych potoków wykonawczych. Dlatego procesor z 4 potokami wykonawczymi taktowany 4GHz będzie miał szczytowo podobną wydajność czy by wykonywał 68k, x86, arm, ppc, mips, whatever... a jak będzie się przeciętne wydajność kształtować zależy nie od ISA a od tego jak w środku te rozkazy będą sprytnie dekodowane by wykarmić ALU. Intel z AMD stawali na głowie by ten fetch&decode zoptymalizować do granic absurdu, ale mają i działa. Z drugiej strony M3 od Apple też działa, a zużywa mniej prądu (i wykonuje rozlazły kod). PPC jak najbardziej mogło być zamiast ARM w procesorach desktopowych Apple, tylko skoro zaczynali od mobilek, a PPC nie chciało się skalować w dół to jaki był sens? Lepiej było wziąć energooszczędnego ARM i dopakować w górę.
21.09 11:57
[#100]
Re: Apollo A6000 "Unicorn"
@waldiamiga, post #99
To zależy od umowy, często nie jest transferowalna na nowy podmiot, jak było w tym przypadku nie wiem, natomiast:
Najśmieszniejsze, że PA Semi akurat było odpowiedzialne za projektowanie układów PWRFicient które obok dobrej wydajności oferowały niski pobór energii. I o to chodziło w początkowej współpracy (gdy Apple jeszcze siedziało na PPC), natomiast 15W to i tak jest sporo, bo ultra low voltage Core 2 to okolice 5W. Efekt był taki, że Apple przeszło na Intela, o PPC zapomniało, a PA Semi kupiło żeby mieć know-how jak projektować wydajne i efektywne procesory, niekoniecznie PPC. A biorąc pod uwagę, że mieli też osoby odpowiedzialne za StrongARM to ... no cóż, kierunek działań był już obrany. Natomiast proszę nie ulegać jakiejś propagandzie, że PPC nie były wydajne. Były bardzo wydajne, szczególnie z genialnym AltiVec. Tutaj - zdaje się - intel dopiero przebił możliwościami gdy zapodał AVX z FMA. Tylko... ARM ma nawet 1024bit SVE, intel ma 512bit AVX, a PPC ? No siedzi dalej na altivec.
Ostatnia aktualizacja: 21.09.2025 12:01:23 przez abcdef
On Monday (April 21), P.A. Semi informed its customers it was being acquired and it could no longer guarantee supplies of its chips. The startup did not identify the acquiring company but said that company may be willing to supply the chip on an end-of-life basis, if it could successfully transfer a third-party license to the technology.
That license in question is probably a PowerPC architectural license that P.A. Semi has with IBM Corp. that allowed the startup to design its own PowerPC chip from scratch. IBM was not immediately available for comment on the issue.
Najśmieszniejsze, że PA Semi akurat było odpowiedzialne za projektowanie układów PWRFicient które obok dobrej wydajności oferowały niski pobór energii. I o to chodziło w początkowej współpracy (gdy Apple jeszcze siedziało na PPC), natomiast 15W to i tak jest sporo, bo ultra low voltage Core 2 to okolice 5W. Efekt był taki, że Apple przeszło na Intela, o PPC zapomniało, a PA Semi kupiło żeby mieć know-how jak projektować wydajne i efektywne procesory, niekoniecznie PPC. A biorąc pod uwagę, że mieli też osoby odpowiedzialne za StrongARM to ... no cóż, kierunek działań był już obrany. Natomiast proszę nie ulegać jakiejś propagandzie, że PPC nie były wydajne. Były bardzo wydajne, szczególnie z genialnym AltiVec. Tutaj - zdaje się - intel dopiero przebił możliwościami gdy zapodał AVX z FMA. Tylko... ARM ma nawet 1024bit SVE, intel ma 512bit AVX, a PPC ? No siedzi dalej na altivec.
Ostatnia aktualizacja: 21.09.2025 12:01:23 przez abcdef
21.09 23:40
[#105]
Re: Apollo A6000 "Unicorn"
@BULI, post #104
Takie cos znalazlem w sieci.
Watpie, zeby bylo prawdziwe.
38 instrukcji na cykl. Raczej 3-8.
Ale fani PPC moga sie cieszyc.
Watpie, zeby bylo prawdziwe.
38 instrukcji na cykl. Raczej 3-8.
Ale fani PPC moga sie cieszyc.
PowerPC Family Overview
CPU speed* instructions L1 cache L2 cache
601 60-120 MHz 3 per cycle 32 KB external to 1 MB
603 75-160 MHz 2 per cycle 2x8 KB
603e 100-300 MHz 2 per cycle 2x16 KB
604 100-180 MHz 4 per cycle 2x16 KB external to 1 MB
604e 166-233 MHz 6 per cycle 2x32 KB external to 1 MB
604ev 250-350 MHz 6 per cycle 2x32 KB external to 1 MB
G3/750 200-450 MHz 3 per cycle 2x32 KB external to 1 MB
750CX 366-466 MHz 3 per cycle 2x32 KB 256 MB onboard
750CXe 400-700 MHz 3 per cycle 2x32 KB 256 MB onboard
750FX 600-900 MHz 3 per cycle 2x32 KB 512 MB onboard
750GX 733-1100 MHz 3 per cycle 2x32 KB 1024 MB onboard
G4/7400 350-600 MHz 19 per cycle+ 2x32 KB supports 2 MB L2 cache
7410 466-533 MHz 20 per cycle+ 2x32 KB supports 1 MB L2 cache
7450 667-733 MHz 20 per cycle+ 2x32 KB 256 KB onboard, up to 2 MB L3
7455 600-1420 MHz 20 per cycle+ 2x32 KB 256 KB onboard, up to 2 MB L3
7447A 600-1500 MHz 20 per cycle+ 2x32 KB 512 KB onboard, no L3 cache
7457 867-1267 MHz 20 per cycle+ 2x32 KB 512 KB onboard, up to 4 MB L3
7457 used in some third-party Mac upgrades, never by Apple
7448 1.0-1.7 GHz 20 per cycle+ 2x32 KB 1024 KB onboard, no L3 cache
G5/970 1.6-2.0 GHz 38 per cycle+ 2x32 KB 512 KB onboard
970FX 1.8-2.7 GHz 38 per cycle+ 64+32 KB 512 KB onboard
970MP 1.8-2.5 GHz 38 per cycle+ 64+32 KB 1 MB per core 22.09 06:16
[#106]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #105
+ jest ze względu na marketing altivec. Można operować na 16 danych naraz więc, ktoś niepełnosprytny uznał, że to jest 16 operacji wektorowych naraz mimo, że to co najwyżej 2 wektorowe instrukcje. Jak pisałem AltiVec to była potęga w tamtych czasach, ale reszta CPU nie wygląda wcale tak różowo. Tylko 2 ALU. Core2 ma już 3, tak samo K8 od AMD. A Zen5 ma 5 ALU i niejako 4 FPU. Czy PowerPC mogło mieć podobnie? Mogło. Czemu nie? W końcu ostatnie poprawki od Gunnara to zdaje się odblokowane kolejne pipeline względem początkowych 2+fpu+ammx, tak? To skoro da się w x86, da się w 68k, da się w ARM czemu nie dałoby się w PPC? Jeszcze raz, większość argumentów o tym jak PPC jest złe będzie też dotyczyło jaki ARM jest zły, albo MIPS. Bo każdy z tych RISCowych procesorów będzie miał większy kod skompilowanego programu niż CISC (no chyba, że Coldfire to mimo, że generalnie RISCowy to może mieć kod podobny ze względu na zmienną długość słowa, ARM korzystający z Thumb2 też). Tylko to nie ma najmniejszego znaczenia, bo realnym ograniczeniem jest silnik, a nie to czy gaz, benzyna czy diesel.
22.09 09:25
[#107]
Re: Apollo A6000 "Unicorn"
Jestem jednym z kupców tego sprzętu, reklama na facebooku wyskoczyła na tyle fartownie, że kupiłem już szóstą sztukę. Skoro wszyscy się dziwią czemu ktoś to kupuje, to już tłumaczę. Jak szedłem na studia niemal 20 lat temu to Amiga trafiła do szafy, bo nie było opcji targać tego do akademika w innym mieście. I tak też leży w tej szafie do dziś, uruchomiona zaledwie parę razy. Zwyczajnie nie mam na nią miejsca. To A1200 więc więcej miejsca niż sześćsetka, karta turbo Apollo 040/40 ma dwa sloty na RAM, ten górny powoduje, że nie da się zamknąć pokrywy i jest cały czas zdjęta, a strach było go odlutowywać. Dodatkowo na zewnątrz wywleczony dysk 3,5", zasilacz Amigowy, CD-ROM, zasilacz pecetowy, bo nie pamiętam już dokładnie o co chodziło, ale wpinało się jakieś dodatkowe zasilanie w okolicach stacji dysku. To zajmuje z kineskopowym Philipsem cały stół. Nie mam na to miejsca, ale też nie mam czasu, aby się w to wszystko teraz zgłębiać - co zrobić, żeby podpiąć normalny monitor, zastąpić FDD czytnikiem kart celem łatwiejszego przerzucania danych z PC, zastąpić HDD kartą CF - od groma zabawy i pewnie przed emeryturą nie będzie ku temu okazji. Móc postawić przed sobą niewielką A600(0), którą podepnę do monitora i tak stojącego na biurku to jest rzecz po prostu nieporównywalna. Wtedy można sobie w wolnej chwili dłubać i sprawdzać jak to działa, a córce pokazać przeszłość w bardziej rzeczywistym wydaniu. Grać za wiele raczej nie będę, chodzi bardziej o ciekawość tak naprawdę.
22.09 14:47
[#109]
Re: Apollo A6000 "Unicorn"
@waldiamiga, post #108
Może to potrwać i zapewne będzie napisane w sposób, który nie odpowie na wszystkie pytania, nie siedzę w systemie od mnóstwa lat, zatrzymałem się na OS 3.1, nie miałem do czynienia z PPC i GFX i zwyczajnie nie będę umiał tego sprzętu Apollo porównać z obecnymi wariacjami, ale postaram się trochę tutaj wrzucić.
22.09 18:45
[#110]
Re: Apollo A6000 "Unicorn"
@abcdef, post #106
To tak liczac to AC68080 ma tez AMMX, i tam zdaje sie 4 operacje na wordach mozna na raz robic.
Chyba raczej musza byc zwykle MIPS-y podane, albo jakis uniwersalny program dzialajacy na roznych procesorach.
Nie widzialem nigdy kodu skompilowanego na ARM, wiec nie wiem jak jest duzy.
Ale kod PPC jest okolo 2x wiekszy niz kod 68k lub x86.
Zreszta osoby, ktore kupia Settlers 2, beda mogly sobie porownac wielkosc exekow dla WarpOS i AmigaOS.
A skoro twierdzisz, ze kod PPC bedzie tak samo duzy jak kod ARM.
Choc wcale nie musi tak byc, bo ARM moze miec lepsze ISA, i lepsze uzycie rejestrow niz PPC.
To w takim razie to jest jakis problem natury technicznej z PPC.
Typu, ze ma za duzy pobor mocy i za bardzo sie grzeje.
Przez to nadaje sie do latania w kosmos itp zastosowan, a nie do malych komputerow jak laptopy.
Chyba raczej musza byc zwykle MIPS-y podane, albo jakis uniwersalny program dzialajacy na roznych procesorach.
Nie widzialem nigdy kodu skompilowanego na ARM, wiec nie wiem jak jest duzy.
Ale kod PPC jest okolo 2x wiekszy niz kod 68k lub x86.
Zreszta osoby, ktore kupia Settlers 2, beda mogly sobie porownac wielkosc exekow dla WarpOS i AmigaOS.
A skoro twierdzisz, ze kod PPC bedzie tak samo duzy jak kod ARM.
Choc wcale nie musi tak byc, bo ARM moze miec lepsze ISA, i lepsze uzycie rejestrow niz PPC.
To w takim razie to jest jakis problem natury technicznej z PPC.
Typu, ze ma za duzy pobor mocy i za bardzo sie grzeje.
Przez to nadaje sie do latania w kosmos itp zastosowan, a nie do malych komputerow jak laptopy.
22.09 19:36
[#114]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #110
Doprawdy nie wiem co będzie miało do rzeczy czy binarka ma megabajt czy dwa w momencie gdy cała gra wymaga np. 300mb ;) Pomijając DLL to taki BG2EE exec ma 12MB. 12MB! A gra ma ze 2,5GB. To wiesz co zmieniłaby binarka 25MB? Nic. A to przecież tylko odświeżynka gry z 2000/2001r!
Jak pisałem takie rzeczy mogły mieć znaczenie jak gra odpalała się z dyskietki 880KB na 512KB RAMu. A nie gdy masz TB przestrzeni dyskowej i ponad 256MB RAM. Nie świrujmy bo nie ma powodu. PPC słusznie poszło na śmietnik historii bo nikt się nie przyłożył żeby było inaczej. A w czasach G4 ta architektura mogła być rozpropagowana szeroko i z dobrym efektem. Ale tak się nie stało. Tak jak Amiga nigdy nie podbiła światowych rynków. Nie ma co płakać. Ale też nie ma co tworzyć historii na nowo typu "a co gdyby". Gdyby Amiga nie umarła w 94 to nie byłoby SAGA jak wydaje się Gunnarowi. Nie byłoby też nowego 68k. Plan był jasny. Hombre na PA-RISC. To nie mogło się udać i by się nie udało. I dalej byłaby dyskusja w co iść po upadku Commodore. I znów by padło na jakieś rozwiązanie inne niż intel (i nie łudźmy się, ARM, który wtedy nie nadawał się do desktopa). Czyli znów byłoby jakieś rozwiązanie, którego Gunnar by nie trawił. Jak np. SuperH czy MIPS. Więc co mamy dziś.
Mamy wizję Gunnara z dopakowanym 68k i chipsetem. Mamy rozwinięcie wizji H&P czyli PPC z kartami graficznymi, akceleracją 3D i dekodowaniem wideo. Co potrafi AC? Nooo... od biedy zdaje się mpeg2. Co potrafi kupny sterownik do Radeonów w AOS4? No chyba relatywnie nowe formaty i ubogą wersję OpenGLa. Hmm... Jedno i drugie rozwiązanie zdecydowanie z ubogim cost/performance... A wiesz co ja lubię? A ja lubię OCS/AGA. Jak będę chciał nowe ficzery i super duper wydajność to odpalę pieca. Dla mnie najistotniejsze rzeczy to takie, które pozwalają lepiej, łatwiej, TANIEJ wydobywać z Amisi to co najlepsze. Np. rgb2hdmi czy Tom, czy A314...
Ostatnia aktualizacja: 22.09.2025 19:50:02 przez abcdef
Jak pisałem takie rzeczy mogły mieć znaczenie jak gra odpalała się z dyskietki 880KB na 512KB RAMu. A nie gdy masz TB przestrzeni dyskowej i ponad 256MB RAM. Nie świrujmy bo nie ma powodu. PPC słusznie poszło na śmietnik historii bo nikt się nie przyłożył żeby było inaczej. A w czasach G4 ta architektura mogła być rozpropagowana szeroko i z dobrym efektem. Ale tak się nie stało. Tak jak Amiga nigdy nie podbiła światowych rynków. Nie ma co płakać. Ale też nie ma co tworzyć historii na nowo typu "a co gdyby". Gdyby Amiga nie umarła w 94 to nie byłoby SAGA jak wydaje się Gunnarowi. Nie byłoby też nowego 68k. Plan był jasny. Hombre na PA-RISC. To nie mogło się udać i by się nie udało. I dalej byłaby dyskusja w co iść po upadku Commodore. I znów by padło na jakieś rozwiązanie inne niż intel (i nie łudźmy się, ARM, który wtedy nie nadawał się do desktopa). Czyli znów byłoby jakieś rozwiązanie, którego Gunnar by nie trawił. Jak np. SuperH czy MIPS. Więc co mamy dziś.
Mamy wizję Gunnara z dopakowanym 68k i chipsetem. Mamy rozwinięcie wizji H&P czyli PPC z kartami graficznymi, akceleracją 3D i dekodowaniem wideo. Co potrafi AC? Nooo... od biedy zdaje się mpeg2. Co potrafi kupny sterownik do Radeonów w AOS4? No chyba relatywnie nowe formaty i ubogą wersję OpenGLa. Hmm... Jedno i drugie rozwiązanie zdecydowanie z ubogim cost/performance... A wiesz co ja lubię? A ja lubię OCS/AGA. Jak będę chciał nowe ficzery i super duper wydajność to odpalę pieca. Dla mnie najistotniejsze rzeczy to takie, które pozwalają lepiej, łatwiej, TANIEJ wydobywać z Amisi to co najlepsze. Np. rgb2hdmi czy Tom, czy A314...
Ostatnia aktualizacja: 22.09.2025 19:50:02 przez abcdef
22.09 20:07
[#116]
Re: Apollo A6000 "Unicorn"
@amikoksu, post #115
Amiga jako platforma stoi w miejscu. Są różne wizje "jak mogła się rozwijać" i każda ma swoje plusy. Każda ma też swoje minusy. Ale Amiga jako to co znamy i kochamy się nie rozwija. Rozwija się szereg dodatków do niej, a trwa w ten czy inny sposób amigowa społeczność. Niemniej - nie ukrywajmy - to aktualnie garstka funkcjonalnych komputerów i nieco szersza rzesza jej wielbicieli.
23.09 21:43
[#118]
Re: Apollo A6000 "Unicorn"
@abcdef, post #114
Roznica jest taka, ze 2 razy wiekszy exek potrzebuje 2 razy wiekszy cache, zeby dorownac w szybkosci dzialania innym procesorom (zakladajac, ze maja podobne taktowanie i podobne MIPSy).
Czyli po pierwsze jest drozszy w produkcji, a po drugie zawsze bedzie wolniejszy przy tym samym cache i duzych programach.
A nowe programy to juz sa duze "kobyly".
A co do AC68080 i A6000 to chetnie bym zobaczyl ile MIPS-ow pokazuje teraz SysInfo.
Bo dla V2 to bylo 149 Mips.
Dla V4 192 Mips.
Jesli to bedzie ze 300 Mips to postep bylby bardzo duzy.
Czyli po pierwsze jest drozszy w produkcji, a po drugie zawsze bedzie wolniejszy przy tym samym cache i duzych programach.
A nowe programy to juz sa duze "kobyly".
A co do AC68080 i A6000 to chetnie bym zobaczyl ile MIPS-ow pokazuje teraz SysInfo.
Bo dla V2 to bylo 149 Mips.
Dla V4 192 Mips.
Jesli to bedzie ze 300 Mips to postep bylby bardzo duzy.
23.09 22:44
[#119]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #118
Chyba czytasz ludziom w myślach, Don🙂 Zacytujmy autora tego całego zamieszania:
'Nasza jednostka CPU 68080 może osiągać szczytowo 6 instrukcji na cykl zegara, a przy częstotliwości 100 MHz daje to szczytową wydajność 600 Mips.
600 Mips to wartość maksymalna - zależy ona od rodzaju instrukcji w programie. Na przykład dla naszych testowych instrukcji:
ADD.l #12345,D0
ADD.l #44512,A0
68080 może wykonać 3 takie instrukcje na cykl.
Oznacza to, że dla tych instrukcji osiągnie szczytowo 300 Mips.
300 Mips w tym zestawie oznacza 600 razy szybszą pracę niż Amiga 500.
Albo około 10 razy szybszą niż akcelerator CPU Phase5 z procesorem 68060.
To bardzo szybkie osiągi jak na Amigę.' (Gunnar)
'Nasza jednostka CPU 68080 może osiągać szczytowo 6 instrukcji na cykl zegara, a przy częstotliwości 100 MHz daje to szczytową wydajność 600 Mips.
600 Mips to wartość maksymalna - zależy ona od rodzaju instrukcji w programie. Na przykład dla naszych testowych instrukcji:
ADD.l #12345,D0
ADD.l #44512,A0
68080 może wykonać 3 takie instrukcje na cykl.
Oznacza to, że dla tych instrukcji osiągnie szczytowo 300 Mips.
300 Mips w tym zestawie oznacza 600 razy szybszą pracę niż Amiga 500.
Albo około 10 razy szybszą niż akcelerator CPU Phase5 z procesorem 68060.
To bardzo szybkie osiągi jak na Amigę.' (Gunnar)
24.09 05:50
[#120]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #118
A ja myślę, że szukasz na siłę usprawiedliwień. Raz, że binarki nie są generalnie 2x większe, 2 że nie potrzebują 2x więcej cache, bo z drugiej strony stały rozmiar instrukcji pozwala m.in. lepiej przewidywać jaki kawałek pamięci do tego cache trzeba wrzucić. A trzy - "down the pipe it's all risc" ;)
Rozbudowane dekodery wymagające zajedwabistych układów predykcji też nie są za darmo ;) ARM jest RISC, ma relatywnie kompaktowy kod jak na RISC i może mieć (bo sam w sobie nie ma i nie jest to zasługa ISA) dużą wydajność. Czemu ciągle zakładać, że samo bycie 68k spowoduje, że coś jest zajedwabiście dobre? Sorry, ale Gunnar robił też przy PPC i jak on ma jakieś dziwne urazy które chce "wyleczyć" atakując PPC na każdym kroku to spoko, ale to tylko o nim świadczy, że nie potrafił "poprawić" PPC w trakcie kariery zawodowej tak jak poprawia 68k hobbystycznie (no, prawie hobbystycznie, bo jednak to jest jakiś biznes na boku).
Czyli po pierwsze jest drozszy w produkcji
Rozbudowane dekodery wymagające zajedwabistych układów predykcji też nie są za darmo ;) ARM jest RISC, ma relatywnie kompaktowy kod jak na RISC i może mieć (bo sam w sobie nie ma i nie jest to zasługa ISA) dużą wydajność. Czemu ciągle zakładać, że samo bycie 68k spowoduje, że coś jest zajedwabiście dobre? Sorry, ale Gunnar robił też przy PPC i jak on ma jakieś dziwne urazy które chce "wyleczyć" atakując PPC na każdym kroku to spoko, ale to tylko o nim świadczy, że nie potrafił "poprawić" PPC w trakcie kariery zawodowej tak jak poprawia 68k hobbystycznie (no, prawie hobbystycznie, bo jednak to jest jakiś biznes na boku).