kategorie: A600, Sprzęt
[#1] Reboot systemu na A600 z Vampire V2
[#2] Re: Reboot systemu na A600 z Vampire V2

@] SKOLMAN_MWS ˇ agrEssOr [, post #1

Ooooooo
Nie mogę doczekać wersji do a1200
[#3] Re: Reboot systemu na A600 z Vampire V2

@Sosabowski, post #2

Ja tak samo. Jestem pod wrażeniem. Mam nadzieję, że do czasu wydania 1200 powstanie też zdrowa konkurencja na FPGA.
[#4] Re: Reboot systemu na A600 z Vampire V2

@] SKOLMAN_MWS ˇ agrEssOr [, post #1

[#5] Re: Reboot systemu na A600 z Vampire V2

@Sokok, post #3

Robi wrażenie. A konkurencja... Myślę, że powstanie.
[#6] Re: Reboot systemu na A600 z Vampire V2

@] SKOLMAN_MWS ˇ agrEssOr [, post #1

Robi wrażenie, czas jest aż irracjonalnie krótki - na A1200 sam POST trwa chyba dłużej :P
[#7] Re: Reboot systemu na A600 z Vampire V2

@madman15, post #6

Gdyby rozwój prawdziwej Amigi 68k poszedł jak należy system ta by startował. Do peceta nawet dodanie dysków SSD nie pomaga, bo windows to kobyła i startuje długo...
[#8] Re: Reboot systemu na A600 z Vampire V2

@Voyox, post #7

Chyba ci odrobinę wigilijne % podkolorowują wyobraźnie. Rozwój technologii niesie za sobą rozrastające się oprogramowanie, nowe funkcje dochodzą, a stare trzeba wciąż obsługiwać przez dłuższy czas, alternatywne dla Windows systemy też są kobyłami, tylko, że dziś trzeba załadować do pamięci cały system(700-1000MB; hibernacja pozwala wstać systemowi bardzo szybko na SSD), a workbench cały siedzi w ROMie, startup-sequence tylko go konfiguruje, a rozmiar wczytywanych plików nie przekracza 1MB.


Co do szybkości wczytywania WB przez Vampire, to mnie to jakoś nie zaskoczyło, fakt, że trwa to naprawdę szybko (ok. 2s), ale na 68020 28MHz z kickstartem załadowanym do fastramu i kartą CF o wydajności 2.5MB/s trwa to około 4s. Lepiej byłoby przetestować jakiś classic WB, który w wersji dla ECS na 68000 ładuje się aż 30s.

Byłoby miło, gdyby ktoś przetestował jakiegoś linuksa na tej karcie lub przygotował taki port.

Ostatnia aktualizacja: 24.12.2015 20:41:50 przez sanjyuubi
[#9] Re: Reboot systemu na A600 z Vampire V2

@sanjyuubi, post #8

Nic mi nie podkolorowuje...
Istota tkwi w tym że instrukcje programowania procesorów x86 są rozlazłe jak zakalec.
Dawno temu "fachowcy" od programowania udowadniali że te same programy pisane pod 68k zajmują 10x mniej miejsca na dysku, czyli rozumując tym tokiem szybciej się wykonują i nie wymagają tyle megaherców. Porównywano kiedyś "wagę" plików z tych samych gier i na PC były zawsze dużo większe nie oferując nic lepszego w grze.
Więc pecet, jak to napisałeś potrzebuje teraz "załadować" 1GB na dzień dobry. Zjada żmija swój własny ogon.
[#10] Re: Reboot systemu na A600 z Vampire V2

@Voyox, post #9

Z tą prędkością wczytywania to nie zdążysz przytrzymać dwóch klawiszy myszy :)
[#11] Re: Reboot systemu na A600 z Vampire V2

@] SKOLMAN_MWS ˇ agrEssOr [, post #1

Rzeźnia a raczej Żeźnia.
[#12] Re: Reboot systemu na A600 z Vampire V2

@Voyox, post #9

Te dowody pewnie były równie rozlazłe jak te instrukcje. Jakoś nie wydaje mi się aby na x86 trzeba było wykonać 10 instrukcji aby dodać A do B. Póki nie zobaczę tych "fachowych" wypocin, uznam, że to zwykłe hejterskie majaczenie, ot wystarczy porównać program napisany w assemblerze na 68k i równoważny kod napisany w C++ na x86, aby już napisać taką teoryjkę (przypomina mi się program dla NDS w C, który po skompilowaniu zajmował 7.5kB, a po napisaniu odpowiednika w assemblerze 56 bajtów). Rozumiem, że jak odpalałem WinuAE kiedyś na procesorze pentium 400MHz (emulowało gdzieś 70-80% prędkości A500), to analogicznie podobną wydajność powinienem uzyskać na Amidze z procesorem 40MHz? Gdzie jest to WinUAE działające płynnie na 68060 80MHz?

Dzisiejsza rozlazłość systemów i aplikacji jest spowodowana m.in o wiele większą ilością warstw abstrakcji używanych w środowiskach programistycznych (są jeszcze inne czynniki). Mamy przecież nawet wirtualne środowiska jak Java albo .net framework, to wszystko musi swoje zajmować i swoje z wydajności pożerać.

Ostatnia aktualizacja: 25.12.2015 03:57:08 przez sanjyuubi
[#13] Re: Reboot systemu na A600 z Vampire V2

@] SKOLMAN_MWS ˇ agrEssOr [, post #1

Wiadomo jaki transfer z karty SD uzyskuje ta karta?
[#14] Re: Reboot systemu na A600 z Vampire V2

@Voyox, post #9

Dawno temu "fachowcy" od programowania udowadniali że te same programy pisane pod 68k zajmują 10x mniej miejsca na dysku.

Jak jeszcze kompilowałem DigiBoostera na AROS-a x86, to wyglądało to mniej więcej tak:
  • binarka M68k – rozmiar 100%
  • binarka x86 – rozmiar 150%
  • binarka PPC – rozmiar 200%


Ostatnia aktualizacja: 25.12.2015 09:17:35 przez Krashan
[#15] Re: Reboot systemu na A600 z Vampire V2

@Krashan, post #14

Czyli coś w tym jest. Z palca tego nie wyssałem. Ale to w owym czasie programiści "podniecali" się przejrzystością i uporządkowaniem kodu pod 68k (a raczej procesora MC68000).
Żeby utrzymać intela przy życiu firma IBM (posiadająca wówczas 40% akcji intela) wypuściła swój flagowy projekt (IBM PC) na światło dzienne dla wszystkich chętnych za "free". A raczej nie były to czasy filantropi, tylko chciwego zysku..
[#16] Re: Reboot systemu na A600 z Vampire V2

@Krashan, post #14

No dobra, 150% to nie 1000% i taki wynik jestem w stanie przyjąć, natomiast zadałeś właśnie cios poniżej pasa zwolennikom teorii wyższości PPC nad x86 :) (to nie jest zaczepka)

Swoją drogą, Vampire jest opisywany jako procesor 64-bitowy zgodny wstecznie z rodziną 68k, co by sugerowało, że ma swój własny tryb pracy, ciekaw tylko jestem, czy ktoś przygotuje jakieś GCC pod ten procesor, bo inaczej będzie się marnował.

Procesorem Gunnara mógłby się też zainteresować ktoś z środowiska Atari i zastąpić nim CT63, w innych środowiskach tez byłoby miło go rozpopularyzować, aby nie skończył jako relikt.
[#17] Re: Reboot systemu na A600 z Vampire V2

@Voyox, post #15

Żeby utrzymać intela przy życiu firma IBM (posiadająca wówczas 40% akcji intela) wypuściła swój flagowy projekt (IBM PC) na światło dzienne dla wszystkich chętnych za "free".


No fakt, ale jakim procesorze mówimy? 8-bitowym 8086?

Ostatnia aktualizacja: 25.12.2015 13:18:26 przez sanjyuubi
[#18] Re: Reboot systemu na A600 z Vampire V2

@sanjyuubi, post #16

Ja co PPC mam dziwne "uczucia". Czyżby Motorola przekombinowała? Patrząc wstecz to produkty Apple zawsze były mocno reklamowane a nie było w nich prawdziwego odniesienia do wydajności względem x86. Nawet emulacja środowiska Windows była tam zawsze żenująca.
Co do Vampire 2, to pierwsza próba wskrzeszenia 68k, myślę że bardzo obiecująca. OK
[#19] Re: Reboot systemu na A600 z Vampire V2

@Voyox, post #18

Ciężko byłoby się przebić przez lobby krzemowe, ale myślę, że może procesor gunnara mógłby znaleźć swoje miejsce w świecie mikrokontrolerów, gdyby jeszcze FPGA do Vampira kosztowało 30zł, to byłby cud.

A co do PPC, to czort wie o co z tym chodzi, czy ktoś tam dawał w łapę? Nie było dobrego kompilatora? Aż dziw, że stosowany był w wielu konsolach, choć zawsze był modyfikowany na zlecenie, ale może devkity były bardziej dopracowane niż kompilatory dla zwykłych PPC?
[#20] Re: Reboot systemu na A600 z Vampire V2

@sanjyuubi, post #8

Brednie. Przecież nie od dziś wiadomo, że programiści mają w dupie, aby wydajnie kompilować dany program.
Zawsze można powiedzieć: zmień sprzęt bo masz za wolny. I w ten sposób napędza się kasę. To też jest troszkę cena postępu, ale płacą za to zwykli jelenie nakręcani przez system...
Nie będę setny raz przytaczał drętwych tekstów o Doomie, który nie miał niby prawa działać na 040....
[#21] Re: Reboot systemu na A600 z Vampire V2

@Krashan, post #14

Dawno temu "fachowcy" od programowania udowadniali że te same programy pisane pod 68k zajmują 10x mniej miejsca na dysku.

Jak jeszcze kompilowałem DigiBoostera na AROS-a x86, to wyglądało to mniej więcej tak:

binarka M68k – rozmiar 100%
binarka x86 – rozmiar 150%
binarka PPC – rozmiar 200%


tak. to sa oczekiwane wyniki.
[#22] Re: Reboot systemu na A600 z Vampire V2

@sanjyuubi, post #19

A co do PPC, to czort wie o co z tym chodzi

Bez przesady. W przeciwieństwie do M68k i x86, PowerPC jest procesorem klasy RISC (procesor o zredukowanej liście rozkazów). To pociąga za sobą zastosowanie tzw. architektury load-store. Oznacza to, że wszystkie rozkazy arytmetyczno-logiczne operują tylko na rejestrach procesora. Jeżeli działamy na danych w pamięci, to trzeba je oddzielnymi rozkazami załadować do rejestrów, wykonać działanie, a potem odesłać kolejnym rozkazem wynik do pamięci. Przykładowo na M68k, żeby dodać wartość rejestru "d3" do zmiennej w pamięci adresowanej przez "a2", piszemy jeden rozkaz:

ADD.L d3,(a2)

Na PowerPC, podobnie dodajemy zawartość "r3" do zmiennej adresowanej przez dajmy na to "r9" i niestety wymaga to już trzech instrukcji:

lwz r4,0(r9)
add r3,r3,r4
stw r3,0(r9)
[#23] Re: Reboot systemu na A600 z Vampire V2

@sanjyuubi, post #16

Swoją drogą, Vampire jest opisywany jako procesor 64-bitowy zgodny wstecznie z rodziną 68k, co by sugerowało, że ma swój własny tryb pracy, ciekaw tylko jestem, czy ktoś przygotuje jakieś GCC pod ten procesor, bo inaczej będzie się marnował.

Moim zdaniem takie zabawy są oczywiście bardzo przyjemne, ale ja gdybym robił M68k w FPGA, wziąłbym zestaw instrukcji 68020, wywalił z niego to, czego Amiga nie używa, a następnie poszedł na szybkość. Dodawanie przez nic nie obsługiwanych rozszerzeń i trybów adresowania nie ma sensu innego poza hobbystyczną zabawą. A kosztuje też w "powierzchni" FPGA, a co za tym idzie również jego cenie.
[#24] Re: Reboot systemu na A600 z Vampire V2

@Krashan, post #22

PowerPC jest procesorem klasy RISC


No to wszystko wyjaśnia i trochę zasmuca jednocześnie, ponieważ wymaga jednocześnie wydajniejszej pamięci. Oj, męczą się te procesory z powolnymi simmami na blizzardach. Czysty RISC jest spotykany najczęściej w mikrokontrolerach, ciekawe, czy te konsolowe PPC mają interfejs CISC->RISC.


wziąłbym zestaw instrukcji 68020, wywalił z niego to, czego Amiga nie używa, a następnie poszedł na szybkość.


To nie jest głupi pomysł, jednak rozczarowałby ludzi, którzy chcieliby poodpalać oprogramowanie dla 68060 na AGA (jeśli pojawi się wersja dla A1200), jak Quake w 1280x256.
[#25] Re: Reboot systemu na A600 z Vampire V2

@sanjyuubi, post #24

W istocie jedyną ważną instrukcją, która jest w 68040/68060, a nie ma jej w 68020 jest MOVE16. Można ją dodać i zrobić, żeby procesor zgłaszał się jako 68060. Oczywiście pozostaje jeszcze temat FPU...

Inna sprawa, że ludzie pisali pod 68060 tylko dlatego, że był najszybszy i to nie polegało na wykorzystaniu jakichś magicznych instrukcji (których nie ma), tylko na dopasowaniu potoku instrukcji do wewnętrznej budowy 68060. Przy implementacji procesora w FPGA naśladowanie wewnętrznej konstrukcji oryginalnej 040 albo 060 nie ma żadnego sensu. Z tego co mi wiadomo rdzeń Apollo tak nie robi. Więc może się okazać, że program skompilowany dla 020 będzie na FPGA działał szybciej, niż skompilowany dla 060.

Z punktu widzenia softu tworzonego teraz lub w przyszłości silenie się na 060 nie ma sensu. Ma to wartość tylko dla uruchamiania produkcji scenowych, szansa przekompilowania których jest raczej żadna.
[#26] Re: Reboot systemu na A600 z Vampire V2

@Krashan, post #23

Ciekawe podejscie, tylko ze oprocz callm i rtm raczej wszystkie instrukcje 68020 sa uzywane na Amidze, nawet tas jest tez uzywany w grach. Wiec nie za bardzo wiem co bys chcial wywalic. Miejsca w FPGA jest wystarczajaco, wiec nie ma sensu pomijac jakis instrukcji. Do tego ma to niewielki wplyw, o ile w ogole ma na szybkosc procesora w FPGA, bo ciagle to jest osiemdziesiat pare MHz dla Cyclone III (200 MHz? ). A taka szybkosc wykazywal Apollo bez trybow adresowych 68020 czy instrukcji typu movep, jak ktos widzial stare fotki szybkosci Apollo sprzed ponad roku. Wszystko raczej zalezy od sposobu implementacji instrukcji 68k w FPGA. Skoro Gunnar dal sie przekonac do zaimplementowania wszystkich instrukcji 68040 (czyli w zasadzie wszystkich 68k, bez paru typu callm, rtm), a byl temu przeciwny jakies 2 lata temu na EAB, to tylko chwala mu za to. Jakby jeszcze dodal wszystkie instrukcje 68882 (co tez mu proponowalem), wliczajac trygonometryczne, to taki procesor bylby bardzo dobrym procesorem.
Co sie tyczy PPC to ta architektura jest z zalozenia mniej wydajna niz 68k czy x86. Po prostu na obsluge 32 rejestrow, potrzeba wiecej miejsca niz na obsluge 16 rejestrow dla 68k, co juz daje 2x wiekszy kod. Do tego obsluga 64 bitow tez zwieksza kod. PPC musi miec 2x wiekszy cache, zeby dorownac w szybkosci wykonywania kodu x86. Przy tej samej szybkosci procesora, PPC bedzie zawsze mniej wydajny niz x86 czy tez Apollo.
[#27] Re: Reboot systemu na A600 z Vampire V2

@Krashan, post #25

Nie do konca, przy pisaniu pod 68060, nie mogli uzywac mulu.l czy divu.l (w wersji 64 bitowej) bo to spowalnialoby program czy demo. Rozpoznawanie procesora jako 68060, czyli dodanie obslugi instrukcji PCR, jest wedlug mnie bez sensu bo bedzie sie sprowadzalo do wyboru dluzszej wersji kodu, przynajmniej dla procesora typu Apollo, ktory moze wykonac 3 do 5 (laczonych) instrukcji w jednym cyklu.
[#28] Re: Reboot systemu na A600 z Vampire V2

@Don_Adan, post #26

Możliwe, że nic nie możnaby wywalić, nie robiłem jeszcze szczegółowej analizy. Ale w tej sytuacji wygląda na to, że w zasadzie nie ma różnicy czy się implementuje 68060 czy 68020. Wystarczy sprawdzić jak Amiga rozpoznaje model procesora i zrobić tak, żeby widział FPGA jako 68060. Dokładniej 68EC060, a nawet LC dopóki nie ma koproca.

A co do koproca będzie tylko jeden mały problem, soft który rozpozna procesor jako 68040 nie zrobi użytku z faktu, że rdzeń ma pełen zestaw 68882.
[#29] Re: Reboot systemu na A600 z Vampire V2

@Don_Adan, post #27

Rozpoznawanie procesora jako 68060, czyli dodanie obslugi instrukcji PCR, jest wedlug mnie bez sensu

A co z demami na 060? Jeżeli sprawdza procesor i wychodzi gdy nie wykryje 060 to bryndza. Dla mnie to byłaby rybka, ale pasjonaci sceny mogą się krzywić.
[#30] Re: Reboot systemu na A600 z Vampire V2

@Voyox, post #18

Wręcz przeciwnie. Apple miało całe serie reklam śmiejących się z wydajności inteli i chwalących PPC. Chyba każdy widział reklamę ze ślimaczkiem, ale to tylko jedna z wielu. Na pewno znajdą sie na yt.
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem