Wiesz, w takiej rozdzielczosci z amigowymi programami pracuje od paru lat, a w ciut mniejszej od bardzo wielu lat....

Swoje pytanie powinieneś zadać na jakimś linuksowym portalu, jak Ci to ktoś już odpowiedział. I zapewne otrzymałbyś odpowiedź zgodną z obiektywną linuksową prawdą - że Amiga jako taka nie nadaje się do niczego poza prostym terminalem linuksowym, a większość programów to i tak amigowe porty linuksowych bibliotek (jak np. stara się mnie co co jakiś czas uświadamiać w temacie AmiGG, czy kiero w przypadku sterowników graficznych). Więc - po co? ;) Po jaką cholerę komu amigowe oprogramowanie na linuksie? AmigaOS używa się dla samego AmigaOS, a programów amigowych na systemie amigowym... To jest swoista całość, jedno bez drugiego nie ma po prostu sensu.

Jako że widać gołym okiem, iż ciężko Ci idzie składne formułowanie myśli, i jako że wreszcie udało Ci się w miarę składnie określić to, o co Ci chodziło, to postaram się w miarę prosto na całość kwestii odpowiedzieć.


Pierwsza sprawa - odnośnie ogólnego konceptu Twojego pomysłu. Oczywiście jest możliwe to co piszesz - takie "amigawine" na linuksie. Ale o ile w przypadku wine, czy winex miało to jakiś sens (brak odpowiedników linuksowych windzianych gier i programów), to w przypadku takiego twora jakim było by "to coś" co proponujesz - nie widzę żadnego sensu, przez pryzmat pracy jaki by w to trzeba było włożyć. Uwierz, jeśli nie rozumiesz dlaczego, to po prostu się postaraj - to nie były by takie proste "wrappery" jak sądzisz. W systemowych programach nie wystarczy tylko emulować wywołań systemowych funkcji, potrzebna jest pełna interakcja pod postacią emulacji zawartości struktur, eventów systemowych, etc. A jako że nie da się przewidzieć z czego dany program korzysta, to trzeba by było emulować wszystko w temacie systemu. Owszem, odeszła by konieczność pisania niejako "najniższej" warstwy - w tym przypadku obsługa sprzętu, ale doszła by konieczność translacji systemowych bebechów linuksa, na amigowe odpowiedniki. Z mojej perspektywy, w optymistycznym założeniu, patrząc na to jak skonstruowane jest linuksowe API - ilość pracy była by conajmniej równoważna... Nie wierzysz że to było by proste? To zobacz ile trwała implementacja funkcjonalności "wrappera" gtk -> MUI. I to niepełnej. I to nie dlatego że MUI jest prostsze jako toolkit od gtk - ma tylko mniej gotowych klas, a to nie to samo.

Druga sprawa, odnośnie "zhackowanej" wersji Picasso96 - to nie jest to nic "shackowanego" jak to określiłeś. Jest to po prostu specjalny sterownik dla zwykłego Picasso96, który wykorzystuje API windowsa poprzez wywołania emulatora. Żadnych bezpośrednich hacków, uwierz.

Trzecia sprawa, odnośnie braku "binarnej kompatybilności" AROSa. Wybacz, ale w ten sposób odkrywasz brak logicznego myślenia. Binarna kompatybilność do niczego nie jest potrzebna, biblioteki AROSa można skompilować na dowolnej architekturze. Od strony API są kompatybilne w 99% z amigowym API (czyli jest rygorystyczne i nie kopiuje tylko amigowego Look'n'feel, wbrew temu co piszesz), co można potwierdzić robiąc "port" dowolnego programu amigowskiego pod AROSa (wiem o czym mówię, bo zdarzyło mi się popełnić kilka portów w obie strony). Wgląd w te biblioteki na pewno pomógłby szalonemu linuksowemu developerowi, który by chciał stworzyć takie "amigaoswine". Ot chociażby by zobaczyć jak to wygląda "od środka".

Czwarta sprawa, odnośnie uaktualnienia systemowego interfejsu. Który to kościsty linuksowy systemowy interfejs stawiasz na przeciwko takiemu MUI, zwłaszcza w wersji 4? (Jeśli już idziemy na całość, i znajdujemy się w dziale MorphOS).

Piąta sprawa, odnośnie blittera, coppera, etc. ABox nie obsługuje tych sprzętowych komponentów niejako z "rozpędu", ze względu na to że nie emuluje starych kości graficznych, bo generalnie rzecz biorąc nie jest emulatorem. To tak w skrócie.
Inna sprawa, to to, że nie wystarczy "zaemulować" blittera czy coppera w sensie jego funkcjonalności. Trzeba by również zmapować te twory w przestrzeni adresowej takiego Pegaza, tak by amigowe super demo znalazło pod danym adresem sprzętowym blittera i coppera, do którego się odwołuje, a nie czarną dziurę z przestrzeni adresowej pegaza. Oczywiście można spokojnie założyć że takie dema rzeźbiące po hardware w większości przypadków działają na m68k, i dać sobie siana z odwołaniami natywnymi, i całość zrealizować na warstwie emulacji procesora m68k, ale... PO CO?...

Szósta sprawa, odnośnie tego czym jest blitter. Podejrzewam że nie wiesz, skoro piszesz o nim w kontekście "OpenGL pixel shader". Otóż spieszę donieść że to jest prosty układ, tylko do szybkiego (jak na swoje czasy) wypełniania niewielkich obszarów pamięci, kopiowania zawartości pamięci z jednego miejsca w drugie, i kreślenia linii. Tak. Naprawdę.

Siódma sprawa, odnośnie braku zainteresowania ogólnej społeczności developerskiej projektami systemów amigowych. Otóż śpieszę donieść że to są systemy niszowe. NISZOWE. Słabo ogólnie znane, postrzegane przez pryzmat starych amig, czyli czegoś totalnie przestarzałego, służącego do obsługiwania gier zapisanych na dyskietkach. O braku marketingu, pieniędzy na rozwój, czy jakąś rewolucję na miarę przejścia z MacOS9 na MacOS10 (taka wolna dygresja odnośnie oderwania się od starego amigowego API bez ochrony pamięci), etc nie wspomnę.

Ósma sprawa - niby dlaczego w ogóle dział "MorphOS?

Wybrałem dział MorphOS ze względu na Abox który jest właśnie komercyjnym odpowiednikiem tego o czym myślę

Mapowanie pamięci i ochrona pamięci - nie widzę innej możliwości jak statyczne zadeklarowanie dla każdego programu klasycznego jaki blok pamięci ma być dla niego zarezerwowany i przekazanie programowi informacji że to jest cała dostępna dla niego pamięć i w obrębie tego bloku wielkości 2 - 64 MB odpowiednie mapowanie blittera. W ten sposób jest dostęp do klasycznych kości implementowanych natywnie i jest ochrona pamięci przy uruchomieniu klasycznego programu amigowskiego w środowisku Linux.

Jeżeli chodzi o interfejs graficzny proponuję zaimplementowanie plugina dla Compiz tak aby podmienić oryginalny window decorator na taki który rysuje amigowe belki na okienkach, zmienia wygląd file managera na amogowo wyglądający etc.

Mówiąc o czymś niszowym zapominasz że tylko 3% użytkowników komputera mają zainstalowany Linux co sprawia że jest to system niszowy, który nie ma wielkiego budżetu reklamowego a mimo to prężnie się rozwija bo developerzy wiedzą że ich wysiłek nie pójdzie na marne jak firma która stworzyła dla nich API podniesie cenę swoich produktów, zbankrutuje, zaprzestanie dotychczasowej działalności, zmieni się zarząd itd. i nagle się okaże że dlatego że nie mają praw autorskich do komercyjnej części systemu dla którego pisali swoje programy to mogą je zacząć pisać od nowa na inną platformę.

tylko ze niszowosc linuxa ma sie nijak do niszowosci amigaos-u. to nawet nie jest 0.01% uzytkownikow komputerow.

Poza tym tych struktór, funkcji, eventów etc. na przwdę nie jest aż tak dużo - w końcu ile może się zmieścić do 256 KB ROM i kilkunastu bibliotek skoro duża część z tego to obsługa systemów plików, sprzętu (scsi.device, parallel.device, serial.device) które mając już Linuksowe API pod sobą byłoby bardzo proste do zaimplementowania poprzez odpowiednie wykożystanie Linuksowego API. Poza tym większość katalogu C można zaimplementować wykożystując analogiczne polecenia dla Unix'a a LoadWB, addbuffers etc. mogą pozostać jako stub bo wcale nie są potrzebne.

Oczywiście że masz rację, świadomie przesadziłem, ale chciałem zwrócić uwagę, że jeśli założysz sensowny projekt na SourceForge to zainteresowanie i developerzy się znajdą.

oczywiście "struktur" - źle napisałem

no to zobacz jakie jest zainteresowanie Golemem na ten przyklad.... Jest na sf. (Golem - pierwszy z brzegu ciekawy projekt jaki mi sie przypomnial).

amigowi deweloperzy lub deweloperzy znajacy amigaos? nie, nie znajda sie. ci ktorzy sa w stanie cos w tym kierunku zrobic sa zajeci przy innych projektach.

I oczywiście nie trzeba emulować WSZYSTKIEGO bo typowa gra wykożystuje co najwyżej 1% amigowskiego API a mało który program wykożystuje więcej niż 30% API - sami widzicie że Abox nie obsługuje wszystkiego a działa całkiem dobrze, to samo dotyczy Wine - na początek nie trzeba obsługiwać wszystkiego i już znajdzie się wiele programów którym to wystarczy do poprawnej pracy.

abox emuluje praktycznie calosc (nie wiem czy 100%, ale bardzo blisko) api (w tym zachowania nieudokumentowane ktore takze musisz emulowac) amigaos-u.

a do gier masz uae.



Ostatnia modyfikacja: 29.06.07 10:24

W mojej opini gdyby projekt był sensowny to by się znaleźli - w końcy WinUAE jest z powodzeniem rozwijany do dzisiaj. Tym bardziej, że dużo z tego co jest potrzebne już kiedys zostało zrobione i jest to open-source.

tu nie chodzi o opinie ale o realia. nie ma programistow amigowych. a uae emuluje sprzet a nie api, wiec autor nie musi miec pojecia o amigaosie.

keiro - co masz do Dominik 'smith' Kowalski ?

Ten gości na przwdę dał popis w pozytywnym tego słowa znaczeniu komentując dyskusję o Efice na IRCu

nic. po prostu bawia mnie niektore jego teksty.

Wracając do dyskusji skoro klasyczne API jest niezmienne od 10+ lat i juz takie pozostanie to można to zrobić raz a dobrze na lata nawet jak niewielu developerów będzie się wokół tego kręcić.

to znajdz tych niewielu deweloperow i moze za 5 (moze 3 przy pracy przynajmniej 8 godzin dziennie) lat bedziecie mieli gotowe rozwiazanie. powodzenia

Bo widzisz Dominik 'smith' Kowalski ma wiele racji tale że jego techniczne argumenty nie były zrozumiane gdy komentował wiadomość o spotkaniu z specami od marketingu Efiki. Uważam, że warstwa systemu obsługująca sprzęt nie powinna mieć nic wspólnego z oryginalną amigowską implemenatcją (maże to byc np. Linux) a dopiero na tej solidnej podstawie budujemy amigowski front-end zamiast budować kolosa nagliniannych nogach który tak naprawdę jest w pełni kompatybilny tylko z samym sobą jak np. AROS.

Linux i solidna podstawa ... lol lol

Dobra, masz rację, że w 2007 roku byłoby to trudne ale gdyby cała praca jaka poszła na AROS poszłaby w tym kierunku to mielibyśmy "Amiga-is-not-an-emulator" w wersji 0.9 a nie AROS w wersji 0.3.3 którego większość ludzi uruchamia pod windowsem, linuksem lub na maszynie wirtualnej.

ale co ma do tego jego cytat z mojej sygnatury? smith to zdolny programista czego nie neguje, tylko czasami pisze rozne smieszne teksty. tyle w tej sprawie.

skad taka pewnosc? aros wlasnie reimplementuje api i zobacz w jakim tempie im to idzie. mozna w sumie powiedziec ze robia to co napisales.

Wiekszosc, czyli kilku deweloperow i z 5-10 uzytkownikow niedzielnych? Nie mam nic przeciwko Arosowi, tylko, ze jak widac, projekt bez wsparcia finansowego bedzie sie rozwijal w takim wlasnie tempie...

Ale borykają się, ze sterownikami nvidii, nie mają sprzętowego wsparcia grafiki 2D, niepotrzebnie przepisują rzeczy takie jak HDtoolbox, Disk Master, przekompilowują ScummVm i SDL po to żeby stworzyć w miarę kompletny system, nie mogą po prostu tłumaczyć API - muszą go pisać od nowa np. interfejs okienkowy, rysować ikonki itd. - zamiast tego wszystkiego wystarczyłoby jedynie skupić się na odpowiedniku czegoś takiego jak mono dla .net, wine, opensourcowa wirtualna maszyna java, czy opensourcowy flash dla Linuxa

java, .net ect tez rysuja okienka....

jest akcelerowany sterownik grafiki. diskmastera nikt nie przepisuje, a jedynie rekompiluje dla innego procesora. interfejs okienkowy i tak musisz napisac bo programy go oczekuja. na interfejs okienkowy sklada sie wiele elementow. layers, intuition, graphics (to tylko czesc wizualna), ktore i tak musisz przepisac bo wymagaja tego programy (jest to czesc api). przepisuja to w inny sposob, ale wykonuja ta sama prace.

poza tym nie widzisz roznicy pomiedzy .net/java a api amigaos-u gdzie wszystkie struktury systemowe sa otwarte dla programisty. nie ma zadnej warstwy abstracji. musisz zachowac kompatybilnosc nie tylko na poziomie api, ale i na poziomie wewnetrznych struktur systemowych do ktorych aplikacje maja dowolny dostep.

proponuje w ramach eksperymentu skompilowac banalny program (moze byc hello world) i proof-of-concept rozwiazania o ktorym piszesz. powodzenia. odezwij sie jak to zrobisz/zrobicie.

Ale uruchamiając applet javy na linuxie w open-sourcowej maszynie javy kozystam z interfejsu gnome więc program wygląda tak jak natywny program napisany dla gtk.

Poza tym muszę kolejny raz przyznać kiero rację - rzeczwiście, w sytuacji jak duża część klasycznego systemu AmigaOS jest "od siekiery" przez co programy mają bezpośredni dostęp do adresów mapowanych na ROM przez co źle napisane programy nawet nie kwapiły się odszukiwać adresu funkcji ROM w tablicy skoków - ale nawet jeżeli węźniemy tylko te dobrze napisane programy to i tak musielibyśmy zastosować wiele tzw. mean hacks żeby cokolwiek uruchomić - w takiej sytuacji chyba najlepiej jest od nowa napisać najlepsze programy amigowskie jako open-source jak to miało miejsce w przypadku:

dopus -> worker
protracker -> sound tracker

(open-sourcowa Colonizaition tak jak inne tego typu gry niestety tradycyjnie końcą swój rozwój na etapie aplha)

Odpowiedź napisałem w poprzednim poście.

Poza tym jaki by to miało sens reimplementować Arexx który jest adaptacją standardu IBM REXX z lat osiemdziesiątych, który poza Amigą nigdzie indziej się nie przyjął a jego sukces na Amidze polegał na tym że był to jedyny dostępny standard - to taki archaiczny VB script.

Natomiast amigowski shell to jakiś uproszczony BASH, czy może Burne shell zaczepnięty z ówczesnych unixów, na których developerzy klasycznej Amigi stworzyli emulator pod którym pisali system w czasie jak sprzęt był dopiero w fazie produkcji (były to stacje graficzne SGI warte 50 milionów dolarów - to jest więcej niż łączny dochód wszystkich amigowskich firm razem wziętych po spaleniu się fabryki Commodore).