28.01 00:41
[#1]
Raspberry MorphOS
Jak myślicie, Yay czy Nay?
Tak wydajnościowo to już poziom ~Core i5 2500 czyli jakieś ponad 2 razy wydajniejszy od najwydajniejszego PowerPC G5. O ile przy RPi4 moje myślenie że MorphOS powinien migrować jak najszybciej się da na ARM i najlepiej na Raspberry Pi było bardziej na zasadzie że takie rzeczy trwają. Użyteczności w porównaniu do jakiegoś wypasionego G5 się wielkiej nie spodziewałem tylko że wyjdzie Pi5 wtedy będzie to wyglądało zupełnie inaczej. RPi ze względu na popularność platformy.
No ale temat taki to każdy może założyć. Ja piszę bo zrobiłem testy na 1 rdzeniu na framebufferze i w 1920x1080 można oglądać YT 1080p z bitrate premium. W zasadzie to pulpit to śmiga pięknie. Z włączoną akceleracją jest trochę lepiej ale to różnicę bardziej widać w 3840x2160 na jednym rdzeniu. Przy 4 można używać 4K bez bólu - trochę wolniej się rysuje ale ogólnie to nie zamula. Nie wydaje mi się aby port 1:1 aby mieć dalej wieszający się system z jednym rdzeniem to była najlepsza opcja ale jeśli już to taki system mogłoby dobrze działać. Przynajmniej nie byłoby problemów z grzaniem się procesora.
Znając życie framebufer musiałby być używany przez jakiś czas zanim jakąś podstawową akcelerację się zrobi dlatego jak to wyrabia z rysowaniem samym procesorem jest ważne. No wyrabia całkiem ładnie.
No ale jakie tam w ogóle są nastroje odnośnie przyszłości?
Siedzenie na PowerPC czyli retro to brak rozwoju i w zasadzie sytuacja praktycznie taka sama jak z samą Amigą. Trzeba jednak iść z duchem czasu. Musi być coś czym się człowiek w danej platformie ekscytuje. Ba, mimo że mam wydajniejsze PC do Linuxów to jak takie Raspberry Pi 5 podłączyłem i zobaczyłem jak to śmiga w porównaniu do czwórki to cieszyłem się jak dziecko. W sumie miesiąc później dalej się cieszę! Tego brakuje już w MorphOS - to ważna część tego hobby komputerowego i dlatego uważam że migracja musi być.
ps. Oczywiście żadne te dywagacje się nie aplikują tutaj do pieców. Nie ten typ systemu aby to wypaliło a szczególnie dla małego projektu i to amigowego.
Poza tym każdy amigowiec wie że jakieś zasady moralne muszą obowiązywać i...
Tak wydajnościowo to już poziom ~Core i5 2500 czyli jakieś ponad 2 razy wydajniejszy od najwydajniejszego PowerPC G5. O ile przy RPi4 moje myślenie że MorphOS powinien migrować jak najszybciej się da na ARM i najlepiej na Raspberry Pi było bardziej na zasadzie że takie rzeczy trwają. Użyteczności w porównaniu do jakiegoś wypasionego G5 się wielkiej nie spodziewałem tylko że wyjdzie Pi5 wtedy będzie to wyglądało zupełnie inaczej. RPi ze względu na popularność platformy.
No ale temat taki to każdy może założyć. Ja piszę bo zrobiłem testy na 1 rdzeniu na framebufferze i w 1920x1080 można oglądać YT 1080p z bitrate premium. W zasadzie to pulpit to śmiga pięknie. Z włączoną akceleracją jest trochę lepiej ale to różnicę bardziej widać w 3840x2160 na jednym rdzeniu. Przy 4 można używać 4K bez bólu - trochę wolniej się rysuje ale ogólnie to nie zamula. Nie wydaje mi się aby port 1:1 aby mieć dalej wieszający się system z jednym rdzeniem to była najlepsza opcja ale jeśli już to taki system mogłoby dobrze działać. Przynajmniej nie byłoby problemów z grzaniem się procesora.
Znając życie framebufer musiałby być używany przez jakiś czas zanim jakąś podstawową akcelerację się zrobi dlatego jak to wyrabia z rysowaniem samym procesorem jest ważne. No wyrabia całkiem ładnie.
No ale jakie tam w ogóle są nastroje odnośnie przyszłości?
Siedzenie na PowerPC czyli retro to brak rozwoju i w zasadzie sytuacja praktycznie taka sama jak z samą Amigą. Trzeba jednak iść z duchem czasu. Musi być coś czym się człowiek w danej platformie ekscytuje. Ba, mimo że mam wydajniejsze PC do Linuxów to jak takie Raspberry Pi 5 podłączyłem i zobaczyłem jak to śmiga w porównaniu do czwórki to cieszyłem się jak dziecko. W sumie miesiąc później dalej się cieszę! Tego brakuje już w MorphOS - to ważna część tego hobby komputerowego i dlatego uważam że migracja musi być.
ps. Oczywiście żadne te dywagacje się nie aplikują tutaj do pieców. Nie ten typ systemu aby to wypaliło a szczególnie dla małego projektu i to amigowego.
Poza tym każdy amigowiec wie że jakieś zasady moralne muszą obowiązywać i...
28.01 09:50
[#4]
Re: Raspberry MorphOS
@michal_zukowski, post #2
1. A pojawi się kiedykolwiek pełna? Pytam, bo może się orientujesz, jak to było z poprzednimi wersjami?
2. Gdyby była ewentualna zbiórka na ileś Rpi 5 dla MOSTeamu, to reflektuję taki pomysł.
3. A inne płytki oparte na pomyśle Rpi5 też tak kiepsko są udokumentowane, czy nie wyszły? W Botlandzie coś tam było przy Rpi4, nie śledzę, stąd taki być może mylny wniosek.
2. Gdyby była ewentualna zbiórka na ileś Rpi 5 dla MOSTeamu, to reflektuję taki pomysł.
3. A inne płytki oparte na pomyśle Rpi5 też tak kiepsko są udokumentowane, czy nie wyszły? W Botlandzie coś tam było przy Rpi4, nie śledzę, stąd taki być może mylny wniosek.
28.01 13:14
[#6]
Re: Raspberry MorphOS
@Rafael/ARMO, post #5
Technicznie rzecz biorąc to tak - jakiekolwiek porty na ARM mają też większy sens jeśli to co portujemy nie ma takich ograniczeń jak jeden CPU. Problemem chyba obsługi wielu rdzeni jest to że API AmigaDOS w ogóle nie było przewidziane do obsługi wielu procesorów czy ochrony pamięci. Też ograniczenie do 2GB pamięci wynika z pewnych rozwiązań które ograniczają jak duże mogą być wskaźniki.
Gdyby chcieć te wszystkie rzeczy dodać i obsługiwać więcej pamięci - ale już nie że 4GB tylko 64-bit adresowanie - to trzeba by dość znacznie zmienić to jak działa cały OS i jego aplikacje. Jeśli taka zmiana powodowałaby że je trzeba przerabiać to nie ma chyba sensu dalej produkować się na PowerPC.
Port w formie w jakiej MOS teraz jest czyli praktycznie kopia AmigaDOS na ARM to byłaby powtórka z rozrywki AROSa. Dalej jeśli by to zrealizować mielibyśmy wydajniejsze procesory i zagwarantowany rozwój platformy ale już tylko zmniejszałby się z czasem procent utylizacji sprzętu.
Gdyby chcieć te wszystkie rzeczy dodać i obsługiwać więcej pamięci - ale już nie że 4GB tylko 64-bit adresowanie - to trzeba by dość znacznie zmienić to jak działa cały OS i jego aplikacje. Jeśli taka zmiana powodowałaby że je trzeba przerabiać to nie ma chyba sensu dalej produkować się na PowerPC.
Port w formie w jakiej MOS teraz jest czyli praktycznie kopia AmigaDOS na ARM to byłaby powtórka z rozrywki AROSa. Dalej jeśli by to zrealizować mielibyśmy wydajniejsze procesory i zagwarantowany rozwój platformy ale już tylko zmniejszałby się z czasem procent utylizacji sprzętu.
28.01 15:58
[#7]
Re: Raspberry MorphOS
@XoR, post #6
Prawda jest taka, że albo zostajemy i jest, jak jest, albo zrywamy kompatybilność i dajemy ewentualnie coś, w stylu uruchom w trybie zgodności/emulacji. Raczej zostanie, jak jest, bo żaden obóz nie ma dość ludzi, na cokolwiek nowego. Na współpracę i jeden system też nie liczę, choć wspólny wybór platformy dawałby cień nadziei. Porzućmy marzenia, czekajmy na A500 Maxi, które ostatecznie zakopie NG, wtedy będzie już za późno na działanie. Zamiast wykorzystać popularność/modę rozwiązań na ARM w naszym mikroświatku, prześpijmy się. Dobranoc. 
29.01 09:12
[#8]
Re: Raspberry MorphOS
@KM_Ender, post #7
Ano... takie mam wrażenie że takie jest podejście aby położyć się wreszcie i dobrze wyspać po latach dobrej roboty...
Za dużo jest problemów do rozwiązania "na raz" a jakkolwiek by ich nie rozwiązał to nie będzie to już to co było: praktycznie ten sam kernel działający tak samo w sensie API dla programów do tego stopnia że można było integrować emulowane programy 68K z systemem. Jakkolwiek by na to nie patrzeć port na maszyny Little Endian czy 64-bit (a jak robić drugie to i nie ma sensu robić drugiego) powoduje że takiej kompatybilności się nie uzyska. To samo jeśli chodzi o zmiany wymagane aby mieć obsługę wielu rdzeni jeśli to miałoby działać tak jak w innych systemach.
No chyba że... chyba że dałoby się (a powinno się technicznie dać!) zrobić tak że OS jest 32-bit i w Big Endian.
Dalej to robimy tak jak na kartach turbo czyli proces startuje na 32-bit na cpu0 normalnie a jak ma coś dużego do przeprocesowania to system uruchamia to na drugim kernelu który już obsługuje arm64 i cpu1, cpu2 i cpu3. Tam też powinno się dać na czas wykonania przełączać do woli endiana pomiędzy dużym a małym. Rozwiązanie iście godne systemu amigowego które co prawda nie sprawiło by że żadna z obecnych aplikacji działałaby jotę wydajniej ale już można by tak pisać nowe aplikacje aby pewne rzeczy wykonywać na dodatkowych rdzeniach a nawet używać optymalizacji napisanych stricte dla Little Endian.
Czy takie coś ma sens czy nie to zależy od tego jak procesor ma rozwiązany problem spójności cache - i o ile pomiędzy 68K i PPC które były innymi procesorami trzeba było to robić programowo to już niekoniecznie ten problem byśmy mieli na nowoczesnym ARMie. Dostępy do zasobów systemowych w najgorszym wypadku jeśli nie wymyśli się nic lepszego musiałyby odbywać się przez proces na cpu0. Na pewno każdy z wątków dla cpu1-3 działałby w nowym kernelu który ma swoją mapę pamięci z której ją przydziela ale jako że my nic nie ukrywamy można bez problemu operować na pamięci "niskiej" i tak np. program do rysowania mandelbrota albo inny ray tracer mógłby zadeklarować pamięć na bitmapę i stworzyć thready które by do tej pamięci do określonych jej części zapisywały wynik obliczeń. Taki program z perspektywy innych programów (o ile nie używają wyższych rdzeni) w ogóle praktyczne nie używałby czasu procesora. Tego typu optymalizacje można by wrzucać w różnych miejscach aby zmaksymalizować wykorzystanie procesora. Pisząc nowy program albo robiąc port jakiegoś programu który wymaga dużej wydajności tego typu mechanizmy można by wykorzystać. Też jeśli chodzi o BE i LE - ARM można sobie przełączać. Nikt tego za bardzo nie robi w np. Linuxie ale tzw. bare metal to i owszem. MorphOS to w zasadzie system bare metal...
Wg. mnie rozwiązania typu że coś tam "emulujemy" nie są do końca tym czego oczekujemy od takiego systemu jak MorphOS. Nawet ochrona pamięci... po co to komu, na co to komu? Tak samo raczej nikt nie chce systemu kompletnie bez aplikacji. Nie wszystko będzie się dało skompilować na nowo a tym bardziej jeśli będzie to wymagało większego effortu. Usunięcie/przepisanie wstawek assemblerowych to jedna sprawa a debugowanie problemów i przerabianie aplikacji z BE na LE to zupełnie inna. Podobnie zmiany w API wymagające aby grzebać w kodzie każdej jednej aplikacji. Emulator PPC potencjalnie można napisać i to samo M68K na to samo kopyto co obecnie emulacja M68K.
Oczywiście dalej mamy problem posiadania bazowego OSa na ARM co wymaga dużej ilości pracy aby się wydarzyło.
Tylko tutaj problemem nie jest tak naprawdę brak dokumentacji tylko sensowność takiej inwestycji. Czas to oczywiście inna sprawa ale jak będą chęci aby np. kupić wersję MOSa na RPi to pewnie i czas się znajdzie
Dokumentacja kuleje ale tak naprawdę wystarczy wybootować, ogarnąć na początek framebuffer, USB i LAN. Te można zgapić z Linuxa i projektów bare metal (np. Ultibo - tam nawet mają LAN i nawet akcelerację grafiki...). Bardziej bym tutaj widział RPi4 jako platforma developerska bo ten temat ma na obecną chwilę większy support ale docelowo przejście na bardziej sensowne RPi5 nie powinno już być takim dużym problemem. Zanim to by wszystko było gotowe do podstawowego używania (nawet bez jeszcze emulacji 68K/PPC) to to jak wybootować i zainicjalizować RPi5 zostanie gdzieś opisane.
Z tego też powodu kiedyś już pisałem o tym że Pi4 to najlepszy target dla MorphOSa. Temat został niejako zignorowany a same środowisko to się chyba zachłysnęło pomysłem odnośnie jakiegoś Rajzena co wg. mnie byłoby pomysłem całkowicie pozbawionym sensu i tylko odwracał uwagę od rzeczy rzeczy ważnych i istotnych - ARM może działać w BigEndian. Zresztą właśnie brak sensu jest powodem że takiego portu na horyzoncie nie widać. Za to port na RPi4 sens miał i to duży. Dalej ma choć w tym momencie docelowo już bardziej na Pi5 bo różnica wydajności jest po prostu:
. A znając życie to Pi6 będzie miał pewnie wydajność Core i5 6700/7600 (a nawet jak dorzucą rdzenióff to 8600) czyli ~2x lepsza wydajność jednego wątku i ogólnie szok i niedowierzanie i dumanie że szkoda że jednak nic nie zrobiono.
Za dużo jest problemów do rozwiązania "na raz" a jakkolwiek by ich nie rozwiązał to nie będzie to już to co było: praktycznie ten sam kernel działający tak samo w sensie API dla programów do tego stopnia że można było integrować emulowane programy 68K z systemem. Jakkolwiek by na to nie patrzeć port na maszyny Little Endian czy 64-bit (a jak robić drugie to i nie ma sensu robić drugiego) powoduje że takiej kompatybilności się nie uzyska. To samo jeśli chodzi o zmiany wymagane aby mieć obsługę wielu rdzeni jeśli to miałoby działać tak jak w innych systemach.
No chyba że... chyba że dałoby się (a powinno się technicznie dać!) zrobić tak że OS jest 32-bit i w Big Endian.
Dalej to robimy tak jak na kartach turbo czyli proces startuje na 32-bit na cpu0 normalnie a jak ma coś dużego do przeprocesowania to system uruchamia to na drugim kernelu który już obsługuje arm64 i cpu1, cpu2 i cpu3. Tam też powinno się dać na czas wykonania przełączać do woli endiana pomiędzy dużym a małym. Rozwiązanie iście godne systemu amigowego które co prawda nie sprawiło by że żadna z obecnych aplikacji działałaby jotę wydajniej ale już można by tak pisać nowe aplikacje aby pewne rzeczy wykonywać na dodatkowych rdzeniach a nawet używać optymalizacji napisanych stricte dla Little Endian.
Czy takie coś ma sens czy nie to zależy od tego jak procesor ma rozwiązany problem spójności cache - i o ile pomiędzy 68K i PPC które były innymi procesorami trzeba było to robić programowo to już niekoniecznie ten problem byśmy mieli na nowoczesnym ARMie. Dostępy do zasobów systemowych w najgorszym wypadku jeśli nie wymyśli się nic lepszego musiałyby odbywać się przez proces na cpu0. Na pewno każdy z wątków dla cpu1-3 działałby w nowym kernelu który ma swoją mapę pamięci z której ją przydziela ale jako że my nic nie ukrywamy można bez problemu operować na pamięci "niskiej" i tak np. program do rysowania mandelbrota albo inny ray tracer mógłby zadeklarować pamięć na bitmapę i stworzyć thready które by do tej pamięci do określonych jej części zapisywały wynik obliczeń. Taki program z perspektywy innych programów (o ile nie używają wyższych rdzeni) w ogóle praktyczne nie używałby czasu procesora. Tego typu optymalizacje można by wrzucać w różnych miejscach aby zmaksymalizować wykorzystanie procesora. Pisząc nowy program albo robiąc port jakiegoś programu który wymaga dużej wydajności tego typu mechanizmy można by wykorzystać. Też jeśli chodzi o BE i LE - ARM można sobie przełączać. Nikt tego za bardzo nie robi w np. Linuxie ale tzw. bare metal to i owszem. MorphOS to w zasadzie system bare metal...
Wg. mnie rozwiązania typu że coś tam "emulujemy" nie są do końca tym czego oczekujemy od takiego systemu jak MorphOS. Nawet ochrona pamięci... po co to komu, na co to komu? Tak samo raczej nikt nie chce systemu kompletnie bez aplikacji. Nie wszystko będzie się dało skompilować na nowo a tym bardziej jeśli będzie to wymagało większego effortu. Usunięcie/przepisanie wstawek assemblerowych to jedna sprawa a debugowanie problemów i przerabianie aplikacji z BE na LE to zupełnie inna. Podobnie zmiany w API wymagające aby grzebać w kodzie każdej jednej aplikacji. Emulator PPC potencjalnie można napisać i to samo M68K na to samo kopyto co obecnie emulacja M68K.
Oczywiście dalej mamy problem posiadania bazowego OSa na ARM co wymaga dużej ilości pracy aby się wydarzyło.
Tylko tutaj problemem nie jest tak naprawdę brak dokumentacji tylko sensowność takiej inwestycji. Czas to oczywiście inna sprawa ale jak będą chęci aby np. kupić wersję MOSa na RPi to pewnie i czas się znajdzie
Dokumentacja kuleje ale tak naprawdę wystarczy wybootować, ogarnąć na początek framebuffer, USB i LAN. Te można zgapić z Linuxa i projektów bare metal (np. Ultibo - tam nawet mają LAN i nawet akcelerację grafiki...). Bardziej bym tutaj widział RPi4 jako platforma developerska bo ten temat ma na obecną chwilę większy support ale docelowo przejście na bardziej sensowne RPi5 nie powinno już być takim dużym problemem. Zanim to by wszystko było gotowe do podstawowego używania (nawet bez jeszcze emulacji 68K/PPC) to to jak wybootować i zainicjalizować RPi5 zostanie gdzieś opisane.Z tego też powodu kiedyś już pisałem o tym że Pi4 to najlepszy target dla MorphOSa. Temat został niejako zignorowany a same środowisko to się chyba zachłysnęło pomysłem odnośnie jakiegoś Rajzena co wg. mnie byłoby pomysłem całkowicie pozbawionym sensu i tylko odwracał uwagę od rzeczy rzeczy ważnych i istotnych - ARM może działać w BigEndian. Zresztą właśnie brak sensu jest powodem że takiego portu na horyzoncie nie widać. Za to port na RPi4 sens miał i to duży. Dalej ma choć w tym momencie docelowo już bardziej na Pi5 bo różnica wydajności jest po prostu:
. A znając życie to Pi6 będzie miał pewnie wydajność Core i5 6700/7600 (a nawet jak dorzucą rdzenióff to 8600) czyli ~2x lepsza wydajność jednego wątku i ogólnie szok i niedowierzanie i dumanie że szkoda że jednak nic nie zrobiono. 29.01 09:41
[#9]
Re: Raspberry MorphOS
@XoR, post #1
Obojętne co tyle tylko to mógł być laptop. Stacjonarka (czyli tez RapberryPi) byłaby dla mnie strasznie niewygodna. Architektura procesora to dla mnie sprawa drugorzędna. Nawet bawiąc się w natywny kod klepany w C/C++ to nie ma dla mnie znaczenia. I tak każdego dnia ten sam kod przewalam między PowerPC, ARM/M1 i Intel. Daaawno się uodporniłem na rodzaj architektury. Przeżyję nawet brak sympatii do Inteli. 
29.01 12:47
[#10]
Re: Raspberry MorphOS
@XoR, post #8
Jak dla mnie to musiałby być nowy system zrywający z kompatybilnością. Nowe wersje softu z Amigi/PPC, (którego nie da się zastąpić ) lub jesteśmy wybitnie przywiązani jako Amigowcy. Remastery najlepszych gier lub używanie Amigakit, Uae itd. MOSTeam już mnie pewnie wpisał na czarną listę za marudzenie. Nawet były jakieś laptopy Acera z Mediateka M8183 do kupienia, czy są nadal nie wiem. Niech robią co chcą. W sumie to czy wieloprocesorowość 32-bity jest prostsza do wprowadzenia, przy jednoczesnym utrzymaniu zgodności z AmigaOS 3.x niż 64-bity na 1 rdzeniu? To do kolegi wcześniej.
) lub jesteśmy wybitnie przywiązani jako Amigowcy. Remastery najlepszych gier lub używanie Amigakit, Uae itd. MOSTeam już mnie pewnie wpisał na czarną listę za marudzenie. Nawet były jakieś laptopy Acera z Mediateka M8183 do kupienia, czy są nadal nie wiem. Niech robią co chcą. W sumie to czy wieloprocesorowość 32-bity jest prostsza do wprowadzenia, przy jednoczesnym utrzymaniu zgodności z AmigaOS 3.x niż 64-bity na 1 rdzeniu? To do kolegi wcześniej. 29.01 17:59
[#11]
Re: Raspberry MorphOS
@KM_Ender, post #10
Ja podchodzę do tematu od strony entuzjasty komputerów i dla mnie rozwiązania typu tego co opisałem wydawałoby się bardzo ciekawe i bardzo 'amigowe' patrząc na cały system i jego historię. Dlatego taki a nie inny pomysł.
Sensowność takiego rozwiązania jest oczywiście wątpliwa.... tylko jak dla mnie sensowność nowego OSu ale dalej babrać się z problemach jakie są do tej pory czyli obsługa sprzętu też wydaje się wątpliwa. Już chyba większym sensem byłoby całkowicie odciąć się od hardware i użyć czegoś co już działa jak np. kernel linuxa i na nim zbudować nowe środowisko. Tj. nie używać userlandu GNU tylko napisać coś nowego z desktopem na MUI. Programy miałyby nowe API już oparte po części na Linuxie. Aby było bardziej amigowo można by stworzyć API które implementuje rzeczy znane z Amigi jak np. datatypy czy nawet można by zmienić jak obsługiwane są ścieżki do plików... jeśli dla ludzi byłaby to istotna kwestia. Pewne aspekty API z natury samego systemu odnośnie ochrony pamięci, wielordzeniowości itp. musiałyby działać inaczej niż do tej porty ale nie byłoby to niemożliwe do zrealizowania.
Oczywiście wtedy to byłby Linux ale już nie GNU/Linux tylko MorphOS który to bardziej niż do tej pory jest "morph"
W tym przypadku kwestię kompatybilności to faktycznie albo emulujemy cały komputer PPC i wtedy równie dobrze może to być X86, tfu tfu...
...albo na jedynej słusznej architekturze która to umożliwia czyli ARM kombinacje w hakowanie kernela aby zmieniać endianess dla procesu (w teorii możliwe nawet podczas gdy on działa jeśli wymagany byłby LE dla komunikacji z resztą systemu) dla procesu i tam uruchomić specjalną wersję MOSa dla ARM 32-bit BE która jest taką jakby maszyną wirtualną ze specjalnymi driverami które najlepiej są wydmuszkami aby już nie emulować prawdziwych urządzeń. To czy to jednak jest możliwe aby wszystkie potrzebne punkty są możliwe trzeba by najpierw wykazać przez jakiś proof of concept. W zasadzie to takie rozwiązanie to byłby dobry temat sam w sobie bo jeśli wszystko by się udało to byśmy mieli możliwość startu kilku MOSów jednocześnie i programy ARM mogłyby działać z praktycznie pełną prędkością. Dalej jeden rdzeń i do 2GB pamięci ale już bardziej użytkowo.
Nawet bym powiedział że od tego ostatniego pomysłu można by w ogóle zacząć całą zabawę z portem. W sensie jak bardzo niedorzecznie by to brzmiało to pod względem effortu powinno to być do ogarnięcia znacznie szybciej niż budowanie nowego 64-bit OSu z nowym API. Nawet bazując na Linuxie to też jest... tak mi się przynajmniej wydaje... większy effort bo trzeba wymyślić API i napisać aplikacje. To nie jest niemożliwe i na dłuższą metę w tej czy natywnej formie nie do uniknięcia jeśli system ma się rozwijać ale nie wydaje mi się aby to mogło zająć krócej niż te kilka lat aby mieć użyteczny pulpit i zestaw podstawowych programów. Za dużo rzeczy do ustalenia i napisania. Jeśli natomiast systemem byłby Linux i w środku MorhOS 32-bit BE to nowy MorphOS może sobie być rozwojowy przez te kilka lat a z punktu użyteczności dużo nie tracimy bo mamy działający z natywną prędkością podsystem. Istniejące programy to by sobie mogły się rozwijać na nim tak jak to zawsze robiły a nowe to już można by rozwijać razem z nową częścią OSu.
Sensowność takiego rozwiązania jest oczywiście wątpliwa.... tylko jak dla mnie sensowność nowego OSu ale dalej babrać się z problemach jakie są do tej pory czyli obsługa sprzętu też wydaje się wątpliwa. Już chyba większym sensem byłoby całkowicie odciąć się od hardware i użyć czegoś co już działa jak np. kernel linuxa i na nim zbudować nowe środowisko. Tj. nie używać userlandu GNU tylko napisać coś nowego z desktopem na MUI. Programy miałyby nowe API już oparte po części na Linuxie. Aby było bardziej amigowo można by stworzyć API które implementuje rzeczy znane z Amigi jak np. datatypy czy nawet można by zmienić jak obsługiwane są ścieżki do plików... jeśli dla ludzi byłaby to istotna kwestia. Pewne aspekty API z natury samego systemu odnośnie ochrony pamięci, wielordzeniowości itp. musiałyby działać inaczej niż do tej porty ale nie byłoby to niemożliwe do zrealizowania.
Oczywiście wtedy to byłby Linux ale już nie GNU/Linux tylko MorphOS który to bardziej niż do tej pory jest "morph"
W tym przypadku kwestię kompatybilności to faktycznie albo emulujemy cały komputer PPC i wtedy równie dobrze może to być X86, tfu tfu...
...albo na jedynej słusznej architekturze która to umożliwia czyli ARM kombinacje w hakowanie kernela aby zmieniać endianess dla procesu (w teorii możliwe nawet podczas gdy on działa jeśli wymagany byłby LE dla komunikacji z resztą systemu) dla procesu i tam uruchomić specjalną wersję MOSa dla ARM 32-bit BE która jest taką jakby maszyną wirtualną ze specjalnymi driverami które najlepiej są wydmuszkami aby już nie emulować prawdziwych urządzeń. To czy to jednak jest możliwe aby wszystkie potrzebne punkty są możliwe trzeba by najpierw wykazać przez jakiś proof of concept. W zasadzie to takie rozwiązanie to byłby dobry temat sam w sobie bo jeśli wszystko by się udało to byśmy mieli możliwość startu kilku MOSów jednocześnie i programy ARM mogłyby działać z praktycznie pełną prędkością. Dalej jeden rdzeń i do 2GB pamięci ale już bardziej użytkowo.
Nawet bym powiedział że od tego ostatniego pomysłu można by w ogóle zacząć całą zabawę z portem. W sensie jak bardzo niedorzecznie by to brzmiało to pod względem effortu powinno to być do ogarnięcia znacznie szybciej niż budowanie nowego 64-bit OSu z nowym API. Nawet bazując na Linuxie to też jest... tak mi się przynajmniej wydaje... większy effort bo trzeba wymyślić API i napisać aplikacje. To nie jest niemożliwe i na dłuższą metę w tej czy natywnej formie nie do uniknięcia jeśli system ma się rozwijać ale nie wydaje mi się aby to mogło zająć krócej niż te kilka lat aby mieć użyteczny pulpit i zestaw podstawowych programów. Za dużo rzeczy do ustalenia i napisania. Jeśli natomiast systemem byłby Linux i w środku MorhOS 32-bit BE to nowy MorphOS może sobie być rozwojowy przez te kilka lat a z punktu użyteczności dużo nie tracimy bo mamy działający z natywną prędkością podsystem. Istniejące programy to by sobie mogły się rozwijać na nim tak jak to zawsze robiły a nowe to już można by rozwijać razem z nową częścią OSu.
29.01 18:05
[#12]
Re: Raspberry MorphOS
@MDW, post #9
Akurat jeśli chodzi o malinowe laptopy to takowy istnieje np. https://www.amazon.com/Raspberry-Portable-Programming-Graphical-Switchable/dp/B09WTHCWVS/ref=sr_1_3?keywords=Raspberry%2BPi%2BLaptop&qid=1706547658&sr=8-3&th=1
Tutaj akurat wersja dla Raspberry Pi 4 ale spodziewam się że wersja dla Raspberry Pi 5 też za jakiś czas powstanie.
ps. Smuci mnie Twój brak niechęci do Inteli
Tutaj akurat wersja dla Raspberry Pi 4 ale spodziewam się że wersja dla Raspberry Pi 5 też za jakiś czas powstanie.
ps. Smuci mnie Twój brak niechęci do Inteli
29.01 18:26
[#13]
Re: Raspberry MorphOS
@KM_Ender, post #4
1. A pojawi się kiedykolwiek pełna? Pytam, bo może się orientujesz, jak to było z poprzednimi wersjami?
2. Gdyby była ewentualna zbiórka na ileś Rpi 5 dla MOSTeamu, to reflektuję taki pomysł.
3. A inne płytki oparte na pomyśle Rpi5 też tak kiepsko są udokumentowane, czy nie wyszły? W Botlandzie coś tam było przy Rpi4, nie śledzę, stąd taki być może mylny wniosek.
1. Dla RP1 czyli kontrolera I/O jeszcze nie ma ale raczej na pewno powstanie.
VC7 (układ graficzny) to kwestia Broadcoma który w tej materii jest nieugięty i nikt nie wie dlaczego. Nie jest to jednak aż taki duży blocker aby sprawiał że nie da się zrobić akceleracji 2D/3D tylko raczej niedogodność.
Inne układy pewnie mają jakąś dokumentację choć czy mają czy nie to nie sprawdzałem.
2. Raczej zarówno RPi4 jak i 5 i pewnie by potrzeba było kilka sztuk.
Cenowo Pi są jak za darmo więc na pewno by się coś ogarnęło W końcu dlatego właśnie Pi bo jest dostępne dla przeciętego zjadacza chleba. Jeśli nie cena to po co generować sobie problemy i od razu można by robić port na: https://www.raptorcs.com/content/base/products.html
3. Z innymi płytkami sytuacja jest różna ale raczej ogólny konsensus jest taki że do projektów bare metal wybiera się Raspberry Pi. Trzeba na to patrzeć też od strony zagwarantowanej dostępności. Pewne marki już ugruntowane z dobrą historią dostępności można by rozważyć. Na pewno jeśli chodzi o sterowniki do grafiki to żaden producent SoC'ów nie udostępnia dokumentacji.
Oczywiście ma to tylko wtedy jakiekolwiek znaczenie jeśli miałby to być port natywny bo jakby robić to na Linuxie to w zasadzie płytkę można by sobie teoretyczne wybrać jakąkolwiek by się chciało - co jest też powodem aby się nad takim rozwiązaniem pochylić.
29.01 21:47
[#15]
Re: Raspberry MorphOS
@XoR, post #1
A co jest złego w amd64? Po co sięgać po hobbystyczny sprzęt ze znacznie ograniczoną produkcją? Amd64 daje cały zestaw do wyboru: laptopy, tablety, stacjonarki, mini-pc, komputery-w-monitorze itd. stare, nowe, ładne, brzydkie, pełna paleta.
Po co przepisywać system operacyjny, aby obsługiwał wszystkie kruczki nowej platformy? To tytaniczna praca dla dziesiątek ludzi.
Dobra inicjatywa została podjęta już dawno temu i została niemalże całkowicie zlana przez "zasady moralne" właśnie. Powstał Amithlon, pyknięty przez jedną osobę, kody źródłowe otwarte, obsługa sprzętu łatwiejsza, bo na jądrze linucha. Oprócz emulacji 68k miał wstępną obsługę odpalania natywnych programów w formacie elf, którą pewnie dałoby się pociągnąć dalej. Dodać emulację ppc (która w WinUAE już jest) i jest się już dużo dalej niż taki MOS musiałby przejść, aby tam dotrzeć.
O słoniu w pokoju, którym jest AROS, to nawet nie wspomnę.
Prawda jest taka, że takie rzeczy są bardzo czasochłonne i ekonomicznie nieuzasadnione i dlatego nic takiego się nie stanie.
Na końcu większość i tak odpali sobie WinUAE i tyle z "zasad moralnych".
Po co przepisywać system operacyjny, aby obsługiwał wszystkie kruczki nowej platformy? To tytaniczna praca dla dziesiątek ludzi.
Dobra inicjatywa została podjęta już dawno temu i została niemalże całkowicie zlana przez "zasady moralne" właśnie. Powstał Amithlon, pyknięty przez jedną osobę, kody źródłowe otwarte, obsługa sprzętu łatwiejsza, bo na jądrze linucha. Oprócz emulacji 68k miał wstępną obsługę odpalania natywnych programów w formacie elf, którą pewnie dałoby się pociągnąć dalej. Dodać emulację ppc (która w WinUAE już jest) i jest się już dużo dalej niż taki MOS musiałby przejść, aby tam dotrzeć.
O słoniu w pokoju, którym jest AROS, to nawet nie wspomnę.
Prawda jest taka, że takie rzeczy są bardzo czasochłonne i ekonomicznie nieuzasadnione i dlatego nic takiego się nie stanie.
Na końcu większość i tak odpali sobie WinUAE i tyle z "zasad moralnych".
29.01 22:37
[#16]
Re: Raspberry MorphOS
@Mario, post #15
Co do MorphOS'a, to czekam na: https://morphos.pl/morphos-na-amd64/
Jeśli kiedykolwiek powstanie, to będzie ogłoszona konkretna konfiguracja na której będzie działał.
Amithlon - lata temu kiedyś uruchomiłem na jakimś tam PC, dzisiaj to chyba ze świecą w ręku szukać konfigu na którym ruszy, to chyba AROS ma lepiej.
Jeśli kiedykolwiek powstanie, to będzie ogłoszona konkretna konfiguracja na której będzie działał.
Amithlon - lata temu kiedyś uruchomiłem na jakimś tam PC, dzisiaj to chyba ze świecą w ręku szukać konfigu na którym ruszy, to chyba AROS ma lepiej.
30.01 09:04
[#18]
Re: Raspberry MorphOS
@Mario, post #15
Po co sięgać po hobbystyczny sprzęt ze znacznie ograniczoną produkcją?
Takie same argumenty padały już w pierwszej połowie lat 00 jak AMD64 dopiero co zostało wydane a nawet i jak jeszcze na nie czekano. Polecam poczytać - fascynująca lektura
Poza tym jeśli chodzi o ARM64 to kolega się chyba nie orientuje jaka jest sytuacja. Powiem krótko - pchanie się w AMD64 w tym momencie większego sensu nie ma bo już są plany dużych firm jak Qualcomm czy nawet Nvidia aby wejść w rynek PC. nawet M$ intensywnie pracuje aby przejście z Windowsa na x86 na Windowsa na ARM było jak najmniej problematyczne. Ba, spodziewam się że za maksymalnie kilka lat część komputerów PC będzie już śmigać na ARMach i ich użytkownicy za bardzo różnicy nie poczują.
Ba, jak ktoś zamarzył sobie neo-amigę na AMD to AMD też podobno pracuje intensywnie nad ARMem. Oni to już kiedyś chcieli zrobić płytę na zarówno AMD64 jak i ARM64 i pewnie prędzej czy później to się po prostu wydarzy. W tamtym momencie podyktowane to było z ich strony brakiem sensownej opcji X86 ale też ten ARM który mieliby wydać to byłby generyczny Cortex A57 chyba - nic szczególnie ekscytującego a i od strony systemów operacyjnych nie wyglądało to dobrze. Dzisiaj takie coś na jakimś Cortexie Xcoś tam już miałoby dość duży sens. Za kilka lat - nieuniknione.
Na AMD64 był czas - tak jakieś dwie dekady temu
I nie mówię tutaj że nie będzie za jakiś czas nowych X86 - na pewno Intel tak łatwo się nie podda. No ale Intel to tak ostatnio średnio działa aby utrzymać dominację X86 a na dłuższą metę nawet jeśli X86 będzie do końca świata i jeden dzień dłużej to ARM też nigdzie raczej nie pójdzie. Jest to bardzo dobry wybór dla MorphOS. No i ARM to jednak dalej Intel Outside - amigowcy wiedzieli, wierzyli... głupio teraz w takim momencie akurat tracić wiarę
30.01 09:36
[#19]
Re: Raspberry MorphOS
@karolb, post #16
Co do MorphOS'a, to czekam na: https://morphos.pl/morphos-na-amd64/
No jest to jakaś opcja.
Nie powiedziałbym aby AMD64 było najlepsze dla MorphOS ale to moja osobista opinia poparta mało konkretnymi przesłankami z dużą ilością "Intel Outside" i gdybania o przyszłości która równie dobrze może się nie wydarzyć tak jak sobie to wyobrażam.
Tego filmiku jeszcze nie widziałem ani opisu - wygląda to całkiem dobrze.
Jeśli to był 2019 a prace były kontynuowane to być może sprawa i tak jest bliższa niż dalsza realizacji jeśli chodzi o design API i jego implementację - coś co wydaje się potrzebować najwięcej effortu. Poza tym w zasadzie w zależności od zaawansowania prac być może X86 dla MoprhOSa tak jak dla Apple będzie tylko przejściowym epizodem. Nic nie będzie stało na przeszkodzie przejść później na ARM jeśli będzie to miało większy sens
A tak po prawdzie to po prostu wolałbym taki port na Rapsberry Pi 5
...bo już go mam, działa bardzo dobrze i ostatecznie zawsze to dla samego MOSa dobra opcja bo łatwiej jest dla takiej platformy o reklamę i ewentualny przypływ nowych użytkowników
30.01 12:43
[#21]
Re: Raspberry MorphOS
@XoR, post #12
Akurat jeśli chodzi o malinowe laptopy to takowy istnieje
Nie wiedziałem, że coś takiego istnieje. Dla mnie mogłoby być.
Smuci mnie Twój brak niechęci do Inteli
Mi jest to już obojętne co tam w środku siedzi. To już nie ten etap w życiu żeby przy czymś się upierać czy na coś czekać. Zdałem sobie sprawę z tego, że będę jeszcze żył mniej więcej tyle ile używam MorphOSa (od 2003).
Czekanie na cokolwiek nie ma już sensu. Dla mnie będzie ok nawet jeżeli nigdy nic nowego nie wyjdzie tylko po prostu MOS będzie utrzymywany na starych PPC. Też będę się fajnie bawił, bo to jest mój poziom retro. Taki, który lubię, chyba rozumiem i w którym dobrze się czuję. Dzisiejsze komputery mi nie imponują, a o starszym retro to ja mogę sobie najwyżej pogadać, miło powspominać.Niechęć do intelowego świata mam cały czas (na codzień używam głównie ARMów i PowerPC). Chociaż do mnie bardziej pasuje "Microsoft outside" niż "Intel outside".
Gdyby taki intelowy MorphOS miał faktycznie działać to zaakceptowałbym to. Ja bym nawet zaakceptował IDEALNIE DZIAŁAJĄCĄ emulację PPC. Tylko tak żeby nie pojawiał mi się inny system przy bootowaniu, żeby nie było żadnego menu z ustawieniami podczas gdy mój system już działa. Niech to będzie gdzieś na niskim poziomie. No i to faktycznie musi działać. Nie żebym nagle dowiedział się, że sieć czy akcelerator 3D na czymś takim nie działa. 
30.01 21:25
[#28]
Re: Raspberry MorphOS
@XoR, post #18
Firmy odchodzą od PC, bo sprzedaż PC dramatycznie spada.
Przeciętny człowiek używa telefonu do prawie wszystkiego.
Zostają tylko ludzie pracujący na komputerach i hobbyści/profesjonaliści, którzy na nich coś tam dłubią. Użytkownik MOSa wpada w taką kategorię, stąd amd64 (znane także również jako x86 64bit) jest dobrym wyborem, bo na rynku pc nadal zdecydowanie dominuje.
Microsyf chce windę na tabletach, to ich stare marzenie jeszcze z lat Windows 8 (kafelki!), stąd ich zamiary przenoszenia systemu na arm. Reszta producentów czuje zapach hajsu urządzeń mobilnych, stąd też chcą w ten rynek wchodzić. Mimo wszystko dostępność sprzętu amd64 (starego i nowego) w postaci pc (bo to nas interesuje) jest ekstremalna, a pogłoski o rychłej śmierci amd64 w kategorii desktopów rozdmuchane.
Z resztą... dajcie spokój... ja nie chcę zmieniać procesora i płyty głównej aby dodać sobie RAMu...
Ostatnia aktualizacja: 30.01.2024 21:27:17 przez Mario
Przeciętny człowiek używa telefonu do prawie wszystkiego.
Zostają tylko ludzie pracujący na komputerach i hobbyści/profesjonaliści, którzy na nich coś tam dłubią. Użytkownik MOSa wpada w taką kategorię, stąd amd64 (znane także również jako x86 64bit) jest dobrym wyborem, bo na rynku pc nadal zdecydowanie dominuje.
Microsyf chce windę na tabletach, to ich stare marzenie jeszcze z lat Windows 8 (kafelki!), stąd ich zamiary przenoszenia systemu na arm. Reszta producentów czuje zapach hajsu urządzeń mobilnych, stąd też chcą w ten rynek wchodzić. Mimo wszystko dostępność sprzętu amd64 (starego i nowego) w postaci pc (bo to nas interesuje) jest ekstremalna, a pogłoski o rychłej śmierci amd64 w kategorii desktopów rozdmuchane.
Z resztą... dajcie spokój... ja nie chcę zmieniać procesora i płyty głównej aby dodać sobie RAMu...
Ostatnia aktualizacja: 30.01.2024 21:27:17 przez Mario
30.01 23:27
[#29]
Re: Raspberry MorphOS
@Mario, post #28
Firmy odchodzą od PC, bo sprzedaż PC dramatycznie spada.
Coś w tym jest aczkolwiek uważam, że stacjonarki jako sprzęty ogólnego przeznaczenia celują w kategorię takiego semi-pro i coraz bardziej to widać (gry, audio/video, grafika, DTP etc.) dany user wiec co chce na stacjonarce robić i nie musi być to stricto profesjonalista.
Przeciętny człowiek używa telefonu do prawie wszystkiego.
Dokumenty czy inne tabelki to już laptopy, których jest całe zatrzęsienie lub sprzęty All-In-One. Każdy z nas potrzebuje coś wydrukować od czasu do czasu... niby się z mobili też da ale to nie to samo.
Microsyf chce windę na tabletach, to ich stare marzenie jeszcze z lat Windows 8 (kafelki!), stąd ich...A tu mi się coś nie zgadza bo jeżeli by wierzyć statystykom to rynek tabletów umiera i to skutecznie, już od lat, gdzie grubo ponad 50% całej sprzedaży rocznej stanowi iPad
,link a skoro M$ ubił linię telefonów to nie sadzę by teraz raptem chciał cokolwiek robić w tej materii i to jeszcze w kategorii tabletów, Apple zjada ich jakością i softem. (Surface w to nie wliczam to jest nisza w niszy). M$ już dawno przeniósł Win na ARM tylko działa to arcydramatycznie, a w stosunku do M1 nie ma podskoku już o kolejnych Mx nie ma co wspominać, a Intel przespał ostatnie 1,5 dekady robiąc nic/niewiele. Dlatego AMD to jedyny sensowny wybór jako desktop lub w postaci mobilnej jako laptopa. Liczę, że w tą stronę skręci MOST. Nie ma co ukrywać x86 dało by zastrzyk mocy pod aplikacje webowe oraz porty softu nie byłoby takie karkołomne przez 'indianowatość' dostęp do nowych technologii też byłby lepszy może nawet port Javy / czy .netcore byłby możliwy, oczywiście fantazjuje ale czemu by i nie pomarzyć :) Kto z nas, po upadku commodore sadził, iż dalej będzie się w 'amigowanie' bawił i to grube dekady po?
31.01 00:09
[#30]
Re: Raspberry MorphOS
@Mario, post #28
Co do Microsoftu, to przecież produkują swoje laptopy jak wiadomo. Z tabletami i smartfonami się już pożegnali. Widać to choćby po Windows 11, gdzie menu Start zaczyna na powrót przypominać to z Windows Vista/7.
A tablety Microsoftu były i na tanich tabletach i na trochę droższych właśnie z Windows 8. I nawet były takie tablety z procesorem ARM, z Windows 8. I to wszystko koniec, końców zdechło, bo soft który był na to dostępny, to była jakaś porażka.
I przecież były też smartfony z Windows 8 od Microsoftu, nawet sam taki miałem i koniec, końców też to zdechło, bo ilość dostępnego softu na to w stosunku do iPhone i Androida, to była rozpacz. Nawet nie było oprogramowania do obsługi aparatów słuchowych.
A co do popularności komputerów, to ja nie zauważyłem żeby liczba chętnych do kupowania spadała. Do domu kupują ludzie je do grania i potrafią mieć ich po kilka. Do biur też tego kupują dużo, a ostatnio jeszcze więcej, skoro Microsoft stwierdził że oficjalnie Windows 11 nie wspiera procesorów Intela od 7 generacji w dół i AMD Ryzen 1X00 oraz 2X00G w dół.
A tablety Microsoftu były i na tanich tabletach i na trochę droższych właśnie z Windows 8. I nawet były takie tablety z procesorem ARM, z Windows 8. I to wszystko koniec, końców zdechło, bo soft który był na to dostępny, to była jakaś porażka.
I przecież były też smartfony z Windows 8 od Microsoftu, nawet sam taki miałem i koniec, końców też to zdechło, bo ilość dostępnego softu na to w stosunku do iPhone i Androida, to była rozpacz. Nawet nie było oprogramowania do obsługi aparatów słuchowych.
A co do popularności komputerów, to ja nie zauważyłem żeby liczba chętnych do kupowania spadała. Do domu kupują ludzie je do grania i potrafią mieć ich po kilka. Do biur też tego kupują dużo, a ostatnio jeszcze więcej, skoro Microsoft stwierdził że oficjalnie Windows 11 nie wspiera procesorów Intela od 7 generacji w dół i AMD Ryzen 1X00 oraz 2X00G w dół.