Komentowana treść: Richard Drummond, AROS i E-UAE
08.11.2007 15:55
[#32]
Re: Richard Drummond, AROS i E-UAE
@MinisterQ, post #30
A Ty śmiesz temu zaprzeczać? 
Swoją drogą też się zastanawiałem, co takiego więcej daje AROS, czego nie można osiągnąć przy pomocy WinUAE czy Amithlona. Chyba najwięcej da się z WinUAE, niezależnie od sprzętu, chyba zawsze wyciśnie się całą moc do emulacji, nie ma problemów ze sterownikami jak w AROS-ie czy Amithlonie...
Swoją drogą też się zastanawiałem, co takiego więcej daje AROS, czego nie można osiągnąć przy pomocy WinUAE czy Amithlona. Chyba najwięcej da się z WinUAE, niezależnie od sprzętu, chyba zawsze wyciśnie się całą moc do emulacji, nie ma problemów ze sterownikami jak w AROS-ie czy Amithlonie...
08.11.2007 17:22
[#33]
Re: Richard Drummond, AROS i E-UAE
@Dzban, post #31
1.platforma jest ściśle określona od strony np. mostków. Rozwijana przez jedną firmę. A więc łatwość oprogramowania co jest ważne przy małej liczbie dev.
2.Spełnia moje subiektywne oczekiwania na nowoczesny ale mały, ekologiczny, energooszczędny, ekonomiczny w uzyciu komputerek. Dysponujący wystarczającą wydajnością w typowych zastosowaniach.
3.Co do "nędzności" to http://www.via.com.tw/en/initiatives/empowered/pc2500_mainboard/index.jsp
trudno taką płytkę nazwać nędzną. A jest to z całej rodziny model średni.
To jest firma która ma wizję rozwoju, której zabrakło kolejnym właścicielom "Amigi". :)
Myślę że czymś takim powinna być "nowa" Amiga.
Aha. Żeby nie być OT to cieszę się, że właśnie ten człowiek robi to bounty. Jego osoba daje gwarancję sukcesu.
Ostatnia edycja: 08.11.07 17:24:40
2.Spełnia moje subiektywne oczekiwania na nowoczesny ale mały, ekologiczny, energooszczędny, ekonomiczny w uzyciu komputerek. Dysponujący wystarczającą wydajnością w typowych zastosowaniach.
3.Co do "nędzności" to http://www.via.com.tw/en/initiatives/empowered/pc2500_mainboard/index.jsp
trudno taką płytkę nazwać nędzną. A jest to z całej rodziny model średni.
To jest firma która ma wizję rozwoju, której zabrakło kolejnym właścicielom "Amigi". :)
Myślę że czymś takim powinna być "nowa" Amiga.
Aha. Żeby nie być OT to cieszę się, że właśnie ten człowiek robi to bounty. Jego osoba daje gwarancję sukcesu.
Ostatnia edycja: 08.11.07 17:24:40
08.11.2007 17:24
[#34]
Re: Richard Drummond, AROS i E-UAE
@SirLEO, post #32
AROS jest natywny, więc działa znacznie szybciej od Amithlona. Amithlon jest szybszy jeśli chodzi o emulację niż WinUAE. Natomiast WinUAE jest spowalniany przez windowsa, i pomimo że oferuje największą zgodność z klasyczną Amigą, to nie da się za jego pomocą wycisnąć wszystkiego z peceta (warstwa pośrednicząca w postaci Windowsa skutecznie wszystko spowalnia).
Nie ma rozwiązań idealnych. Każde ma swoje wady i zalety.
Nie ma rozwiązań idealnych. Każde ma swoje wady i zalety.
08.11.2007 18:51
[#37]
Re: Richard Drummond, AROS i E-UAE
Moim zdaniem dla AROSa powinien zostać ustalony oficjalny konfig powiedzmy raz na dwa lata (może w przyszłości częściej) do którego byłyby rozwijane drivery i każdy kto by chciał używać AROSa kupowałby właśnie taki sprzęt. Do tego przydałaby się pełna obsługa VirtualPC i VMWare - wiem, że można na nich go uruchomić ale nie wiem czy wszystko działa. Takie podejście załatwiłoby problem driverów i sprzętu.
08.11.2007 18:52
[#38]
Re: Richard Drummond, AROS i E-UAE
@ems, post #35
Chyba większość z nas woli używać soft w wersji natywnej.
No tak, ale poki co, na AROSie nie mozna w ogole uzywac amigowego softu. Nie ma zadnego wyboru. Sukcesem MOSa i AOS4 jest wlasnie emulacja, dzieki ktorej tak latwo mozna przejsc na te systemy i z czasem przyzwyczaic sie do innego, natywnego softu, majac caly czas dostep do ulubionego softu 68k, ktory nie doczekal sie natywnej kompilacji.
Dzieki emulacji na AROSie, moze "ruszy" po prostu MUI. Prawda ze to moze byc ciekawa sprawa? A i moze ktos pobawi sie dzieki temu w kompilacje jakichs natywnych klas?
No tak, ale poki co, na AROSie nie mozna w ogole uzywac amigowego softu. Nie ma zadnego wyboru. Sukcesem MOSa i AOS4 jest wlasnie emulacja, dzieki ktorej tak latwo mozna przejsc na te systemy i z czasem przyzwyczaic sie do innego, natywnego softu, majac caly czas dostep do ulubionego softu 68k, ktory nie doczekal sie natywnej kompilacji.
Dzieki emulacji na AROSie, moze "ruszy" po prostu MUI. Prawda ze to moze byc ciekawa sprawa? A i moze ktos pobawi sie dzieki temu w kompilacje jakichs natywnych klas?
08.11.2007 19:02
[#39]
Re: Richard Drummond, AROS i E-UAE
@MinisterQ, post #34
Amithlon jest szybszy jeśli chodzi o emulację niż WinUAE. Natomiast WinUAE jest spowalniany przez windowsa
O ile wiem Amithlon siedzi na linuxie więc jest przez niego spowalniany - jak to ująłeś. A ponieważ Windows jest szybszy niż linux więc jest to większe spowolnienie.
Z drugiej strony nie wiem czy o czymś takim jak spowalnianie można w ogóle mówić w takiej sytuacji ponieważ to co robi Windows/linux i tak musi zostać zrobione. Inna kwestia zachodzi gdy porównujemy to do działania natywnego. Wtedy należałoby zbadać czy AOS działa szybciej niż Windows/linux co jest całkiem prawdopodobne zważywszy na to, że jest prostszy i nie musi za dużo mieszać podczas IPC czy innych operacji.
08.11.2007 19:29
[#40]
Re: Richard Drummond, AROS i E-UAE
@smith, post #39
O ile wiem Amithlon siedzi na linuxie więc jest przez niego spowalniany - jak to ująłeś.
Byyzyydura. ;) Ponieważ w tym przypadku jedyne co jest używane z linuksa jako takiego, to kernel, i ewentualnie jakieś proste sterowniki do sprzętu (najczęściej obsługa DMA czy dźwięku). Na tym kernelu działa tylko jeden proces - proces emulacji procesora m68k. To wszystko. Dalej - Amithlon ma bezpośredni dostęp do hardware peceta - dotyczy to między innymi kart graficznych.
W przypadku WinUAE mamy do czynienia z emulacją wszystkiego - procesora, środowiska - słowem całego sprzętu. W związku z czym AmigaOS uruchomiony na WinUAE nie ma bezpośredniego dostępu do fizycznego sprzętu - jedynie do emulowanego. Sterowniki AHI czy Picasso96 w WinUAE odwołują się do API Windowsa.
Polecam lekturę źródeł WinUAE - jest bardzo porywająca pod tym względem. ;)
Więc w przypadku Amithlona jest spora różnica. To zresztą widać, można to również zmierzyć programami testującymi.
to co robi Windows/linux i tak musi zostać zrobione.
Owszem, ale lepiej by było zrobione raz, a nie dwa, lub więcej razy (HAL windowsa).
Byyzyydura. ;) Ponieważ w tym przypadku jedyne co jest używane z linuksa jako takiego, to kernel, i ewentualnie jakieś proste sterowniki do sprzętu (najczęściej obsługa DMA czy dźwięku). Na tym kernelu działa tylko jeden proces - proces emulacji procesora m68k. To wszystko. Dalej - Amithlon ma bezpośredni dostęp do hardware peceta - dotyczy to między innymi kart graficznych.
W przypadku WinUAE mamy do czynienia z emulacją wszystkiego - procesora, środowiska - słowem całego sprzętu. W związku z czym AmigaOS uruchomiony na WinUAE nie ma bezpośredniego dostępu do fizycznego sprzętu - jedynie do emulowanego. Sterowniki AHI czy Picasso96 w WinUAE odwołują się do API Windowsa.
Polecam lekturę źródeł WinUAE - jest bardzo porywająca pod tym względem. ;)
Więc w przypadku Amithlona jest spora różnica. To zresztą widać, można to również zmierzyć programami testującymi.
to co robi Windows/linux i tak musi zostać zrobione.
Owszem, ale lepiej by było zrobione raz, a nie dwa, lub więcej razy (HAL windowsa).
08.11.2007 19:40
[#41]
Re: Richard Drummond, AROS i E-UAE
@smith, post #36
No właśnie jak już mówiłem, w przypadku AROSa to "więcej sprzętu", to tylko pozornie więcej sprzętu. Bo odnosi się to tylko do obsługiwanego w danej chwili - najczęściej już odrobinę "leciwego".
Faktem oczywiście jest że jest na rynku dostępna znacznie większa ilość wyprodukowanych podzespołów w zakresie danej konfiguracji... Samych szumblasterów czy innych realteków wyprodukowano więcej niż wszystkich A1, Pegasosów, czy innych pociotków.
Faktem oczywiście jest że jest na rynku dostępna znacznie większa ilość wyprodukowanych podzespołów w zakresie danej konfiguracji... Samych szumblasterów czy innych realteków wyprodukowano więcej niż wszystkich A1, Pegasosów, czy innych pociotków.
08.11.2007 19:56
[#42]
Re: Richard Drummond, AROS i E-UAE
@MinisterQ, post #40
Ponieważ w tym przypadku jedyne co jest używane z linuksa jako takiego, to kernel, i ewentualnie jakieś proste sterowniki do sprzętu (najczęściej obsługa DMA czy dźwięku). Na tym kernelu działa tylko jeden proces - proces emulacji procesora m68k. To wszystko.
Na procesorze jedno rdzeniowym zawsze działa jeden proces. Jeżeli pozostałe są w stanie wait to ich obecność nie ma wpływu na prędkość działania.
Dalej - Amithlon ma bezpośredni dostęp do hardware peceta - dotyczy to między innymi kart graficznych.
A czy driver Picasso dla WinUAE nie jest tylko wrapperem na API Windowsa więc wnosi sam z siebie niewielki narzut? Różnica w takim wypadku polega na tym że w wypadku WinUAE sterowanie przechodzi jeszcze przez GDI co może wnieść spowolnienie jednak za to driver pod Windowsem na pewno jest lepszy i bardziej wykorzystuje hardware karty co w efekcie może dać lepszą wydajność.
W przypadku WinUAE mamy do czynienia z emulacją wszystkiego - procesora, środowiska - słowem całego sprzętu.
Amithlon musi robić to samo.
W związku z czym AmigaOS uruchomiony na WinUAE nie ma bezpośredniego dostępu do fizycznego sprzętu - jedynie do emulowanego.
Amithlon też musi wprowadzać emulację przecież. Do tego jak już napisałem wyżej pod Windowsem najprawdopodobniej będzie to działać szybciej.
Więc w przypadku Amithlona jest spora różnica. To zresztą widać, można to również zmierzyć programami testującymi.
Chętnie bym to sprawdził.
08.11.2007 20:28
[#43]
Re: Richard Drummond, AROS i E-UAE
@smith, post #42
Na procesorze jedno rdzeniowym zawsze działa jeden proces. Jeżeli pozostałe są w stanie wait to ich obecność nie ma wpływu na prędkość działania.
Jest różnica pomiędzy okrojonym kernelem linuksa na którym działa tylko jeden proces, a kernelem windowsa, który musi obsługiwać w cholerę rzeczy. Nie zamierzam się tu spierać o szczegółowe dane, niemniej w tym przypadku na korzyść Amithlona przemawia po prostu logika.
Poza tym to po prostu widać, zwłaszcza w sytuacjach gdy windows sobie zeswapuje pamięć którą używa WinUAE - w tym również pamięć graficzną...
A czy driver Picasso dla WinUAE nie jest tylko wrapperem na API Windowsa więc wnosi sam z siebie niewielki narzut?
Tak, można powiedzieć że to jest "tylko" wrapper, który tworzy amigowe "sterowniki" za pomocą DirectX.
Różnica w takim wypadku polega na tym że w wypadku WinUAE sterowanie przechodzi jeszcze przez GDI co może wnieść spowolnienie jednak za to driver pod Windowsem na pewno jest lepszy i bardziej wykorzystuje hardware karty co w efekcie może dać lepszą wydajność.
To założenie iż jest "lepszy" nie jest poparte niczym, ponad wiarę w dogmat o niesamowitości obsługi sprzętu przez windows, i jego wszystkie warstwy abstrakcji razem wzięte.
Już samo naoczne porównanie operacji na oknach pod Amithlonem czy WinUAE pozostawia WinUAE daleko w tyle. Nie mam teraz odpowiedniego sprzętu pod Amithlona, więc niestety nie mogę zrobić żadnego testu, by unaocznić liczbami jak bardzo dostaje w dupę WinUAE na tle Amithlona i operacji graficznych, a szkoda.
Amithlon musi robić to samo.[...] Amithlon też musi wprowadzać emulację przecież.
A niby po jaką cholerę? Jeśli już, to na pewno nie na takim poziomie, i z takim rozmachem jak WinUAE.
Na amithlonie nie uruchomisz nic co się odwołuje do klasycznego amigowego hardware.
Amithlon emuluje tylko procesor, i podstawowe środowisko sprzętowe (takie pierdoły jak obsługa myszy, czy klawiatury, lub dostęp do dysku), dając przy okazji niczym nie blokowany dostęp do rejestrów sprzętowych blaszaka.
Takie rzeczy jak sterowniki do kart graficznych to natywny kod x86, wykorzystujący wspomaganie sprzetowe karty.
Widać że nigdy na oczy nie widziałeś Amithlona.
Jest różnica pomiędzy okrojonym kernelem linuksa na którym działa tylko jeden proces, a kernelem windowsa, który musi obsługiwać w cholerę rzeczy. Nie zamierzam się tu spierać o szczegółowe dane, niemniej w tym przypadku na korzyść Amithlona przemawia po prostu logika.
Poza tym to po prostu widać, zwłaszcza w sytuacjach gdy windows sobie zeswapuje pamięć którą używa WinUAE - w tym również pamięć graficzną...
A czy driver Picasso dla WinUAE nie jest tylko wrapperem na API Windowsa więc wnosi sam z siebie niewielki narzut?
Tak, można powiedzieć że to jest "tylko" wrapper, który tworzy amigowe "sterowniki" za pomocą DirectX.
Różnica w takim wypadku polega na tym że w wypadku WinUAE sterowanie przechodzi jeszcze przez GDI co może wnieść spowolnienie jednak za to driver pod Windowsem na pewno jest lepszy i bardziej wykorzystuje hardware karty co w efekcie może dać lepszą wydajność.
To założenie iż jest "lepszy" nie jest poparte niczym, ponad wiarę w dogmat o niesamowitości obsługi sprzętu przez windows, i jego wszystkie warstwy abstrakcji razem wzięte.
Już samo naoczne porównanie operacji na oknach pod Amithlonem czy WinUAE pozostawia WinUAE daleko w tyle. Nie mam teraz odpowiedniego sprzętu pod Amithlona, więc niestety nie mogę zrobić żadnego testu, by unaocznić liczbami jak bardzo dostaje w dupę WinUAE na tle Amithlona i operacji graficznych, a szkoda.
Amithlon musi robić to samo.[...] Amithlon też musi wprowadzać emulację przecież.
A niby po jaką cholerę? Jeśli już, to na pewno nie na takim poziomie, i z takim rozmachem jak WinUAE.
Na amithlonie nie uruchomisz nic co się odwołuje do klasycznego amigowego hardware.
Amithlon emuluje tylko procesor, i podstawowe środowisko sprzętowe (takie pierdoły jak obsługa myszy, czy klawiatury, lub dostęp do dysku), dając przy okazji niczym nie blokowany dostęp do rejestrów sprzętowych blaszaka.
Takie rzeczy jak sterowniki do kart graficznych to natywny kod x86, wykorzystujący wspomaganie sprzetowe karty.
Widać że nigdy na oczy nie widziałeś Amithlona.
08.11.2007 21:06
[#44]
Re: Richard Drummond, AROS i E-UAE
@MinisterQ, post #43
To założenie iż jest "lepszy" nie jest poparte niczym, ponad wiarę w dogmat o niesamowitości obsługi sprzętu przez windows, i jego wszystkie warstwy abstrakcji razem wzięte.
Chodzi raczej o to że producent chipsetu karty ma nieskrępowany dostęp do dokumentacji do niej więc może napisać lepsze sterowniki, które wykorzystują sprzęt zamiast robić to samo programowo.
Na amithlonie nie uruchomisz nic co się odwołuje do klasycznego amigowego hardware.
Tego nie wiedziałem i to zmienia postać rzeczy. Dla mnie to nie jest wada ale jest na pewno wielu malkontentów, którzy nie mogli tego przeżyć.
Takie rzeczy jak sterowniki do kart graficznych to natywny kod x86, wykorzystujący wspomaganie sprzetowe karty.
Tak samo jak pod WinUAE.
Widać że nigdy na oczy nie widziałeś Amithlona.
Nie zaprzeczę co już zresztą wyżej w sumie napisałem, jednak nie sądzę żeby ta przewaga Amithlona wynikała z linuxa o czym pisałem w moim pierwszym poście. Po prostu Windows jest szybszy i gdyby ktoś odpowiednio popracował nad WinUAE na pewno mogłoby to zostać uwidocznione.
08.11.2007 21:24
[#46]
Re: Richard Drummond, AROS i E-UAE
@szuler, post #23
> 68k to CISC, PPC to RISC. W jaki sposob mialyby byc zgodne?
Sam sobie odpowiedziałeś na pytanie
> Zeby bylo weselej, Toshiba wypuscila koprocesor
mówimy o procesorze...
> A co to ma oznaczac dla amigowcow ktorzy oczekuja komputera biurkowego a nie sterownika przemyslowego?
może to, że procesory są jednak w jakimś stopniu popularne i dostępne?
Sam sobie odpowiedziałeś na pytanie
> Zeby bylo weselej, Toshiba wypuscila koprocesor
mówimy o procesorze...
> A co to ma oznaczac dla amigowcow ktorzy oczekuja komputera biurkowego a nie sterownika przemyslowego?
może to, że procesory są jednak w jakimś stopniu popularne i dostępne?
08.11.2007 21:37
[#47]
Re: Richard Drummond, AROS i E-UAE
@smith, post #44
Chodzi raczej o to że producent chipsetu karty ma nieskrępowany dostęp do dokumentacji do niej więc może napisać lepsze sterowniki
Akurat jeśli chodzi o funkcje wspomagające operacje 2d, to z tym nigdy nie było problemów, i pod tym względem prędkościowo windows zawsze odstawał, jeśli tylko sterownik do danej karty na Amithlonie wykorzystywał jej wspomaganie.
Dla mnie to nie jest wada ale jest na pewno wielu malkontentów, którzy nie mogli tego przeżyć.
Nie było aż tak źle. Amithlon powstał jako coś w zamyśle symulowania systemu operacyjnego - czegoś co maksymalnie wykorzysta nowoczesny hardware bez żadnych linuksów czy innych windowsów poprzez które trzeba się odwoływać do sprzętu - i z tym radzi sobie doskonale. Prędkość takiego "systemu" można porównywać spokojnie do prędkości nowych AmigaOSów uruchomionych na PPC; w przypadku WinUAE nie ma natomiast o czym mówić.
Niestety Amithlon dziedziczy też podstawową wadę AmigaOSu - ewentualny ciężki crash systemu pociąga za sobą konieczność rebootowania całej maszyny...
Takie rzeczy jak sterowniki do kart graficznych to natywny kod x86, wykorzystujący wspomaganie sprzetowe karty.
@smith
Tak samo jak pod WinUAE.
Z tym że w przypadku Amithlona mamy (cyber)graphics.library z jednej strony, i zaraz potem sterownik karty graficznej działający natywnie ze wspomaganiem GPU, a w przypadku WinUAE po drodze do sprzętu mamy windowsa - jego api, HAL, i dopiero sterownik.
jednak nie sądzę żeby ta przewaga Amithlona wynikała z linuxa
Ja nigdzie tego nie napisałem. Ja stwierdziłem tylko że przewaga Amithlona nad WinUAE wynika z tego, że Amithlon nie ma pod sobą systemu operacyjnego i kilku warstw abstrakcji, a jedynie kernel linuksa (nie cały system!) z emulatorem procesora, i bezpośredni dostęp do hardware.
i chociażby nie wiem jak szybszy windows miałby być, to w tej sytuacji nie ma to żadnego znaczenia.
Akurat jeśli chodzi o funkcje wspomagające operacje 2d, to z tym nigdy nie było problemów, i pod tym względem prędkościowo windows zawsze odstawał, jeśli tylko sterownik do danej karty na Amithlonie wykorzystywał jej wspomaganie.
Dla mnie to nie jest wada ale jest na pewno wielu malkontentów, którzy nie mogli tego przeżyć.
Nie było aż tak źle. Amithlon powstał jako coś w zamyśle symulowania systemu operacyjnego - czegoś co maksymalnie wykorzysta nowoczesny hardware bez żadnych linuksów czy innych windowsów poprzez które trzeba się odwoływać do sprzętu - i z tym radzi sobie doskonale. Prędkość takiego "systemu" można porównywać spokojnie do prędkości nowych AmigaOSów uruchomionych na PPC; w przypadku WinUAE nie ma natomiast o czym mówić.
Niestety Amithlon dziedziczy też podstawową wadę AmigaOSu - ewentualny ciężki crash systemu pociąga za sobą konieczność rebootowania całej maszyny...
Takie rzeczy jak sterowniki do kart graficznych to natywny kod x86, wykorzystujący wspomaganie sprzetowe karty.
@smith
Tak samo jak pod WinUAE.
Z tym że w przypadku Amithlona mamy (cyber)graphics.library z jednej strony, i zaraz potem sterownik karty graficznej działający natywnie ze wspomaganiem GPU, a w przypadku WinUAE po drodze do sprzętu mamy windowsa - jego api, HAL, i dopiero sterownik.
jednak nie sądzę żeby ta przewaga Amithlona wynikała z linuxa
Ja nigdzie tego nie napisałem. Ja stwierdziłem tylko że przewaga Amithlona nad WinUAE wynika z tego, że Amithlon nie ma pod sobą systemu operacyjnego i kilku warstw abstrakcji, a jedynie kernel linuksa (nie cały system!) z emulatorem procesora, i bezpośredni dostęp do hardware.
i chociażby nie wiem jak szybszy windows miałby być, to w tej sytuacji nie ma to żadnego znaczenia.
09.11.2007 08:28
[#48]
Re: Richard Drummond, AROS i E-UAE
@Kaczus, post #45
Aha. Tak czy inaczej to nie ma wiekszego znaczenia (poza predkoscia - a pecety "potrafia" bardzo szybko emulowac).
Moze dla Ciebie i ludzi uzywajacych MOSa, to bedzie raczej ciekawostka, ale istnieje bardzo duza liczba osob uzywajacych klasycznego softu (sa to uzytkownicy Classicow, WinUAE/Amithlona) i dla nich AROS z emulacja 68k, moze sie stac prawdziwym AOSem, dzieki czemu beda czesciej uzywac AROSa, a co za tym idzie, zainteresowanie i uzytkownicy nadadza pewnego "kopa" w rozwoju tego systemu :)
Moze dla Ciebie i ludzi uzywajacych MOSa, to bedzie raczej ciekawostka, ale istnieje bardzo duza liczba osob uzywajacych klasycznego softu (sa to uzytkownicy Classicow, WinUAE/Amithlona) i dla nich AROS z emulacja 68k, moze sie stac prawdziwym AOSem, dzieki czemu beda czesciej uzywac AROSa, a co za tym idzie, zainteresowanie i uzytkownicy nadadza pewnego "kopa" w rozwoju tego systemu :)