22.03.2016 10:38
[#1]
Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
Zakładam tutaj nowy temat dotyczący softcore CPU Apollo użytego w karcie Vampire żeby nie zaśmiecać dyskusją innego wątku. Uprzejmie proszę o dyskusję na ten temat tutaj.
Czy ten 64 bitowy przykład z kopiowaniem spriteów jest dla koderów czytelny ? I czy moglibyście napisać przykład tej procedury w typowym 68k i PPC ? Być może wtedy będzie łatwiej porównać i zauważyć użyteczność bądź jakiś brak w tych dodatkowych instrukcjach Apollo.
PS. Gunnar twierdzi że PPC tutaj nie będzie miał zachwycających wyników. No chyba że też z jakąś instrukcją AltiVeca.
PS2: link do omawianego kodu kopiowania sprita -> link
Ostatnia aktualizacja: 22.03.2016 10:55:48 przez pisklak
Czy ten 64 bitowy przykład z kopiowaniem spriteów jest dla koderów czytelny ? I czy moglibyście napisać przykład tej procedury w typowym 68k i PPC ? Być może wtedy będzie łatwiej porównać i zauważyć użyteczność bądź jakiś brak w tych dodatkowych instrukcjach Apollo.
PS. Gunnar twierdzi że PPC tutaj nie będzie miał zachwycających wyników. No chyba że też z jakąś instrukcją AltiVeca.
PS2: link do omawianego kodu kopiowania sprita -> link
Ostatnia aktualizacja: 22.03.2016 10:55:48 przez pisklak
22.03.2016 11:54
[#3]
Re: Apollo CPU - dyskusja
@pisklak, post #1
Lepiej byłoby wyjaśnić jak 5 instrukcji jest wykonywanych w jednym cyklu i jak to się udaje, że w tym samym cyklu pamięć jest jednocześnie zapisywana i odczytywana.
A może Gunnar zakłada, że dane sprite leżą już w pamięci cache (wtedy przestają działać ograniczenia pamięci, ale ma to swoje granice)?
A jest jakaś dokumentacja opisująca działanie poszczególnych specyficznych funkcji Apollo? Czy dalej koderzy mają oceniać nieobiektywnie kod Gunnara?
Ostatnia aktualizacja: 22.03.2016 12:01:30 przez sanjyuubi
A może Gunnar zakłada, że dane sprite leżą już w pamięci cache (wtedy przestają działać ograniczenia pamięci, ale ma to swoje granice)?
A jest jakaś dokumentacja opisująca działanie poszczególnych specyficznych funkcji Apollo? Czy dalej koderzy mają oceniać nieobiektywnie kod Gunnara?
Ostatnia aktualizacja: 22.03.2016 12:01:30 przez sanjyuubi
22.03.2016 11:58
[#4]
Re: Apollo CPU - dyskusja
@pisklak, post #1
Na razie nowe 64 bitowe instrukcje mnie nie interesuja za bardzo, bo to sa raczej instrukcje do obslugi grafiki a to nie moja dzialka. Mam 2 uwagi/propozycje:
1. instrukcja moveq powinna dzialac na 64 bitach, czyli np. moveq #0,D0, zeruje caly 64 bitowy rejestr D0, a nie tylko mlodsze 32bity, nie wiem jak jest teraz w Apollo.
2. kiedys Gunnar chcial wprowadzic instrukcje swapa, np. swapa A0, bo byl nieuzywany opcode na to, taka instrukcja jest jednak prawie nieuzyteczna. Ale jakby uzyc tego samego opcodu dla instrukcji swapl, czyli np. swapl D0, to by to byla pozyteczna instrukcja, czyli zamiana 32 bitow w rejestrze z mlodszych na starsze i ze starszych na mlodsze. Wiec jak ten opcode jest wolny to taka instrukcja powinna zostac dodana do Apollo.
1. instrukcja moveq powinna dzialac na 64 bitach, czyli np. moveq #0,D0, zeruje caly 64 bitowy rejestr D0, a nie tylko mlodsze 32bity, nie wiem jak jest teraz w Apollo.
2. kiedys Gunnar chcial wprowadzic instrukcje swapa, np. swapa A0, bo byl nieuzywany opcode na to, taka instrukcja jest jednak prawie nieuzyteczna. Ale jakby uzyc tego samego opcodu dla instrukcji swapl, czyli np. swapl D0, to by to byla pozyteczna instrukcja, czyli zamiana 32 bitow w rejestrze z mlodszych na starsze i ze starszych na mlodsze. Wiec jak ten opcode jest wolny to taka instrukcja powinna zostac dodana do Apollo.
22.03.2016 12:25
[#6]
Re: Apollo CPU - dyskusja
@Don_Adan, post #5
No powiedzmy, że tak to będzie wyglądać po fuzji.
Jednak, jeżeli coś jest robione w pętli złożonej z dwóch instrukcji, to automatycznie tracisz połowę procesora, bo w jednej instrukcji robisz zawartość pętli, a w drugiej do niej powracasz. Operując na 32-bitowych danych i mając do dyspozycji zegar 100MHz, zwalniasz abstrakcyjnie do 50MHz, przy takiej prędkości, tylko czytając z pamięci masz transfer 200Mb/s, jak chcesz do tego zapisywać, to masz już 100MB/s kopiowania. Zwiększając rozmiar danej do 64-bit, teoretycznie zwiększasz prędkość kopiowania z powrotem do 200MB/s, ale szyna danych pamięci musiałaby także posiadać te 64-bit, inaczej znów wracamy do 100MB/s.
Tak samo przy operacjach na rejestrach, jeśli w jednym cyklu możesz przenieść 64-bit wartość z jednego rejestru do drugiego, to przy pseudo 50MHz masz właśnie 400MB/s, ale jest to transfer chwilowy i do tego wewnętrzny, nie ma realnego odniesienia do wydajności pamięci, bo ta będzie pracować 2 razy wolniej w naszym wypadku.
Myślę, że to co Gunnar miał na myśli, to z jaką prędkością procesor operuje na danych, czyli, odczyt danej 400MB/s - operacje na 64-bit rejestrze, modyfikacja, zapis wyniku 400MB/s - zapis do pamięci 400MB/s. Wtedy te 400MB/s mają sens, jednak prędkość kopiowania pamięci to dalej 200MB/s. Sekretem wydajności będzie tutaj fuzja i operacja na 64-bit danej, a nie wydajność RAM. Przesiadka na 64-bitową pamięć lub ewentualnie DDR, pozwoliłaby na skrócenie ładowania 64-bitowych danych do rejestrów o połowę.
Ostatnia aktualizacja: 22.03.2016 12:42:06 przez sanjyuubi
Jednak, jeżeli coś jest robione w pętli złożonej z dwóch instrukcji, to automatycznie tracisz połowę procesora, bo w jednej instrukcji robisz zawartość pętli, a w drugiej do niej powracasz. Operując na 32-bitowych danych i mając do dyspozycji zegar 100MHz, zwalniasz abstrakcyjnie do 50MHz, przy takiej prędkości, tylko czytając z pamięci masz transfer 200Mb/s, jak chcesz do tego zapisywać, to masz już 100MB/s kopiowania. Zwiększając rozmiar danej do 64-bit, teoretycznie zwiększasz prędkość kopiowania z powrotem do 200MB/s, ale szyna danych pamięci musiałaby także posiadać te 64-bit, inaczej znów wracamy do 100MB/s.
Tak samo przy operacjach na rejestrach, jeśli w jednym cyklu możesz przenieść 64-bit wartość z jednego rejestru do drugiego, to przy pseudo 50MHz masz właśnie 400MB/s, ale jest to transfer chwilowy i do tego wewnętrzny, nie ma realnego odniesienia do wydajności pamięci, bo ta będzie pracować 2 razy wolniej w naszym wypadku.
Myślę, że to co Gunnar miał na myśli, to z jaką prędkością procesor operuje na danych, czyli, odczyt danej 400MB/s - operacje na 64-bit rejestrze, modyfikacja, zapis wyniku 400MB/s - zapis do pamięci 400MB/s. Wtedy te 400MB/s mają sens, jednak prędkość kopiowania pamięci to dalej 200MB/s. Sekretem wydajności będzie tutaj fuzja i operacja na 64-bit danej, a nie wydajność RAM. Przesiadka na 64-bitową pamięć lub ewentualnie DDR, pozwoliłaby na skrócenie ładowania 64-bitowych danych do rejestrów o połowę.
Ostatnia aktualizacja: 22.03.2016 12:42:06 przez sanjyuubi
22.03.2016 12:49
[#7]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@sanjyuubi, post #6
Myślę, że to co Gunnar miał na myśli, to z jaką prędkością procesor operuje na danych, czyli, odczyt danej 400MB/s - operacje na 64-bit rejestrze, modyfikacja, zapis wyniku 400MB/s - zapis do pamięci 400MB/s.
Myślę że dokładnie to miał Gunnar na myśli jeśli chodzi o te 400MB. A jeśli chodzi o to że PPC nie będzie błyszczał w tego typu procedurze to już ja nie wiem o co chodzi, trzeba by pytać kogoś kto zna PPC. Dobrze by było kod PPC zobaczyć z jakimś opisem czy coś podobnego.
22.03.2016 12:58
[#8]
Re: Apollo CPU - dyskusja
@sanjyuubi, post #6
A i jeszcze musisz pamiętać, że fuzja pierwszych trzech instrukcji nie wykona się w jednym cyklu, a w dwóch, bo odczyt 64-bitowej danej z 32-bitowej pamięci będzie trwał dwa cykle, chyba, że ta dana znajduje się już w pamięci cache. Tak samo fuzja dwóch ostatnich, bo zapis do pamięci będzie znów trwał 2 cykle (chyba, że cache pracuje w trybie copyback, ale te dane i tak muszą w końcu trafić do RAM z powrotem). Wynika z tego, że zaproponowany kod wykona się 2-3-4 cyklach zegarowych (przy 64-bit pamięci byłyby to dwa cykle zawsze).
22.03.2016 13:00
[#9]
Re: Apollo CPU - dyskusja
@pisklak, post #7
No i właśnie dlatego mi to nie pasowało, bo prędkość przetwarzania danych, to nie to samo co prędkość kopiowania. Przy 64-bit pamięci lub DDR (lepsza ta pierwsza) , prędkość odczytu danej 64-bitowej wynosiłaby 800MB/s, a i sam cache ładowałby dane i instrukcje przy takiej prędkości, dlatego po sukcesie VV2, można byłoby się pokusić o zrobienie kroku dalej. W PC bitowość pamięci zwiększa się poprzez dodanie kanałów, a 64-bit to norma od czasów SD-RAM.
200MB/s kopiowania to i tak sporo w połączeniu z fuzjami, 68060 ze swoimi powolnymi simmami, maksymalnie 2 instrukcjami na cykl i operacji na liczbie 64bit, wypadnie zauważalnie gorzej. Prędzej PPC będzie starało się dorównać i wyniki mogą być podobne jeśli kod wykona się z cache, jednak mam mieszane uczucia co do wydajności samych pamięci simm (nie mówię o PPC z NeoAmig).
Ostatnia aktualizacja: 22.03.2016 13:12:06 przez sanjyuubi
200MB/s kopiowania to i tak sporo w połączeniu z fuzjami, 68060 ze swoimi powolnymi simmami, maksymalnie 2 instrukcjami na cykl i operacji na liczbie 64bit, wypadnie zauważalnie gorzej. Prędzej PPC będzie starało się dorównać i wyniki mogą być podobne jeśli kod wykona się z cache, jednak mam mieszane uczucia co do wydajności samych pamięci simm (nie mówię o PPC z NeoAmig).
Ostatnia aktualizacja: 22.03.2016 13:12:06 przez sanjyuubi
22.03.2016 15:36
[#11]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@sanjyuubi, post #9
Vampire to dopiero początek. W przyszłości planowane jest użycie lepszej FPGA (prawdopodobnie jakiejś C5) i oczywiście szybszej pamięci, bo ta która jest teraz to już saturacji będzie dostawać. Wszystko zależy od tego jak potoczą się losy Vampira. Zresztą nawet te 200MB/s powinno spokojnie wystarczyc do gierc 2D jak myślę.
22.03.2016 22:29
[#13]
Re: Apollo CPU - dyskusja
@pisklak, post #11
Zależy jeszcze w jakiej rozdzielczości te gry będą działać, ale mocy teoretycznie jest wystarczająco, aby zrobić coś bardzo sensownego w dziedzinie 2D lub czegoś pomiędzy Q1, a Q2.
Ciekawe, czy ktoś pokusiłby się przeportować jakiś emulator automatów, np. MAME (wersja z 2001r na Aminecie) lub NeoGeo i zobaczyć jak to będzie się sprawować.
Zastanawiam się czy procesora Gunnara nie dałoby rady rozreklamować w świecie elektroniki (DEV boardy FPGA lub rdzeń przystosowany do jakiegoś popularnego FPGA DEV boarda robiący z niego Amigę, byłaby to taka powolniejsze alternatywa dla R-PI), grupa odbiorców by się wtedy rozrosła.
Ciekawe czy AMOSowcy mają zamiar coś pisać pod VV2 (da radę w Amosie obsługiwać RTG, jeśli nie natywnie, to może za pomocą jakichś wstawek?).
Ostatnia aktualizacja: 22.03.2016 22:32:21 przez sanjyuubi
Ostatnia aktualizacja: 22.03.2016 22:35:55 przez sanjyuubi
Ciekawe, czy ktoś pokusiłby się przeportować jakiś emulator automatów, np. MAME (wersja z 2001r na Aminecie) lub NeoGeo i zobaczyć jak to będzie się sprawować.
Zastanawiam się czy procesora Gunnara nie dałoby rady rozreklamować w świecie elektroniki (DEV boardy FPGA lub rdzeń przystosowany do jakiegoś popularnego FPGA DEV boarda robiący z niego Amigę, byłaby to taka powolniejsze alternatywa dla R-PI), grupa odbiorców by się wtedy rozrosła.
Ciekawe czy AMOSowcy mają zamiar coś pisać pod VV2 (da radę w Amosie obsługiwać RTG, jeśli nie natywnie, to może za pomocą jakichś wstawek?).
Ostatnia aktualizacja: 22.03.2016 22:32:21 przez sanjyuubi
Ostatnia aktualizacja: 22.03.2016 22:35:55 przez sanjyuubi
22.03.2016 23:07
[#17]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@michal_zukowski, post #15
Wiesz ja tam się nie znam ale MAME na 68k dalej emuluje programowo te 68k chyba, więc raczej potrzeba wystarczająco dużo mocy do zaemulowania procka i całego chipsetu emulowanej płyty (gry). W każdym razie ile wyciąga 1944 na szybkiej 060 ? Bo jeśli faktycznie by to mało procka potrzebowało to i na 030 powinno działać znośnie.
23.03.2016 00:02
[#19]
Re: Apollo CPU - dyskusja
@pisklak, post #17
Sorry, trudno mi sie przestawic na myslenie o sprzęcie o możliwościach komórek sprzed 10 lat. Wyszedlem z założenie że skoro Vampire2 jest ponoć szybszy niż PPC dla Amigi, a ja grałem w 1944 15 lat temu pod MAME to teraz logiczne, że po 15 latach tez będzie działało ok. Dobrze więc, że działa ok bo inaczej byłby regres.
Z ciekawszych rzeczy mozna by bylo sprawdzić jak sprawuje się UAE. Dla tych prędkości można by bylo poemulować jakąś maszynę z AGĄ (bez dzwięku). a jakby jeszcze dorobili bezposrednie emulowanie procka to juz bylby full wypas i AGA na A600.
Z ciekawszych rzeczy mozna by bylo sprawdzić jak sprawuje się UAE. Dla tych prędkości można by bylo poemulować jakąś maszynę z AGĄ (bez dzwięku). a jakby jeszcze dorobili bezposrednie emulowanie procka to juz bylby full wypas i AGA na A600.
23.03.2016 00:44
[#20]
Re: Apollo CPU - dyskusja
@michal_zukowski, post #19
Z ciekawszych rzeczy mozna by bylo sprawdzić jak sprawuje się UAE. Dla tych prędkości można by bylo poemulować jakąś maszynę z AGĄ (bez dzwięku). a jakby jeszcze dorobili bezposrednie emulowanie procka to juz bylby full wypas i AGA na A600.
nie bardzo rozumiem. to ma byc jakis test? bo jak tak dalej pojdzie age bedziesz mial na 600tce i tak w najblizszej przyszlosci..
23.03.2016 03:49
[#21]
Re: Apollo CPU - dyskusja
@sanjyuubi, post #13
Ciekawe czy AMOSowcy mają zamiar coś pisać pod VV2 (da radę w Amosie obsługiwać RTG, jeśli nie natywnie, to może za pomocą jakichś wstawek?)
Odpowiadając najpierw na drugą część pytania: Technicznie prawdopodobnie jest to możliwe, ale tylko przez asembler, czyli skomplikowanie.
Odpowiadając na pierwszą część: Właśnie przez ten asembler AMOS-owcy nigdy czegoś takiego nie napiszą (jeśli znajdzie się jeden, to tylko potwierdzi regułę). Jako argument podam istnienie AGE, na którym oprócz kilku przykładów samego autora tego dodatku do AMOS-a nie powstało nic, a przynajmniej nic, co zwróciłoby uwagę Amosowców/Amigowców. Osoby wybierające AMOS-a robią to z pełną świadomością - chcą bardzo przystępnego programowania i AMOS spełnia tę potrzebę w 100%. Implementacja asemblera czy innych niskopoziomowych wstawek jest dla nas, że się utożsamię, zbyt trudne i zniechęcające.
Co do wykorzystania mocy V2... Tu zdaje się możnaby zaszaleć. Zdaje się, bo dopóki nikt nie przetestuje jakichś procedur wyświetlających grafikę, to pozostaną tylko spekulacje. Chętnie bym to zrobił, gdybym miał tę kartę...
23.03.2016 09:38
[#22]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@michal_zukowski, post #19
Wiesz nikt tutaj nie twierdzi że Apollo w Vampirce jest szybszy ogólnie od PPC. Można wykazać że w niektórych aspektach jest powiedzmy wydajniejszy per MHz niż PPC nawet te NG co nie oznacza automatycznie że ogólna prędkość jest wyższa. Moim zdaniem jeśli chodzi o moc obliczeniową CPU to w tej chwili jak porównywać do PPC to gdzieś w granicach najsłabszych BlizzardówPPC wychodzi. Co jest i tak świetnym wynikiem. Myślę że da to się jeszcze trochę podciągnąć w lepszej FPGA ale nie oszukujmy się - szału nawet w porównaniu do BlizzardówPPC w samej mocy obliczeniowej to nie będzie. Choć zapewne dodanie FPU i tego Vectora sporo pomoże. W tej chwili chłopaki powoli pracują nad przepisaniem RIVY z wykorzystaniem nowych 64 bitowych rozkazów. Pierwsze wyniki są bardzo obiecujące. Założeniem jest płynne odtwarzanie MPEG w 640x360 i myślę że to jest możliwe nawet bez użycia jednostki typu SIMD.
A AGA i tak niedługo będzie więc nie trzeba się bawić w jej emulowanie.
A AGA i tak niedługo będzie więc nie trzeba się bawić w jej emulowanie.
23.03.2016 09:51
[#24]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@michal_zukowski, post #23
Aga będzie z Natami. A jeśli chodzi Ci o AGĘ i UAE to to już jest zupełnie inna bajka.
Wiesz jak masz sprzęt 1000 razy szybszy to możesz sobie emulować AGA i jeszcze masz moc na 800x szybszy proc - to są zupełnie inne sprawy. No chyba że chodzi Ci o niepełną kompatybilność istniejących reimplementacji AGA w FPGA czy coś podobnego. Ale to jest do poprawienia z biegiem czasu jak sądzę. A na temat AGI z Natami się nie będę wypowiadał za dużo bo nie znam tematu. Wiem że jest i działa podobno całkiem dobrze.
Wiesz jak masz sprzęt 1000 razy szybszy to możesz sobie emulować AGA i jeszcze masz moc na 800x szybszy proc - to są zupełnie inne sprawy. No chyba że chodzi Ci o niepełną kompatybilność istniejących reimplementacji AGA w FPGA czy coś podobnego. Ale to jest do poprawienia z biegiem czasu jak sądzę. A na temat AGI z Natami się nie będę wypowiadał za dużo bo nie znam tematu. Wiem że jest i działa podobno całkiem dobrze.
23.03.2016 13:36
[#26]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@wawrzon, post #25
To nie jest pomyłka. Gunnar ma porozumienie z Tomaszem Hirshem (mam nadzieję że dobrze to napisałem bo z głowy piszę) i może wykorzystać w Vampirce AGA z Natami. Działa to w drugą stronę i Natami może mieć za CPU Apollo. Z tego co wiem AGA w Natami działała całkiem nieźle - chodziło wiele gier itp. Ale szczegółów to już nie znam za bardzo.
W każdym razie wiem że będą chyba takie mieszane tryby dodatkowo jak "chunky over planar", być może szybszy copper. Role blittera przejmie chyba w Vampirce CPU. No ale proszę to jak na razie traktować jako plotkę a nie jakiekolwiek oficjalne info.
W każdym razie wiem że będą chyba takie mieszane tryby dodatkowo jak "chunky over planar", być może szybszy copper. Role blittera przejmie chyba w Vampirce CPU. No ale proszę to jak na razie traktować jako plotkę a nie jakiekolwiek oficjalne info.
28.03.2016 17:54
[#27]
Re: Apollo CPU - dyskusja
@pisklak, post #26
No dobra, na forum Apollo Gunnar napisal:
Apollo has a real 68k FPU which supports all operations 68040 and 68060 did also support like e.g:
FADD, FSUB, FABS, FNEG, FMUL, FDIV, FSQURT, etc etc etc
Apollo FPU is more advanced than 68060 FPU and is fully pipelined.
This means it can execute a new instruction every clock cycle.
Czyli Apollo ma wszystkie instrukcje FPU z 68060 czy wszystkie instrukcje z 68882, bo to nie jest to samo. FPU z 68060 nie ma instrukcji trygonometrycznych, jakis trybow adresowania i jeszcze pewnie czegos, bo sie inzynierom nie miescily, albo byli za slabi, zeby je upchnac, bo Pentium ma zdaje wszystkie instrukcje x87, o ile dobrze slyszalem.
Jak szybkie jest to FPU, najwolniejsze instrukcje ile cykli potrzebuja, bo najszybsze to pewnie 1 cykl, albo 0.5 cykla.
No to FPU jest ilu bitowe 64 czy 80?
Apollo has a real 68k FPU which supports all operations 68040 and 68060 did also support like e.g:
FADD, FSUB, FABS, FNEG, FMUL, FDIV, FSQURT, etc etc etc
Apollo FPU is more advanced than 68060 FPU and is fully pipelined.
This means it can execute a new instruction every clock cycle.
Czyli Apollo ma wszystkie instrukcje FPU z 68060 czy wszystkie instrukcje z 68882, bo to nie jest to samo. FPU z 68060 nie ma instrukcji trygonometrycznych, jakis trybow adresowania i jeszcze pewnie czegos, bo sie inzynierom nie miescily, albo byli za slabi, zeby je upchnac, bo Pentium ma zdaje wszystkie instrukcje x87, o ile dobrze slyszalem.
Jak szybkie jest to FPU, najwolniejsze instrukcje ile cykli potrzebuja, bo najszybsze to pewnie 1 cykl, albo 0.5 cykla.
No to FPU jest ilu bitowe 64 czy 80?
28.03.2016 18:09
[#28]
Re: Apollo CPU - dyskusja
@Don_Adan, post #27
A co do pamieci w Vampire to na amiga.org sa jeszcze stare specyfikacje, podane przez Gunnara, no i karta miala miec pamiec DDR3, czyli 64bitowy odczyt i zapis:
For A500/ A1000/ A2000 / CDTV.
Card specs are:
* very fast 68K CPU
* 128 MB DDR3 Fast-memory
* SD-card usable/bootable as IDE-device
* Network interface
* RTG Graphics Card (chunky/Hicolor/truecolor) with HDMI out
The physial card design is done.
Testing / Driver development needs to be done.
For A500/ A1000/ A2000 / CDTV.
Card specs are:
* very fast 68K CPU
* 128 MB DDR3 Fast-memory
* SD-card usable/bootable as IDE-device
* Network interface
* RTG Graphics Card (chunky/Hicolor/truecolor) with HDMI out
The physial card design is done.
Testing / Driver development needs to be done.
29.03.2016 12:57
[#29]
Re: Apollo CPU - dyskusja
@Don_Adan, post #28
DDR3 świadczy jedynie o technologii wykonania pamięci, czyli głównie z jakimi częstotliwościami pamięć pracuje, dla DDR3 będzie to 800MHz i w górę. Większość takich kostek, nawet DDR3 to układy 16-bitowe, aby uzyskać 64-bit trzeba połączyć "równolegle" 4 takie kości. Vampire nie ma procesora pracującego z taką prędkościa, aby wykorzystać to co oferuje DDR3, zwykły DDR1 (do 200MHz - 400MHz efektywnie) sprawdziłby się tutaj doskonale.
Wygląda na to, że do tego czasu plany się zmieniły, na zdjęciach VV2 widać kości o oznaczeniu IS42S16320B-6TLI, czyli 16-bitowe SD-RAMy znane z V1 z maksymalna częstotliwością pracy równą 166MHz.
Ostatnia aktualizacja: 29.03.2016 12:58:08 przez sanjyuubi
Wygląda na to, że do tego czasu plany się zmieniły, na zdjęciach VV2 widać kości o oznaczeniu IS42S16320B-6TLI, czyli 16-bitowe SD-RAMy znane z V1 z maksymalna częstotliwością pracy równą 166MHz.
Ostatnia aktualizacja: 29.03.2016 12:58:08 przez sanjyuubi