Komentowana treść: Emu68 - M68K na RaspberryPi
[#31] Re: Emu68 - M68K na RaspberryPi

@mschulz, post #30

Czy twoje rozwiazanie nie przypomina Amiathlona ? Bedzie mozliwosc odpalenia aos 3.9 ?
[#32] Re: Emu68 - M68K na RaspberryPi

@Sventevith, post #31

Czy twoje rozwiazanie nie przypomina Amiathlona ? Bedzie mozliwosc odpalenia aos 3.9 ?


Moje rozwiazanie zaczelo powstawac tam gdzie amithlon mial dotrzec ale mu sie nie udalo. Amithlon korzystal z linuksa ale w przyszlosci mial krok po kroku z dodatkowego systemu operacyjnego rezygnowac. Ponadto amithlon chyba jednak troche chipsetu emuluje.

Bedzie mozliwosc odpalenia aos 3.9 ?


W tej chwili nie, bo kickstart bez chipsetu nie zadziala. Ale wszystkie nowe platformy na ARM maja wiecej niz jeden rdzen CPU. Jezeli ktos sie odwazy i napisze emulator chipsetu korzystajacy np. z jednego z wolnych w tej chwili rdzeni procesora to czemu nie, moze cos zadziala.

Ale to piesn dalekiej przyszlosci. Na razie musze dokonczyc FPU i CPU.
[#33] Re: Emu68 - M68K na RaspberryPi

@mschulz, post #32

Pomysł super. Rozwój AROSA 68k też może dzięki temu przyśpieszy.
[#34] Re: Emu68 - M68K na RaspberryPi

@Sventevith, post #33

Mnie najbardziej w AROS-ie (Icaros Desktop) brakuje tego, że nie można od tak sobie odpalić aplikacji 68k wprost z systemu (i pisanej pod system, żeby nie było, a nie pod układy specjalizowane, jak to jest w przypadku MOS-a czy AOS4). I trzeba stawiać kompletne środowisko 3.x w Amibridge. Więc może w tym nadzieja.
[#35] Re: Emu68 - M68K na RaspberryPi

@MUFA-amigaone-pl, post #28

Podeslij obraz z systemem 3.1 z quakiem zainstalowanym to zrobie testy na 3b i 4 bo mi sie nie chce znowu workbencha konfigurować ani szukać quake na amige na torrentach
[#36] Re: Emu68 - M68K na RaspberryPi

@mschulz, post #30

Zbedna zaczepka, zupelnie nie na miejscu.


Po prostu próbowałem dociec skąd człowiek, który jako jeden z nielicznych w naszym środowisku zwykł odpowiadać technicznie na techniczne pytania (za co go szanuję, mimo iz nie jest w drużynie AmigaOS), nagle wyskoczył z z dziwnym i niepasującym do innych wypowiedzi z ostatnich nastu lat, tekstem "o czuciu się zaatakowanym".

Moja uwaga, na miejscu czy nie, cały czas mam nieodparte wrażenie że trafiłem w punkt. No ale mniejsza o to bo tak naprawdę dziś zdalem sobie sprawę, że nie na miejscu było moje pytanie o Quake. To tylko pokazuje że te wszystkie opowiastki o MIPSach potrafią wprowadzić w błąd, nawet doświadczonego amigowca.

Abstrahując od tych 1400 MIPSów i opierając się tylko na tych 300 MIPSach podawanych dla Rasspberry PI 4 w SysInfo można by uznać że taki Quake, to bułka z masłem na śniadanie. Tymczasem dziś czytam na forum PPA, że w rzeczywistości pod UAE procek dławi się już przy produkcjach dla A500, typu State Of Art.

Zatem moje pytanie o Quake można uznać za nieważne, gdyż Malina w czwartej wersji nie jest żadną konkurencją dla produktów A-EONu, nie tylko uwzględniając Petunię, ale nawet i E-UAE.
[#37] Re: Emu68 - M68K na RaspberryPi

@MUFA-amigaone-pl, post #36

1. A po co na emulowanej amidze odpalać port quake jak można odpalić port quake na raspberry (i to samo pytanie, po co na X5000 odpalać port 68k? ma to taki sens jak ślepemu okulary założyć).
2. state of the art działa wyśmienicie i wcale się nie dławi, nie wiem kto tak kolegę okłamał. Właśnie przed momentem sprawdzałem na NanoPi M4 (2 rdzenie A72 i 4 A53, czyli najszybsze o dość podobnej wydajności do RPi4).
3. a kto pisał, że RPi4 jest konkurencją dla produktów A-EONu? To sam kolega sobie założył, taki amigowy don kichot, nie ma wroga to trzeba sobie znaleźć.
4. Przeciętny (IBM) PC (compatible) w cenie do 2000zł kładzie w emulacji Amigi 68k produkty A-EON, w natywnych aplikacjach też nie jest inaczej. A do tego ma większe możliwości rozbudowy i jest kompatybilny z większą ilością softu. Jak już porównujemy jabłka z pomarańczami to dodajmy i grejpfruta. A co!
[#38] Re: Emu68 - M68K na RaspberryPi

@abcdef, post #37

Przeciętny (IBM) PC (compatible) w cenie do 2000zł kładzie w emulacji Amigi 68k produkty A-EON, w natywnych aplikacjach też nie jest inaczej.


He hee heee... No chiba nie za bardzo. Były kiedyś takie benchmarki i w natywnych aplikacjach PPC Intele i AMD wypadły słabo, oj, słabo:



(żeby nie było - na wykresie im dłuższy słupek tym dłużej się benchmark robił).
[#39] Re: Emu68 - M68K na RaspberryPi

@recedent, post #38

W jakich natywnych ... daj link to zrobię. Nie na 2.4GHz starym intelu i z całą pewnością nie na 4GHz wyśrubowanym low IPC AMD netburst-like. Przypominam, OGR, RC5 i lame już parę miesięcy temu ogrywaliśmy na R5 1400 oraz Cortex A72.

Ostatnia aktualizacja: 02.12.2019 17:05:49 przez abcdef
[#40] Re: Emu68 - M68K na RaspberryPi

@abcdef, post #39

Przypominam, OGR, RC5 i lame już parę miesięcy temu ogrywaliśmy na R5 1400 oraz Cortex A72.


Hę? Od kiedy na Cortex A72 chodzi emulowany AmigaOS 4.1 FE?
[#41] Re: Emu68 - M68K na RaspberryPi

@recedent, post #40

Hę, a od kiedy ma chodzić? Mowa była o NATYWNYCH aplikacjach jeśli zapomniałeś (co dziwne, bo sam wytłuściłeś ten fragment). I jeszcze raz - do jakiej aplikacji rzekomo miałbym emulować PowerPC? Bo chyba nie Quake PPC skoro chodzi natywnie na x86 (w końcu na niego powstał) a także jest dostępny port dla ARM. W natywnych aplikacjach obecne x86 są szybsze od wykastrowanego powerpc z X5000. W emulacji 68k też są szybsze. A ARMy są wystarczająco szybkie by emulować klasyka i jego gry. Nie wiem czemu ktoś porównuje produkty A-EON z RPi4, ale skoro porównuje to mnie kurka chyba też wolno. I jak ten AmigaOne X5000 wtedy wygląda? Natywne apki? To może coś co każdy w jakiś tam sposób wykorzystuje. Pakowanie plików? Nakładanie filtrów w GIMP? Kodowanie x.264?

Ostatnia aktualizacja: 02.12.2019 17:36:12 przez abcdef
[#42] Re: Emu68 - M68K na RaspberryPi

@abcdef, post #41

Mowa była o NATYWNYCH aplikacjach jeśli zapomniałeś (co dziwne, bo sam wytłuściłeś ten fragment)


A, bo z logiki Twojej wypowiedzi wynikało mi, że chodzi o natywne aplikacje PPC (zresztą - napisałem o tym dwa posty temu - ale nie wytłuściłem, więc mogłeś nie zauważyć). To chyba jasne, że natywne aplikacje pod Intela/x64 (nowe, desktopowe procesory) będą chodzić szybciej niż ich odpowiedniki pod PowerPC (czyli albo desktopowe konstrukcje sprzed 15 lat, albo bardziej współczesne, ale celowane w zupełnie inny rynek - chyba że weźmiemy jako porównanie do testów te 22-rdzeniowe potwory od Talosa na POWER9).

A wracając do tematu - skoro mowa o pakowaniu plików/nakładaniu filtrów/kodowaniu x.264 to Emu68 raczej nie sprawdzi się w porównaniu do PowerPC (chyba że naprawdę słabych PPC).

EDIT: A swoją drogą - chciałbym zobaczyć ten benchmark Krakena (ulubiony test jubiego) odpalony na przeglądarce pod wspomnianym ultraszybkim, emulowanym 68k.

Ostatnia aktualizacja: 02.12.2019 18:10:24 przez recedent
[#43] Re: Emu68 - M68K na RaspberryPi

@abcdef, post #37

1. A po co na emulowanej amidze odpalać port quake jak można odpalić port quake na raspberry (i to samo pytanie, po co na X5000 odpalać port 68k? ma to taki sens jak ślepemu okulary założyć).


Po nic. Tyle że przypominam iż dyskusja jest w watku o emulacji 68k. Zatem zakładając że dyskutujemy na poziomie (czyli bez wyskakiwania z przytykami na temat logicznego myślenia, o okłamywaniu czy Don Kichocie) oraz że dyskutujemy na temat (czyli nie o natywnym Quake na ARMa, a właśnie o emulacji 68k), postanowiłem zadać to niewinne pytanie. Przyznam że nie sądziłem że wśrod niektorych fanów Maliny wywoła to tak ostrą reakcję i wycieczki personalne.

2. state of the art działa wyśmienicie i wcale się nie dławi, nie wiem kto tak kolegę okłamał.


Ja nikomu z góry nie przypisuję złych intencji. Jeśli jednak uważasz że forumowicz infboras to jakiś wyrafinowany kłamca, to idż z nim walcz do tego wątku, gdzie podał m.in.i nformację:

- FS-UAE - taki zwykły 2.8.3 z APTa - słabo. State of the art zabija CPU.

Nie sądzę aby zmyślał, zwłaszcza że w rzeczonym wątku udziela się kilku innych userów Maliny i nikt poza Tobą nie zarzucił mu kłamstwa.

3. a kto pisał, że RPi4 jest konkurencją dla produktów A-EONu? To sam kolega sobie założył, taki amigowy don kichot, nie ma wroga to trzeba sobie znaleźć.


Na przykład tutaj masz jeden z całej serii podobnych artykułów, gdzie zwolennik Maliny, widzi ją jako nową Amigę NG. Tak więc skoro piszą, to ja jako użytkownik aktualnej Amigi NG, dociekam czy stoją za tym racjonalne argumenty, poza ceną i "chciejstwem". Jednym z kluczowych argumentow jest z pewnością wydajność.


4. Przeciętny (IBM) PC (compatible) w cenie do 2000zł kładzie w emulacji Amigi 68k produkty A-EON, w natywnych aplikacjach też nie jest inaczej. A do tego ma większe możliwości rozbudowy i jest kompatybilny z większą ilością softu. Jak już porównujemy jabłka z pomarańczami to dodajmy i grejpfruta. A co!


Oczywiście, jak każdy rasowy troll możesz też dodać gadaninę o arbuzach i bananach, że nie ma to nic wspólnego z tematem emulacji 68k na ARMach, to przecież dla takich jak Ty najmniejszy problem. Grunt by wdeptać w ziemię przeciwnika, ktory śmiał dociekać i zadawać jakieś konkretne (być może niewygodne) pytania względem platformy X czy Y.

Jak już pisałem wcześniej, nie rusza mnie to kompletnie, przerabiałem to po stokroć z niebieskimi, mogę i przerobić z nawiedzonym zwolennikiem Maliny. Skoro już stałem się obiektem Twojej krucjaty, to wiem że żadnymi argumentami Cięnie przekonam, ale by nie wywoływać brednioserialu, do którego być może zaraz przyłączyą się kolejne osoby, mam dwa zdania do innych fanów tego komputerka.

Nie mam nic przeciwko Raspberry PI i nie mam nic do użytkownikow tej maszynki. Cieszcie się swoim hobby, emulacją tych czy innych maszyn. Moje pytania nie byly żadną próbą ataku, a wyrazem ciekawości. Po prostu nie mam w domu tego sprzętu i w najbliższym czasie nie zamierzam go kupować, co nie znaczy że nie śledzę dedykowanych wątków i nie mam ochoty na poszerzanie swojej wiedzy na temat Maliny.
[#44] Re: Emu68 - M68K na RaspberryPi

@recedent, post #42

Tylko widzisz, niektórzy nie rozumieją o co w temacie chodzi. Emu68 to jak jest jasno opisane emulator samego procesora. On rzeczywiście może być zdecydowanie szybszy niż emulowane 68k w emulatorach AMIGI (klasycznej) bo te emulują oprócz procesora jeszcze sporo rzeczy. A sam JIT 68k dla ARM nie jest specjalnie mocno rozwijany, w końcu też jest od względnie niedawna ;) Dodatkowo parcie na prędkość to też poluzowanie takich rzeczy jak ilość cykli instrukcji itp. Jeśli nie trzeba się trzymać krzemowego pierwowzoru to zwyczajnie da się jeszcze szybciej. I dochodzimy do sedna. Jak dobrze rozumiem początkowo chodziło o [bARMowego AROSa[/b]. Z biegiem czasu gdy chłopaki zaczęli eksperymentować z dopałką do Amigi na Cortex M7 (rdzeń mikrokontrolera, nie mikroprocesor!) pewnie powstał pomysł by spróbować emulować procesor (+ podsystem pamięci) na ARM - sprzęt nie jest bardzo drogi, jest dostępny od ręki w dużych ilościach i (zakładając, że Emu68k zaoferuje odpowiednią wydajność) zawsze można przenieść na większy rdzeń z większymi możliwościami, a dodatkowo pozostaje opcja odpalania natywnego softu ARM z wykorzystaniem amigowego chipsetu korzystając ze zdecydowanie dojrzalszych kompilatorów C/C++ niż ma 68k (czyli także używać chipsetu do wyświetlania grafiki a rdzenia ARM do jej generowania). Dla kogoś innego taki JIT jeśli będzie dobry to może stanowić serce kompletnego emulatora, o czym zresztą też była mowa. Wtedy pozostałe rdzenie emulowałyby chipset, a jeden dedykowany byłby tylko do procesora. I nie ma tu żadnej walki z produktami A-EON, bo niby po co i o co? Chodzi o względnie popularny i dostępny sprzęt spełniający założenia. Bo gdyby iść rzeczywiście w wydajność to tak jak pisałem rdzeń e5500 się chowa nie tylko przed Ryzenem, ale nawet laptopowymi i5. POWER to inna bajka, ale nie łudź się, nawet w POWER9 nieraz x86 ustępuje, a sytuacje odwrotne raczej nie są zachętą dla użytkowników domowych, bo ilu z nas potrzebuje ultra krótkiego tworzenia i przełączania wątków?
https://www.phoronix.com/scan.php?page=article&item=power9-epyc-xeon&num=2
Wszystko jednostki z 64 wątkami sprzętowymi. To serwery. Dla użytkownika domowego jest dostępny "w sklepie za rogiem" Ryzen z boostem do 4.4GHz czego chyba nie oferuje żaden "cywilny" POWER9 (przy czym o ile dobrze rozumiem P9 ma boost do 4.0 max aktualnie, w każdym razie nie znalazłem szybszych). Chełpienie się wydajnością PPC w tych czasach jest niepoważne. A wyśmiewanie czyjejś inicjatywy tylko dlatego, że procesor jest słabszy niż PPC (a platforma wielokrotnie tańsza i łatwiej dostępna) jest tym bardziej niepoważne.
[#45] Re: Emu68 - M68K na RaspberryPi

@MUFA-amigaone-pl, post #43

Nie sądzę aby zmyślał, zwłaszcza że w rzeczonym wątku udziela się kilku innych userów Maliny i nikt poza Tobą nie zarzucił mu kłamstwa

I znów tworzysz mitomanię, gdzie niby zarzuciłem komuś kłamstwo? Napisałem wyraźnie "u mnie działa, na sprzęcie podobnej wydajności". Jestem prawie pewien, że na H2+ Allwinnera też by działało. Nie pomyślałeś, że wina mogła być po stronie sterowników, konfiguracji, stanów energetycznych, nagrzania maliny? Nie, lepiej przyjąć bezrefleksyjnie jako aksjomat "state of the art TNIE NA RPI4". Ale widać nie czytałeś do końca, bo w komentarzu #75 częściowo sprawa się rozjaśniła.
masz jeden z całej serii podobnych artykułów, gdzie zwolennik Maliny, widzi ją jako nową Amigę NG

Oczywiście, że widzi bo ma ku temu powody.
1. RPI jest tanie
2. powszechnie dostępne
3. z zarąbistym community o kilka rzędów większym od amigowców
4. ma dość bogate wsparcie i dokumentację
Jak to wygląda z produktami Apollo-team lub A-EON? Aha. Ok.
Oczywiście nie zmienia to faktu, że PPC ma w miarę przyzwoity system, a Coffin też nie jest aż tak bardzo do tyłu. Niemniej to były, są i nadal będą nisze. RPI-Amiga zresztą też, ale zawsze to więcej ludzi, którzy z nią się zetkną i coś pogrzebią, powiedzą dalej ... Lepsze to niż zamknąć się w enklawie, przykryć dłońmi uszy i "lalalalalalalala".
Oczywiście, jak każdy rasowy troll możesz też dodać gadaninę o arbuzach i bananach, że nie ma to nic wspólnego z tematem emulacji 68k na ARMach

Co ma emulacja 68k na PPC wspólnego z tematem emulacji 68k na ARMach? Hipokryto sam zacząłeś!
[#46] Re: Emu68 - M68K na RaspberryPi

@abcdef, post #44

Tylko widzisz, niektórzy nie rozumieją o co w temacie chodzi. Emu68 to jak jest jasno opisane emulator samego procesora. On rzeczywiście może być zdecydowanie szybszy niż emulowane 68k w emulatorach AMIGI (klasycznej) bo te emulują oprócz procesora jeszcze sporo rzeczy.


Nie tylko to. Emulator m68k w eUAE nie pracuje na calej pamieci widzianej przez procesor hosta tylko ma wydzielony swoj wlasny blok RAM-u. Oznacza to tyle ze kazdy dostep do pamieci m68k musi byc "przetlumaczony" na dostep do tego bloku, co wymaga dodatkowych instrukcji. Emu68 nie emuluje nawet tego - emulowany m68k widzi dokladnie ta sama przestrzen adresowa co host. Oznacza to ze na przyklad takie niewinne
move.l 4.w, a6

zostanie przetlumaczone na przyklad na cos takiego:
mov r0, #4
ldr r1,[r0]

bez zbednych dodatkow. Takie podejscie ma oczywscie swoje wady i nie zadzialalo by gdyby emulator mial pracowac pod kontrola jakiegokolwiek systemu operacyjnego. Ale na malinie nie mam tego problemu, po prostu nie mam systemu operacyjnego, Emu68 to "kernel". Po wiecej szczegolow na temat "bebechow" Emu68 odsylam do kolejnego numeru Amiga NG.

Dodatkowo parcie na prędkość to też poluzowanie takich rzeczy jak ilość cykli instrukcji itp.


Nie mam czegos takiego jak ilosc cykli instrukcji. Emu68 traktuje kod m68k jak strumien danych do "skompilowania" i wykonania. Jezeli jakies instrukcje zostana pominiete lub wykonane odmiennie od pierwowzoru to jest to ok o ile efekt pracy danego bloku instrukcji ARM daje identyczny wynik jak przetlumaczony fragment kodu m68k.

I nie ma tu żadnej walki z produktami A-EON, bo niby po co i o co?


Nigdy nie walczylem ani nie konkurowalem z produktami A-EON tak samo jak nie walczylem i nie konkurowalem z AmigaOS4/Hyperionem. Bo i po co? Mam inne podejscie do oprogramowania, inny target, inna filozofie systemu. Milo by bylo oczekiwac podobnego traktowania mnie albo teamu AROS-a z tej drugiej, czerwonej developerskiej strony, ale by sie offtop zrobil.

PS. Jezeli kotos bedzie zainteresowany porownaniem wydajnosci Emu68 z innymi emulacjami m68k to wkrotce bedzie to mozliwe. Koncze przenoszenie generatora fraktala Buddhabrot na AmigaOS. Dokladnie ten sam kod testuje pod moim emulatorem z jedna tylko roznica - ja rysuje bezposrednio po framebufferze, pod AmigaOS bede musial z cybergraphics.library skorzystac. Procesorozerny fragment bedzie dokladnie ten sam.

Ten sam generator fraktali mozna zobaczyc w akcji pod 64-bitowym AROSem tutaj: https://www.youtube.com/watch?v=lMaFfL95nok
Testowalem wersje wykorzystujaca odpowiednio 4,3,2 i 1 rdzen procesora (tak tak, to jeden z arosowych testow smp). Prosze zauwazyc ze wersja na 1 rdzen (natywny kod x86) tworzy rysunek 900x900 pikseli w mniej wiecej 27 sekund. Ten sam kod w wersji m68k uruchomionej na RasPi 4B potrzebuje 155 sekund dla obrazka 800x800 pikseli.

Ostatnia aktualizacja: 02.12.2019 20:55:19 przez mschulz

Ostatnia aktualizacja: 02.12.2019 20:56:04 przez mschulz
[#47] Re: Emu68 - M68K na RaspberryPi

@mschulz, post #46

Fraktal pod Emu68 wyglada tak:



Generowal sie 317 sekund (bo to RasPi 3B+), srednio na jedna instrukcje cpu m68k Emu68 wygenerowal 5,24 instrukcji dla ARM, lacznie z przerzucaniem kontekstu m68k z/do rejestrow ARM na poczatku i koncu tlumaczonych blokow. Pomijajac te drobnostki wychodza srednio 3,77 instrukcje ARM na jedna instrukcje m68k. Mniej juz nie bedzie, architektura RISC jest granica.
[#48] Re: Emu68 - M68K na RaspberryPi

@mschulz, post #47

No spoko, ilość instrukcji wygenerowanych na jedną 68k to jeden problem, drugi to obłożenie ALU w ARMie (innymi słowy jak po przetłumaczeniu i przeliczeniu będzie wyglądało IPC emulowanego 68k względem zegara bazowego ARM). Jeśli na A53 (RPi3) będzie z tym słabo to na A72 czy 73 w sumie można się spodziewać większej wydajności głównie za sprawą wyższej częstotliwości pracy. Dziwi mnie tylko czemu aż tak dużo instrukcji potrzeba na FPU.
[#49] Re: Emu68 - M68K na RaspberryPi

@abcdef, post #48

Dziwi mnie tylko czemu aż tak dużo instrukcji potrzeba na FPU.


Dlaczego duzo? Wiele instrukcji FPU typu rejestr-rejestr tlumaczonych jest 1:1 na arm (fadd, fsub, fneg, fmul, fdiv, fsqrt), czasami trzeba jeszcze flagi w FPSR odpowiednio do wyniku obliczen ustawic. To co jest dluzsze to ladowanie z adresu do rejestru - tryb double na arm musi byc na ARM wyrownany do 4 bajtow, na 68881 nie musi - trzeba to obejsc. Poza tym konwersja miedzy int i single/double zajmuje kilka instrukcji. Trybu Extended jeszcze nie mam, prace sa w toku.

TO co duzo zajmuje to instrukcje typu fsin/fcos, ale to raczej oczywiste :)
[#50] Re: Emu68 - M68K na RaspberryPi
szanowne towarzystwo zapraszam do oglądnięcia tego zdjęcia mojej maliny 3

https://www.instagram.com/p/B4Myrg1F7qF/

to wytrzymuje do około 75% ciągłego, jednostajnego obciążenia CPU

bez czegoś takiego to maleństwo szybko się przegrzewa i muli niesamowicie na rekomendowanym chłodzeniu, tuż koło 50% mocy

wszystko powyżej to musi być chłodzenie aktywne

do czego zmierzam,

jak chcecie porównywać wydajność czegokolwiek - najpierw optymalizacja maliny

Ostatnia aktualizacja: 03.12.2019 20:33:52 przez rwks
[#51] Re: Emu68 - M68K na RaspberryPi

@rwks, post #50

A po co taka rzeźba gdy są dedykowane chłodzenia do maliny? ;) Malina gorąca? Weź tableta czy smartfona i niech coś robi mocniej obciążającego proca to ci jajka usmaży :P
[#52] Re: Emu68 - M68K na RaspberryPi

@rwks, post #50

A ja mam takie coś link i wygląda, że daje radę
[#53] Re: Emu68 - M68K na RaspberryPi

@abcdef, post #45

Nowa Amiga NG? Nie.

Po pierwsze, wartości niematerialne czyli historia, wspomnienia.
PowerPC jest z nami od dwudziestu paru lat. To o PowerPC w Amidze pisał Magazyn Amiga, a to coś znaczy.

Po drugie, życie.
- to tylko emulator
- to ten sam ARM co w robocie
- po co skoro można na tym uruchomić Androida i zrobić wszystko pod Androida sto razy szybciej
[#54] Re: Emu68 - M68K na RaspberryPi

@swinkamor12, post #53

A po co PPC w amidze skoro na PowerMacu z OSX można zrobić więcej, lepiej i szybciej? ;) Trollolollo, dajesz dajesz...
[#55] Re: Emu68 - M68K na RaspberryPi

@swinkamor12, post #53

Widzę że jesteś fanem Amigi i natywnych rozwiązań dla tego komputera, dlatego zachęcam Cię i jestem wręcz pewien, że jako prawdziwy miłośnik, to zrobisz, do wsparcia mojego projektu, którego celem jest radykalne zwiększenie ilości dedykowanego oprogramowania na Amigi. Tutaj adres strony, na której możesz to zrobić OK
[#56] Re: Emu68 - M68K na RaspberryPi

@abcdef, post #54

A po co PPC w amidze skoro na PowerMacu z OSX można zrobić więcej, lepiej i szybciej?

Nie wiesz o czym piszesz. To nawet nie jest śmieszne.
Między Os X na ppc a najnowszym Androidem który działa na RPI jest kilkanaście lat różnicy.
[#57] Re: Emu68 - M68K na RaspberryPi

@swinkamor12, post #56

A między funkcjonalnością OSX a AOS4? :) Nie potrafisz czytać ze zrozumieniem, szkoda, właśnie dlatego trollujesz
[#58] Re: Emu68 - M68K na RaspberryPi

@smith, post #55

Miałem kiedyś Amigę 1200. a1200 ma za wolną grafikę. Nic się nie da zrobić. Szkoda Twojego czasu. Jedyne co może pomóc to zmiana grafiki na lepszą.
[#59] Re: Emu68 - M68K na RaspberryPi

@abcdef, post #57

Porównywanie sytuacji na ppc gdzie są dwa zabytki a na ARM gdzie Android to mainstream jest głupie po prostu.
[#60] Re: Emu68 - M68K na RaspberryPi

@swinkamor12, post #59

Hueh, no amiga jest jeszcze większym, ale nic nie stoi na przeszkodzie by mogła wykorzystać coś nowszego, coś lepszego niż 68000@7MHz czy 68EC020@14MHz. Widzisz, kiedyś istniały takie wynalazki gdzie komputer wkładałeś w komputer żeby mieć szybszy komputer (blizzard w amidze i płyta z pentium w slocie płyty z 486 czy Sonnet Crescendo z G4 na PCI). Albo wynalazki z adapterami Socket 7 na Socket 5, Pentium overdrive, Pentium II overdrive, FCPGA@SLOT1 itp. Było zapotrzebowanie, był zbyt. Z punktu widzenia społeczności amigowej jest zapotrzebowanie i na wynalazki pokroju MiSTera, Vampire 4 standalone, jak i na wynalazki pokroju Warp 1260, Vampire 4 1200 czy wreszcie cokolwiek innego co tchnie choć trochę życia w skostniały zabytek. To, że Ty tego nie rozumiesz mnie nie dziwi, ale też i nie obchodzi. Nie Ty decydujesz.
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