04.10.2016 05:47
[#121]
Re: Apollo CPU - dyskusja
@pisklak, post #118
Mi nie chodzi o to zeby fpu Apollo dzialalo jak fpu 68040/68060, tylko zeby dzialalo lepiej. Ja nie lubie bezsensownych ograniczen. A nie widze zadnego powodu, zeby fpu Apollo nie mialo pelnego 68882 w sobie, tylko jakiegos kastrata. Nawet Krashan w swojej implementacji 68k planuje pelne 68882, za co mu chwala.
04.10.2016 09:03
[#122]
Re: Apollo CPU - dyskusja
@Don_Adan, post #121
Ale należy pamiętać o tym, że implementacja funkcji trygonometrycznych i wykładniczych to i tak będzie coś w rodzaju wewnętrznego programu. Takie funkcje implementuje się korzystając z rozwinięcia funkcji w szereg albo przybliżenia wielomianami. To oznacza, że wyliczenie wartości funkcji to kilka - kilkanaście mnożeń i dodawań. Oczywiście zrobienie tego jako mikroprogram wewnętrzny nieco przyspieszy cały taki rozkaz, ale to też kosztuje w zasobach FPGA.
04.10.2016 10:18
[#123]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@Don_Adan, post #121
Hmm... po pierwsze to FPU będzie pipelined czyli chyba jednak będzie lepszy/szybszy niż ten z 040/060. Po drugie to to o czym mówimy dotyczy wykorzystywania tylko i wyłącznie rozkazów 68882 niezaimplementowanych bezpośrednio - analogiczna sytuacja jak w 040/060, a jakoś te procesory działają OK używając bibliotek emulujących. Jak się pisze kod pod 040/060 to tych rozkazów i tak unika się jak ognia raczej. Po trzecie to ten skok do kodu emulującego będzie chyba bezpośrednio do "pamięci FPGA" czy jak to tam zwać (taki wewnętrzny ROM, sorki nie znam się na nazewnictwie tego wszystkiego), więc będzie to niezależne od odpalonego systemu i całkiem niewidoczne dla użytkownika.
Po czwarte to ograniczenia zawsze istnieją. FPGA z gumy nie jest. A jak się ma wielką chęć na upchnięcie w 40k LE CPU+FPU+AGA to trzeba się liczyć z każdą zajętą bramką.
Po czwarte to ograniczenia zawsze istnieją. FPGA z gumy nie jest. A jak się ma wielką chęć na upchnięcie w 40k LE CPU+FPU+AGA to trzeba się liczyć z każdą zajętą bramką.
18.10.2016 09:38
[#124]
Re: Apollo CPU - dyskusja
@Don_Adan, post #121
Pozwoliłem sobie "odkopać" ten wątek, z racji faktu, że Gunnar w dniu wczorajszym na forum Apollo Knowledge w najkrótszy możliwy sposób podsumował obecny stan rozwoju 68080. Ponieważ to informacje z absolutnie pierwszej ręki, to mam nadzieję, że to rozwieje najczęściej powtarzające się wątpliwości odnośnie projektu.
To give you an overview what the Vampire 500 currently includes
Apollo 68080 CPU (100% 68K compatible)
Apollo fully supports _EVERY_ CPU instruction of the 68000/68010/68030/68040/68060
Apollo 68080 supports _ALL_ 68000/68020/680x0 Ea-modes.
Apollo 68080 supports selfmodify code operations.
So code doing this which worked fine on 68000, but fails on 68030/68040 .. can work again on 68080.
Apollo 68080 can max execute up to four 68k instruction per clock cycle.
In Amiga benchmarks the Vampire scores like an 68060 @100-160 MHz
It obvious that APOLLO 68080 is very fast, sometimes for running ancient games the best compatibility comes when running slower.
We test right now a user-selectable "turtle-mode" which allows running e.g Games in a a speed much closer to original.
Vampire2 comes with 128 MB fastmem (memcopy speed ~ 300 MB/sec)
The Vampire2 includes a FAST-ATA IDE-controller, with peak 16 MB/sec. In AMIGA HD benchmarks we measured up to 13 MB/sec peak doing real transfers.
The Vampire2 includes an SD-Card interface for easy data-exchange.
The Vampire2 has digital Video out - SAGA.
Which support many different GFX modes
Up to 1920x1080 with up to 24/32bit per pixel.
(...)
Apollo has its own MMU.
It has more/partly other features than 68K MMU.
As you certainly know previous 68k CPUs had 1 bus.
Apollo is different.
Like some DSP designs APOLLO supports using 2 buses fully in parallel. This more advanced bus design also requires a different MMU.
68882 is a quite old and very slow FPU design.
APOLLO has an 68k compatible FPU which is fully pipelined - and is much more advanced then even the 68060 FPU.
APOLLO's FPU is fully code compatible to 68K FPUs.
The FPU is currently under testing.
[ŹRÓDŁO]
SORRY FOR THE LONG POST. HERE'S A BOING BALL RUNNING ON VAMPIRE:
To give you an overview what the Vampire 500 currently includes
Apollo 68080 CPU (100% 68K compatible)
Apollo fully supports _EVERY_ CPU instruction of the 68000/68010/68030/68040/68060
Apollo 68080 supports _ALL_ 68000/68020/680x0 Ea-modes.
Apollo 68080 supports selfmodify code operations.
So code doing this which worked fine on 68000, but fails on 68030/68040 .. can work again on 68080.
Apollo 68080 can max execute up to four 68k instruction per clock cycle.
In Amiga benchmarks the Vampire scores like an 68060 @100-160 MHz
It obvious that APOLLO 68080 is very fast, sometimes for running ancient games the best compatibility comes when running slower.
We test right now a user-selectable "turtle-mode" which allows running e.g Games in a a speed much closer to original.
Vampire2 comes with 128 MB fastmem (memcopy speed ~ 300 MB/sec)
The Vampire2 includes a FAST-ATA IDE-controller, with peak 16 MB/sec. In AMIGA HD benchmarks we measured up to 13 MB/sec peak doing real transfers.
The Vampire2 includes an SD-Card interface for easy data-exchange.
The Vampire2 has digital Video out - SAGA.
Which support many different GFX modes
Up to 1920x1080 with up to 24/32bit per pixel.
(...)
Apollo has its own MMU.
It has more/partly other features than 68K MMU.
As you certainly know previous 68k CPUs had 1 bus.
Apollo is different.
Like some DSP designs APOLLO supports using 2 buses fully in parallel. This more advanced bus design also requires a different MMU.
68882 is a quite old and very slow FPU design.
APOLLO has an 68k compatible FPU which is fully pipelined - and is much more advanced then even the 68060 FPU.
APOLLO's FPU is fully code compatible to 68K FPUs.
The FPU is currently under testing.
[ŹRÓDŁO]
SORRY FOR THE LONG POST. HERE'S A BOING BALL RUNNING ON VAMPIRE:
Jak karta będzie dostępna i będzie działać przyzwoicie, to pewnie kupię do A500 i kto wie, może zastąpi A1200 na biurku. 
Pytanie kiedy pojawi się słynne: Houston mamy problem. 
29.10.2016 14:34
[#134]
Re: Apollo CPU - dyskusja
@skipp, post #133
Wow, daje radę ten Vampire. Jak będzie dostępna biorę dla A500 lub A1200 :)
Swoją drogą, Vamire2 oparty jest o Altera Cyclone III.
I patrząc tutaj,mogliby zrobić wersję opartą także np. CycloneV:
https://www.altera.com/products/fpga/cyclone-series.html
Albo o inne układy FPGA, nie tylko Cyclone, który jest raczej serią tanią niż wydajną (chociaż nie wiem na ile one są kompatybilne):
https://www.altera.com/products/fpga/overview.html
Swoją drogą, Vamire2 oparty jest o Altera Cyclone III.
I patrząc tutaj,mogliby zrobić wersję opartą także np. CycloneV:
https://www.altera.com/products/fpga/cyclone-series.html
Albo o inne układy FPGA, nie tylko Cyclone, który jest raczej serią tanią niż wydajną (chociaż nie wiem na ile one są kompatybilne):
https://www.altera.com/products/fpga/overview.html
29.10.2016 15:55
[#138]
Re: Apollo CPU - dyskusja
@skipp, post #124
Apollo fully supports _EVERY_ CPU instruction of the 68000/68010/68030/68040/68060
Apollo 68080 supports _ALL_ 68000/68020/680x0 Ea-modes.
Mnie to osobiście martwi. Kroki polegające na wycinaniu instrukcji i trybów adresowania z 68040 i 68060 nie były bezzasadne. Okazało się, że żaden kompilator nie jest w stanie z nich sensownie skorzystać. Dodatkowo niektóre z nich wymuszały użycie mikrokodu w procesorze i / lub ogólnego skomplikowania mikroarchitektury.
Powtarzając za klasycznym podręcznikiem z architektur systemów komputerowych (Computer Organization and Design, Hennessy & Patterson):
- opłaca się optymalizować tylko te instrukcje, które wykonują się najczęściej,
- im zestaw instrukcji jest prostszy i bardziej jednolity tym szybciej można go wykonywać.
Gunther nie dokonał jeszcze podstawowego przełomu w przetwarzaniu instrukcji M68k. Chodzi o dokładnie to samo przejście, które wykonał Intel z Pentium do Pentium Pro – czyli zrobienie procesora wykonującego instrukcje poza porządkiem programu (Out-of-Order execution). Bez tego Apollo Core to tylko 68060 na sterydach uparcie ciągnąca bagaż kompatybilności wstecz.
29.10.2016 17:41
[#141]
Re: Apollo CPU - dyskusja
@cahir, post #138
Apollo to ma być 680x0 na sterydach, z lepszą kompatybilnością wsteczną - w końcu chcemy na tym uruchamiać AmigaOS m68k, aplikacje na ten system i stare gry na Amigę (zazwyczaj pisane w assemblerze) - a nie pisać na to nowoczesny system operacyjny.
Ostatnia aktualizacja: 29.10.2016 17:42:03 przez Cedrat
Ostatnia aktualizacja: 29.10.2016 17:42:03 przez Cedrat
29.10.2016 21:39
[#146]
Re: Apollo CPU - dyskusja
@Andrzej Drozd, post #144
Cyberświat zmienił się przez ostatnie 15 lat... coraz bardziej dbamy o bezpieczeństwo.
Amigę chroni znikoma popularność, niewielka moc obliczeniowa i retro-zastosowania; haker, który włamie się do podłączonej do sieci Amigi 68k, nie pokopie sobie na niej bitcoinów, nie przechwyci hasła do bankowości elektronicznej (przy pewnej dozie szczęścia - jedynie do poczty elektronicznej). Ransomware też niewiele zdziała - nikt nie trzyma na Amidze jedynej kopii firmowych danych (o ile w ogóle ktokolwiek trzyma coś takiego na Amidze) czy zdjęć z wycieczki życia. Botnetu (np. do DDOSów) też się z Amig nie zrobi, jest ich po prostu zbyt mało. Żaden cybergangsta nie ma więc motywacji, żeby się męczyć z egzotycznym systemem.
Ostatnia aktualizacja: 29.10.2016 21:40:14 przez Cedrat
Amigę chroni znikoma popularność, niewielka moc obliczeniowa i retro-zastosowania; haker, który włamie się do podłączonej do sieci Amigi 68k, nie pokopie sobie na niej bitcoinów, nie przechwyci hasła do bankowości elektronicznej (przy pewnej dozie szczęścia - jedynie do poczty elektronicznej). Ransomware też niewiele zdziała - nikt nie trzyma na Amidze jedynej kopii firmowych danych (o ile w ogóle ktokolwiek trzyma coś takiego na Amidze) czy zdjęć z wycieczki życia. Botnetu (np. do DDOSów) też się z Amig nie zrobi, jest ich po prostu zbyt mało. Żaden cybergangsta nie ma więc motywacji, żeby się męczyć z egzotycznym systemem.
Ostatnia aktualizacja: 29.10.2016 21:40:14 przez Cedrat
29.10.2016 23:17
[#150]
Re: Apollo CPU - dyskusja
@Cedrat, post #146
haker, który włamie się do podłączonej do sieci Amigi 68k, nie pokopie sobie na niej bitcoinówJak się włamie na i7 quad z jakimś odjechanym Radeonem to też sobie nie pokopie, chyba że zadowoli go jakieś 5 groszy rocznie (zakładając, że użytkownik przez rok się nie zorientuje). Czasy kopania bitcoinów komputerami już minęły...