Komentowana treść: A-EON i Hyperion - niewygodne wycieki
15.08.2018 16:50
[#31]
Re: A-EON i Hyperion - niewygodne wycieki
@mschulz, post #23
Struktura systemu Amiga OS nakreślona w ROM Kernel Reference Manual jest jasna i klarowna.
Podstawową biblioteką Amiga OS jest exec.library, która jest jedynym elementem bezwzględnym w hierarchii systemowej, tzn. dostęp do niego jest od razu (biblioteka ta jest zawsze otwarta).
Pozostałe biblioteki otwiera exec.library za pomocą funkcji OpenLibrary(). Po otrzymaniu dostępu, można używać sporej bazy funkcji bibliotecznych do grafiki, okien, schowka, lokalizacji, funkcji matematycznych, animacji, muzyki itp.
Jak widać architektura Amiga OS, którą opracował jeszcze zespół Commodore-Amiga był bardzo dalekowzroczny. Architektura w takim rozumieniu jest w pełni do przeniesienia na inne architektury, czy procesory.
Nawet typy wskaźnikowe, które są oznaczone specjalnym typem APTR oraz STRPTR mogą ulec przeniesieniu na architekturę 64-bitową.
Co do struktur, to można rozwinąć pomysł, który narodził się jeszcze w firmie Commodore i systemie 2.0 i polegał na wprowadzeniu elementów obiektowych - BOOPSI, a później w systemie 3.0 - Datatypów.
Zatem zawsze można uczynić strukturę Window prywatną i dać do niej dostęp z poziomu funkcji typu SetAttr() i odpowiednich list tagów.
Niewątpliwie Tagi oraz funkcje przyjmujące argumenty w listach tagów to kolejny element łatwy w rozszerzaniu, ponieważ można dodawać nowe typy Tagów.
Pewnym problemem mogłoby być wprowadzenie 64-bitowych pól tagów kompatybilnych z listami 32-bitowymi. Ale i to da się osiągnąć na kilka sposobów.
Oczywiście oprogramowanie musiałoby spełniać kilka zasad, by poprawnie działać na takim systemie.
64-bitowa przestrzeń adresowa i Endian to dosyć ważne zagadnienia, jednak jeżeli programy korzystałyby z funkcji matematycznych, czy typów całkowitych oraz wskaźnikowych w języku C bez oglądania się na ich budowę, to nie powinno sprawiać takiego trudu przenoszenie takich programów.
Ostatnia aktualizacja: 15.08.2018 16:55:37 przez Hexmage960
Podstawową biblioteką Amiga OS jest exec.library, która jest jedynym elementem bezwzględnym w hierarchii systemowej, tzn. dostęp do niego jest od razu (biblioteka ta jest zawsze otwarta).
Pozostałe biblioteki otwiera exec.library za pomocą funkcji OpenLibrary(). Po otrzymaniu dostępu, można używać sporej bazy funkcji bibliotecznych do grafiki, okien, schowka, lokalizacji, funkcji matematycznych, animacji, muzyki itp.
Jak widać architektura Amiga OS, którą opracował jeszcze zespół Commodore-Amiga był bardzo dalekowzroczny. Architektura w takim rozumieniu jest w pełni do przeniesienia na inne architektury, czy procesory.
Nawet typy wskaźnikowe, które są oznaczone specjalnym typem APTR oraz STRPTR mogą ulec przeniesieniu na architekturę 64-bitową.
Co do struktur, to można rozwinąć pomysł, który narodził się jeszcze w firmie Commodore i systemie 2.0 i polegał na wprowadzeniu elementów obiektowych - BOOPSI, a później w systemie 3.0 - Datatypów.
Zatem zawsze można uczynić strukturę Window prywatną i dać do niej dostęp z poziomu funkcji typu SetAttr() i odpowiednich list tagów.
Niewątpliwie Tagi oraz funkcje przyjmujące argumenty w listach tagów to kolejny element łatwy w rozszerzaniu, ponieważ można dodawać nowe typy Tagów.
Pewnym problemem mogłoby być wprowadzenie 64-bitowych pól tagów kompatybilnych z listami 32-bitowymi. Ale i to da się osiągnąć na kilka sposobów.
Oczywiście oprogramowanie musiałoby spełniać kilka zasad, by poprawnie działać na takim systemie.
64-bitowa przestrzeń adresowa i Endian to dosyć ważne zagadnienia, jednak jeżeli programy korzystałyby z funkcji matematycznych, czy typów całkowitych oraz wskaźnikowych w języku C bez oglądania się na ich budowę, to nie powinno sprawiać takiego trudu przenoszenie takich programów.
Ostatnia aktualizacja: 15.08.2018 16:55:37 przez Hexmage960
15.08.2018 16:54
[#32]
Re: A-EON i Hyperion - niewygodne wycieki
@Hexmage960, post #31
Wszystko to co piszesz jest piekne i madre, ale ja nie mowie o przenoszeniu programow. To jest jak najbardziej wykonalne czego dowodem jest AROS, ktory moze byc skompilowany na wiele roznych platform (big endian, little endian, 32bity, 64bity) z tych samych zrodel.
To o czym my tutaj piszemy to zachowanie zgodnosci binarnej wstecz. Czyli np. umozliwienie uruchomienia programu napisanego pod 32 bitowy AmigaOS na m68k (czy tez PowerPC) na przyklad na 64-bitowej architekturze little endian, chocby na takim x86_64.
A tego zrobic sie nie da i w tym caly problem.
To o czym my tutaj piszemy to zachowanie zgodnosci binarnej wstecz. Czyli np. umozliwienie uruchomienia programu napisanego pod 32 bitowy AmigaOS na m68k (czy tez PowerPC) na przyklad na 64-bitowej architekturze little endian, chocby na takim x86_64.
A tego zrobic sie nie da i w tym caly problem.
15.08.2018 17:11
[#33]
Re: A-EON i Hyperion - niewygodne wycieki
@mschulz, post #32
Zgadzam się. Binarnie nie ma zgodności. Z tego co wiem, to ludzie trzymają się PowerPC głównie ze względu na Big Endian (akurat PowerPC może pracować w obu trybach).
Pytanie tylko takie - skoro programy M68k zarówno na AmigaOS4 i MorphOS są uruchamiane za pomocą wbudowanego emulatora M68k, to czy rzeczywiście ten Endian ma w tym przypadku znaczenie?
Ja nie wiem do końca, ale podejrzewam, że te emulowane programy M68k korzystając z zasobów systemowych wywołują "prawdziwe" funkcje systemowe takiego AmigaOS4, czy MorphOS i wszelakie dane muszą być w Big Endian?
Pytanie tylko takie - skoro programy M68k zarówno na AmigaOS4 i MorphOS są uruchamiane za pomocą wbudowanego emulatora M68k, to czy rzeczywiście ten Endian ma w tym przypadku znaczenie?
Ja nie wiem do końca, ale podejrzewam, że te emulowane programy M68k korzystając z zasobów systemowych wywołują "prawdziwe" funkcje systemowe takiego AmigaOS4, czy MorphOS i wszelakie dane muszą być w Big Endian?
15.08.2018 19:39
[#35]
Re: A-EON i Hyperion - niewygodne wycieki
@Hexmage960, post #33
chodzi o kod mieszany. Masz binarke z nowego systemu, ktory korzysta z bibliotek ze starego np, albo odwrotne konfiguracje. Wtedy endiany maja znaczenie, gdzyz dostajesz dane, ktore musisz wiedziec jak zinterpretowac.
Przypomne, ze Morphos chcial pojsc droga Apple i zamknac wszystko w boksach (i w ten sposob uniezaleznic troche system od platform sprzetowych), ale poza aboksem nie powstalo nic wiecej niestety. Bo niestety kasa od BBRV sie skonczyla, a wiec praca na etacie zespolu programistow rowniez, zostala praca hobbystyczna, a ta jest wolniejsza i mniej planowalna.
Przypomne, ze Morphos chcial pojsc droga Apple i zamknac wszystko w boksach (i w ten sposob uniezaleznic troche system od platform sprzetowych), ale poza aboksem nie powstalo nic wiecej niestety. Bo niestety kasa od BBRV sie skonczyla, a wiec praca na etacie zespolu programistow rowniez, zostala praca hobbystyczna, a ta jest wolniejsza i mniej planowalna.
15.08.2018 19:44
[#36]
Re: A-EON i Hyperion - niewygodne wycieki
@Hexmage960, post #33
Ja nie wiem do końca, ale podejrzewam, że te emulowane programy M68k korzystając z zasobów systemowych wywołują "prawdziwe" funkcje systemowe takiego AmigaOS4, czy MorphOS i wszelakie dane muszą być w Big Endian?
Wszystko czego emulowany m68k moze "dotknac" musi byc w formacie 32bit BigEndian. Absolutnie wszystko.
15.08.2018 20:27
[#37]
Re: A-EON i Hyperion - niewygodne wycieki
@mschulz, post #36
@KaczusNG @MSchulz
Tak też podejrzewałem. Przykładowo jak program emulowany, skompilowany pod procesor M68k wywołuje OpenWindowTagList(), to zadziała, ponieważ wykonywana jest funkcja OpenWindowTagList() z systemu MorphOS/Amiga OS4, która - siłą rzeczy - musi pracować w taki sposób by program M68k "czuł się" jak w środowisku Amiga OS 3.x, czyli dostarczać struktury w akceptowalnym formacie, czyli 32-bitowe wskaźniki i Big-endian.
Dlatego szereg programów z Amiga OS 3.x zadziała pod MorphOSem i Amiga OS 4.
W takim razie, ludzie którzy zajmują się takimi rzeczami, w przypadku architektury Intelowskiej musieliby sprawić by konwersja danych następowała w locie, tj. wywoływane funkcje systemowe musiałyby dokonywać konwersji zamiany bajtów (i ew. konwersji wskaźników), żeby dostarczyć programowi danych w wymaganym formacie i poprawnie przekształcić dane, które program dostarcza systemowi.
Pewnie da się to zrobić, choć zawsze można skompilować programy pod nową architekturę i będą działać sprawniej. Jak zawsze kwestia tego, jaka jest siła robocza.
Z tego co słyszałem np. LibreOffice jeszcze nie został wydany. Co więcej, przy zmianie architektury większość binarek nada się do kosza (również ten LibreOffice!). Ludziom to nie przeszkadza, co mnie osobiście trochę dziwi.
Ale może to wynika z tego, że ja nie jestem jakoś specjalnie zaangażowanym fanem Amigi NG, choć parę rzeczy jest dla mnie interesujących (choć na pewno nie polityczno-prawne kwestie będące tematem newsa). Wolę swoją A1200.
Tak też podejrzewałem. Przykładowo jak program emulowany, skompilowany pod procesor M68k wywołuje OpenWindowTagList(), to zadziała, ponieważ wykonywana jest funkcja OpenWindowTagList() z systemu MorphOS/Amiga OS4, która - siłą rzeczy - musi pracować w taki sposób by program M68k "czuł się" jak w środowisku Amiga OS 3.x, czyli dostarczać struktury w akceptowalnym formacie, czyli 32-bitowe wskaźniki i Big-endian.
Dlatego szereg programów z Amiga OS 3.x zadziała pod MorphOSem i Amiga OS 4.
W takim razie, ludzie którzy zajmują się takimi rzeczami, w przypadku architektury Intelowskiej musieliby sprawić by konwersja danych następowała w locie, tj. wywoływane funkcje systemowe musiałyby dokonywać konwersji zamiany bajtów (i ew. konwersji wskaźników), żeby dostarczyć programowi danych w wymaganym formacie i poprawnie przekształcić dane, które program dostarcza systemowi.
Pewnie da się to zrobić, choć zawsze można skompilować programy pod nową architekturę i będą działać sprawniej. Jak zawsze kwestia tego, jaka jest siła robocza.
Z tego co słyszałem np. LibreOffice jeszcze nie został wydany. Co więcej, przy zmianie architektury większość binarek nada się do kosza (również ten LibreOffice!). Ludziom to nie przeszkadza, co mnie osobiście trochę dziwi.
Ale może to wynika z tego, że ja nie jestem jakoś specjalnie zaangażowanym fanem Amigi NG, choć parę rzeczy jest dla mnie interesujących (choć na pewno nie polityczno-prawne kwestie będące tematem newsa). Wolę swoją A1200.
16.08.2018 08:24
[#39]
Re: A-EON i Hyperion - niewygodne wycieki
@mschulz, post #36
Wygląda na to, ze przejście na PPC niczego poza wyższym taktowaniem nie dało? Po tylu latach warto zapytać i co opłacało się, skoro system Amigi ma problem z dostosowaniem się do architektury PPC i w zasadzie albo zerwiemy kompatybilność, albo wykorzystamy moc procka? Dobrze zrozumiałem?
Ostatnia aktualizacja: 16.08.2018 08:25:21 przez KM
Ostatnia aktualizacja: 16.08.2018 08:25:21 przez KM
16.08.2018 08:25
[#40]
Re: A-EON i Hyperion - niewygodne wycieki
@Hexmage960, post #37
Teraz pytanie, skąd system ma wiedzieć, że dany wskaźnik jest w/g architektury Intel'a, a który w/g architektury Motoroli? Nawet jeśli system będzie wiedział - to skąd ma to wiedzieć np. jakaś antyczna biblioteka GUI m68k, która z jakiegoś powodu też tego wskaźnika używa?
Poza tym... endianess i bitowość to tylko część większego problemu. Świat desktopowych komputerów obecnie zachwyca się procesorami 8-rdzeniowymi, 16-rdzeniowymi, gdzieś tam na horyzoncie majaczą 32-rdzeniowe (i to jeszcze z hyperthreadingiem). Rozwiążesz problem bitowości, jak dodasz porządne wsparcie dla wielu rdzeni przy przeklętej funkcji forbid? Jakoś załatwisz wielordzeniowość - jak dodasz wsparcie dla architektury NUMA (na razie dotyczy tylko Threadrippera czy Core i9, ale to się może za kilka lat zmienić). Jak wprowadzisz śledzenie zasobów i ochronę pamięci pomiędzy procesami,?
Przykro mi, ale AmigaOS jest tak przestarzały, że szkoda gadać :) Pierwotne podejście MorphOS'a (ABOX i inne boksy) było jedyną słuszną drogą - niestety, nie zostało zaimplementowane.
Poza tym... endianess i bitowość to tylko część większego problemu. Świat desktopowych komputerów obecnie zachwyca się procesorami 8-rdzeniowymi, 16-rdzeniowymi, gdzieś tam na horyzoncie majaczą 32-rdzeniowe (i to jeszcze z hyperthreadingiem). Rozwiążesz problem bitowości, jak dodasz porządne wsparcie dla wielu rdzeni przy przeklętej funkcji forbid? Jakoś załatwisz wielordzeniowość - jak dodasz wsparcie dla architektury NUMA (na razie dotyczy tylko Threadrippera czy Core i9, ale to się może za kilka lat zmienić). Jak wprowadzisz śledzenie zasobów i ochronę pamięci pomiędzy procesami,?
Przykro mi, ale AmigaOS jest tak przestarzały, że szkoda gadać :) Pierwotne podejście MorphOS'a (ABOX i inne boksy) było jedyną słuszną drogą - niestety, nie zostało zaimplementowane.
16.08.2018 08:58
[#41]
Re: A-EON i Hyperion - niewygodne wycieki
@Cedrat, post #40
Przykro mi, ale AmigaOS jest tak przestarzały, że szkoda gadać :)
Sama architektura Amiga OS, opisana w ROM Kernel Reference Manual wskazuje na to, że jej projektanci myśleli daleko do przodu. Architektura tego systemu w takim rozumieniu jest przygotowana na zaadaptowanie do innych platform.
Jednak rzeczywiście jest to koncepcja, zaś w rzeczywistym Amiga OS brakuje wielu komponentów w tym np. ochrony pamięci, bądź śledzenia zasobów, lecz wprowadzenie ich jest możliwe przy zachowaniu założeń architektury.
Z tego co wiem, śledzenie zasobów było planowane w Amiga OS. Akurat tą rzecz da się wprowadzić wyjątkowo łatwo.
Na poziomie API Amiga OS nie jest przestarzały, gdyż w takim rozumieniu jego architektury może być zaadaptowany do innych platform. Wystarczy zachować hierarchię systemową z exec.library w jej korzeniu, lecz oczywiście cały kod odpowiedzialny za poszczególne składniki musiałby być zmodernizowany.
Programy musiałyby być skompilowane na nowo na podstawie źródeł.
Stare programy systemowe musiałyby pracować w jakimś środowisku, w którym funkcje systemowe dbałyby o konwersję little/big-endian w obie strony.
Także podsumowując: w teorii Amiga OS jest możliwy do przeniesienia nawet na inne procesory, architektury, wiele rdzeni itd.
W praktyce jednak jest mniej różowo - ponieważ wielu komponentów brakuje, zaś ich wprowadzenie jest bardzo kosztowne.
W Commodore już w NDK 3.1 namawiano na korzystanie z systemowych bibliotek, przewidując co się będzie działo w przyszłości.
Amiga OS jest przestarzały w kwestii komponentów, których brakuje, a ich uzupełnienie to masa pracy. A siły roboczej brakuje.
Dlatego ja jestem przeciwnikiem zmiany architektury. Zbyt wiele rzeczy trzeba by pisać od nowa, podczas gdy programiści nie nadążają z przenoszeniem gotowych programów.
P.S. Tak nawiasem mówiąc, to nie trzeba było się przenosić już z Amigi na AmigaOne.
Ostatnia aktualizacja: 16.08.2018 09:03:09 przez Hexmage960
16.08.2018 09:23
[#42]
Re: A-EON i Hyperion - niewygodne wycieki
@Hexmage960, post #41
Sama architektura Amiga OS, opisana w ROM Kernel Reference Manual wskazuje na to, że jej projektanci myśleli daleko do przodu. Architektura tego systemu w takim rozumieniu jest przygotowana na zaadaptowanie do innych platform.
Nie. Jezeli chcialbys patrzec w ten sposob to *kazdy* system operacyjny jest napisany tak ze jest przygotowany na zaadaptowanie do innych platform. Dlaczego nie? Skoro API jest opisane?
PS: Windows tez byl na procesory PPC czy Alpha... I co z tego?
Na poziomie API Amiga OS nie jest przestarzały, gdyż w takim rozumieniu jego architektury może być zaadaptowany do innych platform.
Na poziomie API AmigaOS jest cholernie przestarzaly. Absolutnie nie nadaje sie (bez zrywania kompatybilnosci binarnej) do zmiany architektury z BE na LE, z 32 na 64 bity, do dodania SMP czy ochrony pamieci.
Programy musiałyby być skompilowane na nowo na podstawie źródeł.
Przykro mi to stwierdzic, ale to absolutnie nie swiadczy o nowoczesnosci (czy chociazby dalekowzrocznosci) tworcow AmigaOS.
Stare programy systemowe musiałyby pracować w jakimś środowisku, w którym funkcje systemowe dbałyby o konwersję little/big-endian w obie strony.
Nie da sie. Mozesz mi wierzyc na slowo, dyskusje na ten temat powtarzaja sie co pare lat i co pare lat koncza w ten sam sposob - stwierdzeniem ze sie nie da.
Wiesz kiedy mozna by bylo taka konwersje robic? Gdyby np. taka funkcja jak OpenWindow nie zwracala wskaznika na publicznie opisana strukture w ktorej mozna grzebac (struct Window), tylko gdyby zwracala jakis nic nie znaczacy numer (uchwyt) ktorego uzywalbys do badania/zmieniania stanu okna, cos jak GetWindowAttr(handle, attr) SetWindowAttr(handle, attr, value), i tak samo dla wszystkich objektow/struktur i innych danych zarzadzanych przez system. Wtedy i tylko wtedy moglbys dokonywac dosc bezstresowej konwersji miedzy endianami, 32bit, 64bit i zapewnic sobie w miare sensowna kompatybilnosc binarna wstecz. Co do wielu rdzeni to jest jeszcze gorzej. Mechanizmy blokujace w systemie sa fatalne (Forbid()/Permit() i Disable()/Enable()) a te ktore sa w miare sensowne sa bardzo ciezkie do poprawy.
Ale to tylko gdybanie. Takich funkcji (poza BOOPSI) nie bylo i nie byly uzywane, programy grzebaly w bebechach systemu i nic juz tego nie zmieni. Mozna by pomyslec o napisaniu zupelnie nowego systemu (OS5?) i totalnym odcieciu sie od korzeni (UAE do uruchamiania zabytkow), ale spotkalo by sie to z totalnym oporem srodowiska i typowa bolaczka nowych systemow - brakiem oprogramowania.
Taki przyklad jeszcze: w wersji SMP AROS-a trzeba bylo dodac nowe mechanizmy blokujace (spinlock) ktore sa wbudowane np. w strukture MessagePort (bo musza, inaczej nie dalo by sie uzywac MsgPort do przesylania wiadomosci miedzy procesorami). Jaki jest tego skutek? Nawet stare AROSowe programy skompilowane pod x86_64 musza byc przekompilowane na nowo pod wersje SMP, bo rozmiar struktury sie zmienil. Co gorsza, trzeba koniecznie uzyc funkcji systemowej CreateMsgPort. Stary sposob uzywany przez niektore programy (np. stworzenie MsgPort na stosie czy w pamieci i zainicjalizowanie "na piechote") nie zadziala bo stary kod nie ma wiedzy jak zainicjalizowac spinlocka.
Także podsumowując: w teorii Amiga OS jest możliwy do przeniesienia nawet na inne procesory, architektury, wiele rdzeni itd.
Z zerwaniem kompatybilnosci wstecznej na poziomie binariow i kodu? Tak. Dokladnie tak samo jak dowolny inny kawalek softu.
W Commodore już w NDK 3.1 namawiano na korzystanie z systemowych bibliotek, przewidując co się będzie działo w przyszłości.
Wtedy juz bylo za pozno.
16.08.2018 10:48
[#43]
Re: A-EON i Hyperion - niewygodne wycieki
@Cedrat, post #40
Jak wprowadzisz śledzenie zasobów i ochronę pamięci pomiędzy procesami,?
Przykro mi, ale AmigaOS jest tak przestarzały, że szkoda gadać :)
Nareszcie ktoś dotknął sedna problemu. Cechy systemu Amigi które były wielkimi zaletami i były rewolucyjne w 1985, stały się dziś balastem i kulą u nogi.
Jest to analogiczna sytuacja jaka była kiedyś z amigowym chipsetem - w 1985 roku to była rewolucja, a kilka lat później założenia które pasowały idealnie do 1985 roku stały się anachronizmem i hamulcem rozwoju. Stąd porzucenie chipsetu przez NG i osadzenie UAE które ma zapewnić kompatybilność z softem które go wymaga.
Teraz czas na konsekwentną decyzję - skoro odrzucamy jeden przestarzały element, to dlaczego mamy pielęgnować i podtrzymywać przy życiu inny przestarzały element - AmigaOS4 - który jest obecnie tylko balastem i hamulcem na nowszym hardware? Może był nieco bardziej odporny na upływ czasu niż chipset, ale jak widać czas go w końcu dogonił i przyszła na niego pora.
Aby być konsekwentnym, trzeba zrobić analogicznie jak z chipsetem - opakować to w jakiś emulator (np. QEMU) i nadbudować nad tym naprawdę nowoczesny system. Tylko tu się pojawia pytanie wyższego rzędu - po co i dla kogo?
Podsumowując - udawanie w 2018 roku że cechy systemu Amigi zabetonowane w 1985 roku są nowoczesne jest równie zabawne dziś jak kiedyś dla zwolenników NG zabawny był starzejący się chipset i jego zwolennicy. Tylko, że dziś AmigaOS4 sam znalazł się w takiej sytuacji.
16.08.2018 12:02
[#45]
Re: A-EON i Hyperion - niewygodne wycieki
@jubi, post #43
@Jubi
Te cechy nie pojawiły się w 1985 roku. Tak naprawdę system Amigi dojrzał i w wersji 2.0 zaczął nabierać coraz lepszych cech. Wersja 3.0 posiadła wiele nowych własności. Ostatnia wersja od Commodore wydana została w 1993 roku dla Amigi CD32.
System Amigi był cały czas rozwijany, on nie stał w miejscu.
Wystarczy poczytać o osiągnięciach na polu Amigi wybitnych programistów z tamtego okresu (konferencje deweloperskie w Stanach Zjednoczonych).
No niestety, kilka lat po 1985 chipset nie stał się hamulcem rozwoju. Również NG nie powstało kilka lat po 1985 roku. Chipset, obok systemu też był rozwijany. Dzięki temu rozwojowi powstał ECS i AGA.
Niestety zainteresowanie Amigą topniało szybko. I dlatego też pewne własności AGA nie zostały należycie docenione.
Zapewne "dzisiejszy Amiga OS" musiałby stawić czoła nowościom technologicznym. Jednak w latach 1985-1994 Amiga rozwijała się prężnie i bez problemu nadążała za postępem technologicznym. Ba, nawet w 1995-1997 tak było, za czasów Escomu.
Dopiero w latach 1998-1999 nastąpił kryzys.
Mija ponad 30 lat od premiery Amigi. Mamy za sobą parę "przygód" z firmami typu Viscorp, Gateway 2000, Amino, które po bankructwie Escomu przejmowały prawa do marki.
Jeśli ktoś lubi nadal Amigę i rzeczy z nią powiązane, typu system operacyjny (oraz takie nienamacalne obiekty jak filozofia systemu) to może bez problemu tę sympatię wyrażać w różny sposób.
Po co jednakowoż wchodzić sobie w drogę? Dla kolegi - nie wiem, czy Amiga to relikt przeszłości, lub chociaż rzecz sentymentalna. Jako że wyraża kolega swoją antypatię do systemu Amiga OS w tej czy innej postaci, szuka prawidłowości, które tym rządzą i dzieli się nimi, rozumiem że prawie nic z Amigi nie zostało, co mogłoby wzbudzać w koledze jakieś pozytywne emocje?
Rozumiem, że system 1.3, Amiga 500 i Real3D coś tam wzbudzają. Ale czy jest coś jeszcze? I co ważne, czy późniejsze losy Amigi kolegę interesują? Czy jednak bankructwo Commodore to był definitywny koniec?
Podsumowując - udawanie w 2018 roku że cechy systemu Amigi zabetonowane w 1985 roku są nowoczesne jest równie zabawne
Te cechy nie pojawiły się w 1985 roku. Tak naprawdę system Amigi dojrzał i w wersji 2.0 zaczął nabierać coraz lepszych cech. Wersja 3.0 posiadła wiele nowych własności. Ostatnia wersja od Commodore wydana została w 1993 roku dla Amigi CD32.
System Amigi był cały czas rozwijany, on nie stał w miejscu.
Wystarczy poczytać o osiągnięciach na polu Amigi wybitnych programistów z tamtego okresu (konferencje deweloperskie w Stanach Zjednoczonych).
Jest to analogiczna sytuacja jaka była kiedyś z amigowym chipsetem - w 1985 roku to była rewolucja, a kilka lat później założenia które pasowały idealnie do 1985 roku stały się anachronizmem i hamulcem rozwoju. Stąd porzucenie chipsetu przez NG i osadzenie UAE które ma zapewnić kompatybilność z softem które go wymaga.
No niestety, kilka lat po 1985 chipset nie stał się hamulcem rozwoju. Również NG nie powstało kilka lat po 1985 roku. Chipset, obok systemu też był rozwijany. Dzięki temu rozwojowi powstał ECS i AGA.
Niestety zainteresowanie Amigą topniało szybko. I dlatego też pewne własności AGA nie zostały należycie docenione.
Zapewne "dzisiejszy Amiga OS" musiałby stawić czoła nowościom technologicznym. Jednak w latach 1985-1994 Amiga rozwijała się prężnie i bez problemu nadążała za postępem technologicznym. Ba, nawet w 1995-1997 tak było, za czasów Escomu.
Dopiero w latach 1998-1999 nastąpił kryzys.
Mija ponad 30 lat od premiery Amigi. Mamy za sobą parę "przygód" z firmami typu Viscorp, Gateway 2000, Amino, które po bankructwie Escomu przejmowały prawa do marki.
Jeśli ktoś lubi nadal Amigę i rzeczy z nią powiązane, typu system operacyjny (oraz takie nienamacalne obiekty jak filozofia systemu) to może bez problemu tę sympatię wyrażać w różny sposób.
Po co jednakowoż wchodzić sobie w drogę? Dla kolegi - nie wiem, czy Amiga to relikt przeszłości, lub chociaż rzecz sentymentalna. Jako że wyraża kolega swoją antypatię do systemu Amiga OS w tej czy innej postaci, szuka prawidłowości, które tym rządzą i dzieli się nimi, rozumiem że prawie nic z Amigi nie zostało, co mogłoby wzbudzać w koledze jakieś pozytywne emocje?
Rozumiem, że system 1.3, Amiga 500 i Real3D coś tam wzbudzają. Ale czy jest coś jeszcze? I co ważne, czy późniejsze losy Amigi kolegę interesują? Czy jednak bankructwo Commodore to był definitywny koniec?
16.08.2018 12:29
[#47]
Re: A-EON i Hyperion - niewygodne wycieki
@mschulz, post #42
Przykro mi to stwierdzic, ale to absolutnie nie swiadczy o nowoczesnosci (czy chociazby dalekowzrocznosci) tworcow AmigaOS.
Generalnie uważam, że ulokowanie tylko bazy exec pod adresem bezwzględnym $4, brak sztywnej mapy pamięci oraz namawianie programistów, by przestrzegali wszystkich reguł programowania pod Amiga OS świadczy o takiej dalekowzroczności.
Oczywiście wszystko ma swoje granice. Ludzie w tamtych latach nie wyobrażali sobie jeszcze 64-bitowego adresowania, czy wielu rdzeni procesora. Pewnie gdyby Commodore przetrwało próbę czasu, system ewoluował by, ale to co chciałem pokazać, że system Amigi był całkiem dobry i nowoczesny już od początku.
No cóż, głównie dla amigowców. Bo taka smutna prawda, poza naszą wąską grupą nikt inny tym systemem się nie interesował i nie odkrył jego walorów.
Mechanizmy blokujace w systemie sa fatalne (Forbid()/Permit() i Disable()/Enable()) a te ktore sa w miare sensowne sa bardzo ciezkie do poprawy.
Hmm... szkoda że platforma Amiga nie rozwijała się wraz z systemem. Obecnie mamy parę platform w miarę nowoczesnych (przy czym AmigaOne są bardzo drogie) i system rozwijany w trzech różnych gałęziach.
Mamy też gałąź zwaną "retro". Dla mnie jednak jest to najciekawsza z tych wszystkich gałęzi.
Fajnie wyobrażać sobie, co by było gdyby Commodore nie zbankrutował. Tak jak napisałem zainteresowanie Amigą było w 1993 niewielkie. Wystarczy spojrzeć ile powstało wtedy gier.
Ciekawe czy przy tak małym zainteresowaniu Amiga by przetrwała. No, bo ostatnim produktem od Commodore była Amiga CD32, zaś Escom postawił na reedycję Amig 1200/4000 z systemem 3.1 oraz - dodatkowym oprogramowaniem (dość nowoczesnym).
My, "mali" użytkownicy musieliśmy się z tym pogodzić. I ja cenię sobie Amigę 1200 od Escomu najbardziej, bo dzięki Escomowi mam Amigę. Bez Escomu może wyszłaby jakaś platforma - ale pewnie bardzo droga.
Kiedy Amigowcy zaczęli robić swoje "Amigi" zaczęły się kłopoty. A nastąpiło to ok. roku 1998-1999. Może i kogoś stać na AmigiOne, ale są też ludzie biedniejsi.
Dla kogoś Amiga klasyczna to "archeologia" i brak rozwoju. Ja uważam jednak, że można się sporo z tamtych czasów nauczyć, wyciągnąć wnioski. Można obcować z tamtą kulturą Amigi, która oferuje jeszcze wiele ciekawego.
16.08.2018 12:40
[#48]
Re: A-EON i Hyperion - niewygodne wycieki
@Hexmage960, post #45
Te cechy nie pojawiły się w 1985 roku. Tak naprawdę system Amigi dojrzał i w wersji 2.0 zaczął nabierać coraz lepszych cech
Nie chodzi o powierzchowną pozłotkę typu datatypy itd. ale o core, którego założenia nie zmieniły się nigdy a które ładnie tu wyłuszczył mschulz. Podobnie było z chipsetem, rozwijał się tak, żeby nie naruszyć podstawowych założeń i te niezmienione zostały aż do końca.
Tylko teraz niektórzy zwolennicy OS4 potrafią kpić z chipsetu który założeniami tkwi w 1985 roku, a nie widzą tego, że ten system też tam tkwi i że to już też stało się problemem nie do obejścia i trzeba go będzie w całości odrzucić tak jak odrzucili wcześniej chipset.
16.08.2018 12:48
[#49]
Re: A-EON i Hyperion - niewygodne wycieki
@jubi, post #48
Nie chodzi o powierzchowną pozłotkę typu datatypy itd. ale o core, którego założenia nie zmieniły się nigdy a które ładnie tu wyłuszczył mschulz. Podobnie było z chipsetem, rozwijał się tak, żeby nie naruszyć podstawowych założeń i te niezmienione zostały aż do końca.
Ciekawe rzeczy kolega tu mówi. A czy kolejne odsłony systemu Windows zmieniły swoje podstawowe założenia? Interfejs użytkownika jest bardzo podobny, a ponadto biblioteki standardowe pozostały nadal (WinAPI) i tylko zabudowuje się różnej maści frameworkami.
Powstały dodatkowe funkcje do obsługi 64-bitowego adresowania jak GetWindowLongPtr().
Jak programuję pod WinAPI to widzę wiele analogii do systemu Amiga OS. Te systemy są podobne, choć różnią się w niektórych kwestiach.
Zaś jeśli kolega uważa datatypy za pozłotki to nie zna ich prawdziwej wartości. Przecież dzięki datatypom Amiga OS 3.0 wzbogacił się standardowo o obsługę tekstu FTXT, obrazów ILBM, animacji ANIM, filmów CDXL, dźwięków 8SVX, dokumentów AmigaGuide, z oczywistą możliwością rozbudowy o inne typy danych.
Ostatnia aktualizacja: 16.08.2018 12:50:16 przez Hexmage960
16.08.2018 13:56
[#51]
Re: A-EON i Hyperion - niewygodne wycieki
@Sventevith, post #9
Czy naprawdę nie było dostępnych innych procesorów niż e500 ?
Nie wiem czy były, takie pytanie to powinieneś skierować do A-EONu. Jedyne co wiadomo to fakt iż MOSTeam wywieśił bialą flagę z napisem "nie da się niekompatybilny procesor" i że prawdopodobnie Hyperion musiał odpowiedzieć że jednak się da, bo nie wierzę by w przeciwnym wypadku A-EON wchodził w Tabora.
Teraz jedyne pytanie jest takie czy Hyperion jedynie się przechwalał i poległ, czy jednak dał radę. Szczerze powiedziawszy, to ja już odpowiedź na to pytanie znam, a i myślę że Ty jak i inni zainteresowani, wkrótce ją poznacie.
16.08.2018 14:05
[#52]
Re: A-EON i Hyperion - niewygodne wycieki
@MUFA-amigaone-pl, post #51
Małe sprostowanie. MorphOS Team nie powiedział, że się nie da tylko, że ilość pracy jest nieproporcjonalna do tego jakie efekty może przynieść i że lepiej dajmy na to zająć się Jitem w OWB niż marnować czas na pisanie emulatora FPU. Po latach (ponad trzech) wyszło, że skończyło się na tym, że przewidywania MorphOS Teamu się sprawdziły. AEon/Hyperion zaliczył solidną obsuwę w dostarczeniu sprzętu/systemu. Mam nadzieje, że Hyperion mnie pozytywnie zaskoczy bo jeśli upupili 2, 3 lata i emulator FPU nadal nie będzie wystarczająco szybki to będzie to oznaczało koniec marzeń czerwonej częsci amigowego środowiska na tanią, względnie szybką maszynę.
ps. w informatyce nie ma tak, że się czegoś nie da, zawsze jest to związek pieniędzy czasu i ludzi.
Ostatnia aktualizacja: 16.08.2018 14:09:06 przez michal_zukowski
ps. w informatyce nie ma tak, że się czegoś nie da, zawsze jest to związek pieniędzy czasu i ludzi.
Ostatnia aktualizacja: 16.08.2018 14:09:06 przez michal_zukowski
16.08.2018 15:00
[#54]
Re: A-EON i Hyperion - niewygodne wycieki
@michal_zukowski, post #50
Taka jest różnica między chipsetem a systemem. Co więcej, dla użytkownika teoretycznie podstawione elementy będą/byłyby niewidoczne.
Nie ma większej różnicy pomiędzy jednym a drugim, bo wszystko jak napisałeś niżej jest kwestią nakładu czasu i pieniędzy. Gdyby mieć odpowiedni budżet dałoby się zbudować chipset który pracowałby jednocześnie w starym trybie dla kompatybilności i w nowym dla nowych funkcji. Tylko że design i produkcja takich układów to niesamowite nakłady pieniędzy i taniej jest wziąć z półki jakiś gotowy chipset a kompatybilność zapewnić programowo przez UAE.
Tak samo jest z OS4 - teoretycznie dałoby się wielkim nakładem czasu i pieniędzy i zbudować jakiś mechanizm który przełączałby stary i nowy tryb i dawał nowym programom dostęp np. do ochrony pamięci. Jednak taniej i szybciej będzie zamknąć ten antyczny i przestarzały system w emulatorze QEMU i nad tym zbudować coś nowego - takie jest racjonalne rozwiązanie.
Ale obaj wiemy, że tu nie rządzi racjonalność tylko emocje i przywiązanie do archaizmów, które w umysłach niektórych na zawsze pozostaną "NG" chociaż dawno już minął ich okres przydatności do spożycia.
16.08.2018 15:21
[#55]
Re: A-EON i Hyperion - niewygodne wycieki
@stefkos, post #53
Widzisz, znowu to robisz, znowu piszesz cos co nie jest prawda. No ale dobrze ze rzookol juz napisal jak to naprawde wyglada.
Nie ma żadnego oficjalnego oświadczenia ze strony MOSTeamu, więc trudno zarzucać mi klamstwo. Możesz mi co najwyżej zarzucić niewłaściwą interpretację słów, jakie pojawiają się na forach.
Przypomnę że rzookol pod pierwszym newsem o Taborze wypowiedział się trzykrotnie.
Pierwszy raz po prostu napisał MorphOSa na to nie będzie. Za drugim razem jeszcze dodał że targetem dla tego sprzętu jest, cytuje "czerwona biedota". A potem wreszcie rozwinął że ludzie od AmigaOS dostali procka bez FPU i trzy lata na napisanie sterowników. W związku z czym Morphosa na to nie będzie.
Nie ma jasno nigdzie żadnego oświadczenia, którego można by się trzymać i zarzucać mi nieprawdę. Jak mówię tego typu wypoweidzi można róznie interpretować, przecież trzy lata to jest nic dla MOSa. Zobacz że MOS ze wsparciem dla płyty Cyrus (celowo nie używam nazwy X5000 bo wtedy akurat bym skłamał), wyszedł prawie 2 lata po wersji dla AmigaOS, a w sumie od ogłoszenia wsparcia do realizacji komercyjnej, uplynęło chyba ze 4 lata.
16.08.2018 15:25
[#56]
Re: A-EON i Hyperion - niewygodne wycieki
@MUFA-amigaone-pl, post #55
Nie ma żadnego oficjalnego oświadczenia ze strony MOSTeamu, więc trudno zarzucać mi klamstwo.
Jest dokładnie odwrotnie. Ponieważ najprawdopodobniej napisałeś nieprawdę, wypadałoby albo poprzeć ją oficjalnym oświadczeniem (cytuję: fakt iż MOSTeam wywieśił bialą flagę z napisem "nie da się niekompatybilny procesor), albo odwołać.
Ostatnia aktualizacja: 16.08.2018 15:26:27 przez recedent
16.08.2018 15:32
[#57]
Re: A-EON i Hyperion - niewygodne wycieki
@MUFA-amigaone-pl, post #55
Nie ma żadnego oficjalnego oświadczenia ze strony MOSTeamu, więc trudno zarzucać mi klamstwo.
Wiec mogles napisac dokladnie w ten sposob, ze stanowisko MOSTeamu w kwestii tej plyty jest niejasne badz nieokreslone. Nie chce sie czepiac sformulowan, ale sam napisales: <<Jedyne co wiadomo to fakt iż MOSTeam wywieśił bialą flagę z napisem "nie da się niekompatybilny procesor">> a to juz jest ogromna nadinterpretacja.
Nie ma jasno nigdzie żadnego oświadczenia, którego można by się trzymać i zarzucać mi nieprawdę.
Znowu przesadzasz. Rzookol napisal "MorphOS-a na to nie bedzie" a Ty to odczytales jako "nie da sie". A jezeli ja Ci napisze ze AmigaOS4 na MacMini nie bedzie, tez odczytasz to jako "Nie da sie"? Przeciez wiesz, ze sie da, a jednak taka wersja nie powstanie, prawda? Jezeli nikt nie przeportuje AROS-a na X1000, AmigaOne czy jakikolwiek inny komputer, to czy oznacza to ze "nie da sie"? A moze po prostu nikomu sie portowac nie chce?
Zobacz że MOS ze wsparciem dla płyty Cyrus (celowo nie używam nazwy X5000 bo wtedy akurat bym skłamał), wyszedł prawie 2 lata po wersji dla AmigaOS, a w sumie od ogłoszenia wsparcia do realizacji komercyjnej, uplynęło chyba ze 4 lata.
Moze po prostu nie bylo to ich priorytetem? Nie wiem, zgaduje tylko. Ale jako osoba nie posiadajaca wiedzy nie posuwalbym sie zbyt daleko w wyciaganiu wnioskow i interpretowaniu tego "co autor mial na mysli"...
16.08.2018 15:37
[#58]
Re: A-EON i Hyperion - niewygodne wycieki
@MUFA-amigaone-pl, post #55
Na tym portalu kazdy wypowiada sie za siebie w komentarzach, nie bylo zadnej informacji oficjalnej. Na stronie MorphOS Teamu znajdziesz wszystkie oficjalne informacje, na ktorych "wydanie" zgodzili sie wszyscy w grupie. Rozumiem ze kolejny Twoj wpis mam odczytac jako kolejne oswiadczenie Hyperionu/AEON'u?
Robienie wersji MOS'a dla Tabora to strata czasu co pokazuje rowniez obsuwa wydania os4 (tak to moje zdanie, nie zadne oficjalne MOSTeamu).
Robienie wersji MOS'a dla Tabora to strata czasu co pokazuje rowniez obsuwa wydania os4 (tak to moje zdanie, nie zadne oficjalne MOSTeamu).
16.08.2018 15:41
[#59]
Re: A-EON i Hyperion - niewygodne wycieki
@recedent, post #56
Ok, odwołuję MOSTeam nie wywiesił białej flagi i nie odniósł się w jakikolwiek sposób do kwestii Tabora.
Jedyne pewne informacje jakie udało się uzyskać na łamach PPA od jednego z przedstawicieli teamu, to fakt iż jest to sprzęt dla czerwonej biedoty, nie ma FPU i że Hyperionowi zajmie trzy lata na napisanie sterowników, to są powody dla któreych zdaniem rzookola nie MOSteam nie podjął się przepisania systemu na ten sprzęt.
Teraz napisałem jak było w rzeczywistości, choć jeszcze raz podkreślam że lepsze byłoby jednak jakieś oficjalne oświadczenie w stylu.
"Oczywiście moglibyśmy tego dokonać. Uważamy jednak że oprogramowanie Tabora zajmie wiele lat pracy i wiele zasobów, wobec tego wolimy w tym czasie poświęcić się innym zadaniom" - Wtedy by było jasno i dobitnie i nie prowokowałoby do interpretacji.
Jedyne pewne informacje jakie udało się uzyskać na łamach PPA od jednego z przedstawicieli teamu, to fakt iż jest to sprzęt dla czerwonej biedoty, nie ma FPU i że Hyperionowi zajmie trzy lata na napisanie sterowników, to są powody dla któreych zdaniem rzookola nie MOSteam nie podjął się przepisania systemu na ten sprzęt.
Teraz napisałem jak było w rzeczywistości, choć jeszcze raz podkreślam że lepsze byłoby jednak jakieś oficjalne oświadczenie w stylu.
"Oczywiście moglibyśmy tego dokonać. Uważamy jednak że oprogramowanie Tabora zajmie wiele lat pracy i wiele zasobów, wobec tego wolimy w tym czasie poświęcić się innym zadaniom" - Wtedy by było jasno i dobitnie i nie prowokowałoby do interpretacji.