Komentowana treść: AROS - ciag dalszy ata.device
11.07.2004 22:07
[#3]
Re: AROS - ciag dalszy ata.device
W odpowiedzi na komentarz #2
A czy planuje sie zrobienie takiego emulatora 68k jak w MorphOSie? Poprostu zeby zwykly uzytkownik nawet nie wiedzial, ze odpala cos pod emulacja. Dwuklik na dowolnym programie pod 68k, WOS, PUP, MOS i dziala tak jak kazdy program pisany specjalnie dla AROSa. :)
A czy planuje sie zrobienie takiego emulatora 68k jak w MorphOSie? Poprostu zeby zwykly uzytkownik nawet nie wiedzial, ze odpala cos pod emulacja. Dwuklik na dowolnym programie pod 68k, WOS, PUP, MOS i dziala tak jak kazdy program pisany specjalnie dla AROSa. :)
11.07.2004 22:13
[#4]
Re: AROS - ciag dalszy ata.device
W odpowiedzi na komentarz #2
W przeszlosci MOSowcy korzystali juz z uprzejmosci (i zrodel) AROSowcow. A moze daloby sie tez podzielic tym stosem TCP/IP, co? :) Wy tak ladnie to piszecie, ze moze daloby sie przeniesc. Jezeli nie to mnie popraw bom zielony w tym temacie. W AmiTCP pod MOSa juz nikt nie wierzy. To co, ze ktos go tam juz dawno uzywa... MOSa 1.5 tez ktos uzywa a nie ma sie go co spodziewac przed rokiem 2044. :(
W przeszlosci MOSowcy korzystali juz z uprzejmosci (i zrodel) AROSowcow. A moze daloby sie tez podzielic tym stosem TCP/IP, co? :) Wy tak ladnie to piszecie, ze moze daloby sie przeniesc. Jezeli nie to mnie popraw bom zielony w tym temacie. W AmiTCP pod MOSa juz nikt nie wierzy. To co, ze ktos go tam juz dawno uzywa... MOSa 1.5 tez ktos uzywa a nie ma sie go co spodziewac przed rokiem 2044. :(
11.07.2004 23:43
[#7]
Re: AROS - ciag dalszy ata.device
Pedzej skonczy sie "Moda na sukces" niz pojawi sie MOS 1.5 :D :D :D
12.07.2004 11:34
[#8]
Re: AROS - ciag dalszy ata.device
"Spodobal" mi sie w opisie tekst, ze teraz device obsluguje dyski o pojemnosci do 2^57 (chyba) :) W zasadzie moznaby jeszcze calosc tekstu zakodowac i w hexie zapisac 
)
P.S.
Cos mi sie wydaje, ze w j.angielskim tlumaczy sie "on obsluguje..." na "it can handle", nie "he..." :) Forma "she" jest co najwyzej uzywana, ale tylko wtedy, jesli mowi sie pieszczotliwie o maszynach (np. o Amidze, co akurat by sie zgadzalo, bo to nawet rodzaj zenski)
)P.S.
Cos mi sie wydaje, ze w j.angielskim tlumaczy sie "on obsluguje..." na "it can handle", nie "he..." :) Forma "she" jest co najwyzej uzywana, ale tylko wtedy, jesli mowi sie pieszczotliwie o maszynach (np. o Amidze, co akurat by sie zgadzalo, bo to nawet rodzaj zenski)
12.07.2004 11:44
[#9]
Re: AROS - ciag dalszy ata.device
W odpowiedzi na komentarz #8
Co do 2^57 nie mialem juz wczoraj sily zastanawiac sie, czy to petabajty czy inne stworki :)
A co do angielskiego? Coz, z czasem degraduje sie on u mnie, jako ze urzedowym jezykiem dookola jest teraz niemiecki. Angielskim posluguje sie doslownie od swieta. Szkoda.
Co do 2^57 nie mialem juz wczoraj sily zastanawiac sie, czy to petabajty czy inne stworki :)
A co do angielskiego? Coz, z czasem degraduje sie on u mnie, jako ze urzedowym jezykiem dookola jest teraz niemiecki. Angielskim posluguje sie doslownie od swieta. Szkoda.
14.07.2004 18:38
[#12]
Re: AROS - ciag dalszy ata.device
@rzookol, post #10
W odpowiedzi na komentarz #10
Jesli AROS pracuje na procesorze w BigEndian, problemu nie ma, i emulacje m68k dalo by sie zrobic. Niestety, wiekszosc osob pracuje nad wersja x86, ktora chcac nie chcac pracuje w LittleEndian.
Problemem jest uruchomienie emulatora korzystajacego z tego samego systemu. Problemem jest tez integracja emulatora bazujacego na UAE z calym systemem. Program moze sie odwolac na przyklad do struct RastPort, w ktorej dane beda w LittleEndian, a stary program sie tego nie spodziewa. Co wtedy? Wypadek przy pracy ;)
Kiedys widzialem propozycje, zeby kod i dane dla m68k trzymac w osobnym obszarze pamieci, w ktorym podmienialo by sie automatycznie (przez wyjadek "Page Fault") dane tak, aby emulowany m68k widzial system jako calosc w Big Endianie. Niestety, taka sztuczka nie zadzialalaby chociazby przy kopiowaniu stringa grupkami po 4 bajty :)
Problemow jest sporo a nawet jeszcze wiecej. Ludzie piszacy programy pod PalmOS5 znaja bolaczke wspolistnienia BigEndianowego m68k (emulowanego na ARM'ie) i LittleEndianowym ARM'em.
Jesli AROS pracuje na procesorze w BigEndian, problemu nie ma, i emulacje m68k dalo by sie zrobic. Niestety, wiekszosc osob pracuje nad wersja x86, ktora chcac nie chcac pracuje w LittleEndian.
Problemem jest uruchomienie emulatora korzystajacego z tego samego systemu. Problemem jest tez integracja emulatora bazujacego na UAE z calym systemem. Program moze sie odwolac na przyklad do struct RastPort, w ktorej dane beda w LittleEndian, a stary program sie tego nie spodziewa. Co wtedy? Wypadek przy pracy ;)
Kiedys widzialem propozycje, zeby kod i dane dla m68k trzymac w osobnym obszarze pamieci, w ktorym podmienialo by sie automatycznie (przez wyjadek "Page Fault") dane tak, aby emulowany m68k widzial system jako calosc w Big Endianie. Niestety, taka sztuczka nie zadzialalaby chociazby przy kopiowaniu stringa grupkami po 4 bajty :)
Problemow jest sporo a nawet jeszcze wiecej. Ludzie piszacy programy pod PalmOS5 znaja bolaczke wspolistnienia BigEndianowego m68k (emulowanego na ARM'ie) i LittleEndianowym ARM'em.
14.07.2004 19:02
[#13]
Re: AROS - ciag dalszy ata.device
@Michal Schulz, post #12
W odpowiedzi na komentarz #12
Problemow jest sporo a nawet jeszcze wiecej. Ludzie piszacy programy pod PalmOS5 znaja bolaczke wspolistnienia BigEndianowego m68k (emulowanego na ARM'ie) i LittleEndianowym ARM'em.
Ale Oni sobie jakoś radzą?
Może by ich podpatrzeć tu, i tam? ;)
Problemow jest sporo a nawet jeszcze wiecej. Ludzie piszacy programy pod PalmOS5 znaja bolaczke wspolistnienia BigEndianowego m68k (emulowanego na ARM'ie) i LittleEndianowym ARM'em.
Ale Oni sobie jakoś radzą?
Może by ich podpatrzeć tu, i tam? ;)
14.07.2004 19:25
[#14]
Re: AROS - ciag dalszy ata.device
@MinisterQ, post #13
W odpowiedzi na komentarz #13
Oczywiscie ze sobie radza. Kod dla ARM'a swiadomie trzyma pewna czesc danych w BigEndian i dodatkowo do wszystkiego masz dostep przez handle, z ktorego dopiero po poproszeniu systemu, dostajesz wskaznik.
Wyobrazasz sobie taka zabawe w programach dla AmigaOS/AROS'a? W praktyce oznaczalo by to przepisanie wszystkiego od zera, bo glupie OpenLibrary wymagalo by potem karkolomnych LockHandle i FreeHandle czy jakkolwiek to zwac.
Oczywiscie ze sobie radza. Kod dla ARM'a swiadomie trzyma pewna czesc danych w BigEndian i dodatkowo do wszystkiego masz dostep przez handle, z ktorego dopiero po poproszeniu systemu, dostajesz wskaznik.
Wyobrazasz sobie taka zabawe w programach dla AmigaOS/AROS'a? W praktyce oznaczalo by to przepisanie wszystkiego od zera, bo glupie OpenLibrary wymagalo by potem karkolomnych LockHandle i FreeHandle czy jakkolwiek to zwac.
15.07.2004 00:01
[#15]
Re: AROS - ciag dalszy ata.device
Jestem w temacie programowania calkiem zielony ale ... amithlon jakoś sobie radzi z konwersjami endianów.
Pozatym już wielokrotnie pisałem, że jedyne co ogranicza programistów to ich własne przeświadczenie tym ograniczeniu.
Czy nie można by było zrobić tak żeby emulator automatycznie przemieniał te endiany ? Przecież zawsze wiadomo które procesy są natywne a które emulowane i dzięki temu system/emulator może mieć kontrole nad tym kiedy ma być zastosowana konwersja endianów.
Pozatym już wielokrotnie pisałem, że jedyne co ogranicza programistów to ich własne przeświadczenie tym ograniczeniu.
Czy nie można by było zrobić tak żeby emulator automatycznie przemieniał te endiany ? Przecież zawsze wiadomo które procesy są natywne a które emulowane i dzięki temu system/emulator może mieć kontrole nad tym kiedy ma być zastosowana konwersja endianów.
15.07.2004 08:05
[#16]
Re: AROS - ciag dalszy ata.device
@Albert Jasinski, post #15
W odpowiedzi na komentarz #15
Amithlon radzi sobie z endianami, bo amithlon to emulator, on przede wszystkim emuluje, wiec tam nie ma tego problemu... Za to by napisac program wykorzystujacy moc maszyny trzeba sie nakombinowac podobnie jak dla kart powerup pod klasycznym AOSem...
Amithlon radzi sobie z endianami, bo amithlon to emulator, on przede wszystkim emuluje, wiec tam nie ma tego problemu... Za to by napisac program wykorzystujacy moc maszyny trzeba sie nakombinowac podobnie jak dla kart powerup pod klasycznym AOSem...
15.07.2004 11:30
[#17]
Re: AROS - ciag dalszy ata.device
@Albert Jasinski, post #15
W odpowiedzi na komentarz #15
Amithlon to emulator, AROS to system operacyjny - to lekka roznica, nieprawdaz? Pod AROSem UAE tez sobie jakos radzi, co nie znaczy ze da sie w system bezbolesnie wbudowac emulator m68k. Pisanie wstawek w x86 dla amithlona to karkolomna zabawa (ulatwiona wprawdzie specjalnym gcc, ale dalej karkolomna).
Emulator nie moze automatycznie podmieniac endianow. Popatrz - czytasz powiedzmy ULONG rowny niech bedzie 0x11223344. Pod intelem beda to kolejno bajty 0x44 0x33 0x22 0x11, pod m68k 0x11 0x22 0x33 0x44. Powiedzmy, ze emulator przekowertuje dane w locie. Wszystko jak na razie pieknie. A co, jesli program pod m68k bedzie kopiowal stringa nie bajt po bajcie, tylko dlugie slowo za dlugim slowem, coby bylo szybciej (tak dziala np. CopyMem)? Z prostego stringa "Dupa\0" zrobi sie nagle 'a' 'p' 'u' 'D' x x x '\0', gdzie x to jakies smieci ktore byly dalej w pamieci. Co z takim czyms zrobisz.
Na koniec zagadka. Procesory PPC mozna za pomoca jednej flagi przelaczyc w tryb LittleEndian. Zastanow sie, dlaczego przelaczyc, a nie na przyklad zrobic tak, zeby pracowal w BigEndian i LittleEndian jednoczesnie (a bit wepchnac do MMU, tak coby odpowiednie strony dalo sie zaznaczyc jako LE)? Czyzby tworcy PPC tez byli przeswiadczeni o swoich ograniczeniach?
Amithlon to emulator, AROS to system operacyjny - to lekka roznica, nieprawdaz? Pod AROSem UAE tez sobie jakos radzi, co nie znaczy ze da sie w system bezbolesnie wbudowac emulator m68k. Pisanie wstawek w x86 dla amithlona to karkolomna zabawa (ulatwiona wprawdzie specjalnym gcc, ale dalej karkolomna).
Emulator nie moze automatycznie podmieniac endianow. Popatrz - czytasz powiedzmy ULONG rowny niech bedzie 0x11223344. Pod intelem beda to kolejno bajty 0x44 0x33 0x22 0x11, pod m68k 0x11 0x22 0x33 0x44. Powiedzmy, ze emulator przekowertuje dane w locie. Wszystko jak na razie pieknie. A co, jesli program pod m68k bedzie kopiowal stringa nie bajt po bajcie, tylko dlugie slowo za dlugim slowem, coby bylo szybciej (tak dziala np. CopyMem)? Z prostego stringa "Dupa\0" zrobi sie nagle 'a' 'p' 'u' 'D' x x x '\0', gdzie x to jakies smieci ktore byly dalej w pamieci. Co z takim czyms zrobisz.
Na koniec zagadka. Procesory PPC mozna za pomoca jednej flagi przelaczyc w tryb LittleEndian. Zastanow sie, dlaczego przelaczyc, a nie na przyklad zrobic tak, zeby pracowal w BigEndian i LittleEndian jednoczesnie (a bit wepchnac do MMU, tak coby odpowiednie strony dalo sie zaznaczyc jako LE)? Czyzby tworcy PPC tez byli przeswiadczeni o swoich ograniczeniach?
15.07.2004 12:02
[#18]
Re: AROS - ciag dalszy ata.device
Oczywiście.
Cały rozwój ludzkości ograniczony jest przez możliwości pojmowania ludzi.
Gdyby wyeliminować słowa "nie da się" pozostało by tylko jedno realne ograniczenie - czas.
No ale pozostawmy sprawę wbudowanego emulatora 68k .... bo skoro programiści twierdzą że się nie da to pewnie przerasta to ich możliwości (to jest właściwe stwierdzenie).
Powróćmy do sprawy UAE w Arosie.
Dlaczego tak ważny element jak emulacja starego oprogramowania jest tak olewany ? Przecież aros bez UAE to nie ma za bardzo czym przyciągnąć użytkownika.
Już dawno wysówałem pomysły co do WinUAE które zamiast kounikować się z userempoprzez ekran emulowany. robiło by to używając ekranu windowsa.
Innymi słowy ikonki wczytane w UAE pojawiły by się na pulpice windy a każde okienko otwierane przez emulator było by otwierane w osobnym okienku na ekranie windowsa. W przypadku ekranów innych od WB , ekrany te otwierały by się jako dodatkowe okna albo jako sobne ekranby pod windą.
Można by też zrobić uae działające jako tło pulpitu.
To samo można by zastosować w arosie. Bo powiedzmy sobie szczerze ... żaden choćby nie wiem jak dobry potomek AmigaOS nie ma szans na przetrwanie bez możliwości odpalania softu klasycznego.
Jak narazie amithlon pomimo że jest już oficjalnie nierozwijany, to nadal trzyma resztę daleko w tyle. I w zasadzie
Cały rozwój ludzkości ograniczony jest przez możliwości pojmowania ludzi.
Gdyby wyeliminować słowa "nie da się" pozostało by tylko jedno realne ograniczenie - czas.
No ale pozostawmy sprawę wbudowanego emulatora 68k .... bo skoro programiści twierdzą że się nie da to pewnie przerasta to ich możliwości (to jest właściwe stwierdzenie).
Powróćmy do sprawy UAE w Arosie.
Dlaczego tak ważny element jak emulacja starego oprogramowania jest tak olewany ? Przecież aros bez UAE to nie ma za bardzo czym przyciągnąć użytkownika.
Już dawno wysówałem pomysły co do WinUAE które zamiast kounikować się z userempoprzez ekran emulowany. robiło by to używając ekranu windowsa.
Innymi słowy ikonki wczytane w UAE pojawiły by się na pulpice windy a każde okienko otwierane przez emulator było by otwierane w osobnym okienku na ekranie windowsa. W przypadku ekranów innych od WB , ekrany te otwierały by się jako dodatkowe okna albo jako sobne ekranby pod windą.
Można by też zrobić uae działające jako tło pulpitu.
To samo można by zastosować w arosie. Bo powiedzmy sobie szczerze ... żaden choćby nie wiem jak dobry potomek AmigaOS nie ma szans na przetrwanie bez możliwości odpalania softu klasycznego.
Jak narazie amithlon pomimo że jest już oficjalnie nierozwijany, to nadal trzyma resztę daleko w tyle. I w zasadzie
15.07.2004 12:10
[#19]
Re: AROS - ciag dalszy ata.device
@Albert Jasinski, post #18
W odpowiedzi na komentarz #18
To o czym piszesz jest teoretycznie mozliwe (uae na windowsie), ale bylby maly, a w zasadzie wielki problem, brak komunikacji miedzy tak odpalonymi programami... teoretycznie mozna by pomyslec jak ten problem obejsc, ale wtedy efektywnosc dzialania bedzie zadna... (pomijam juz fakt emulacji calego srodowiska w kazdym oknie z osobna)
To o czym piszesz jest teoretycznie mozliwe (uae na windowsie), ale bylby maly, a w zasadzie wielki problem, brak komunikacji miedzy tak odpalonymi programami... teoretycznie mozna by pomyslec jak ten problem obejsc, ale wtedy efektywnosc dzialania bedzie zadna... (pomijam juz fakt emulacji calego srodowiska w kazdym oknie z osobna)
15.07.2004 12:21
[#20]
Re: AROS - ciag dalszy ata.device
@Albert Jasinski, post #18
W odpowiedzi na komentarz #18
Jak juz wczesniej zaznaczyles, kompletnie sie na tym nie znasz. Ale popatrzmy.
napisales - "No ale pozostawmy sprawę wbudowanego emulatora 68k .... bo skoro programiści twierdzą że się nie da to pewnie przerasta to ich możliwości (to jest właściwe stwierdzenie)."
W takim razie powiem Ci, ze podobny problem przerasta mozliwosci nawet programistow microsoftu, ktorych windows NT w wersji na PPC wymuszal na procesorze prace w LittleEndian, mimo ze tak dzialajacy PPC jest zdziebko wolniejszy. Nie jestesmy pierwsi i nie bedziemy ostatni :)
Co do UAE zintegrowanego z pulpitem: byc moze kiedys takie cos powstanie, ale wymaga to takze calkiem sporego nakladu ze strony samego systemu i procesora. Jesli okno emulowanego w UAE programu mialoby sie otwierac na powedzmy arosowym workbenchu, musialbys stale sledzic wszystko co na tym ekranie tez jest otworzone i odzwierciedlac wszystkie struktury w BigEndianie, odpowiednio juz przetworzone.
Co do olewania emulacji. Widzisz. Pegasos czy AmigaOne maja maly problem, bo emulacja jest duzo latwiejsza do wykonania. W przypadku arosa dzialajacego na Bigendianie tez byloby duuuuuuzo latwiej. Niestety, aros dziala przede wszystkim na x86, i albo aros z systemu ktorym jest, stalby sie kolejnym emulatorem takim jak amithlon, i gawiedz cieszyla by sie starymi programami a programisci kleliby probujac pisac programy na x86, albo aros pozostanie systemem, w ktorym mozesz sobie uzyc starych programow pod UAE.
Z punktu widzenia starych amigowcow byc moze pierwsze (cos a'la amithlon) rozwiazanie byloby lepsze, ale dla nas jest nieoplacalne. My tworzymy system, a nie emulator. Jesli brak Ci starych programow, to albo uzyj UAE, albo zaniteresuj sie mocno amithlonem, bo dla takich wlasnie osob zostal on pomyslany.
A na koniec: "Jak narazie amithlon pomimo że jest już oficjalnie nierozwijany, to nadal trzyma resztę daleko w tyle."
Albert, z calym szacunkiem, ale odrozniaj prosze Cie emulator od systemu operacyjnego.
Hint: "Kurde, ten caly Gimp jest o niebo lepszy od windowsa XP..." brzmi rownie bluznierczo co twoje stwierdzenie ;)
Jak juz wczesniej zaznaczyles, kompletnie sie na tym nie znasz. Ale popatrzmy.
napisales - "No ale pozostawmy sprawę wbudowanego emulatora 68k .... bo skoro programiści twierdzą że się nie da to pewnie przerasta to ich możliwości (to jest właściwe stwierdzenie)."
W takim razie powiem Ci, ze podobny problem przerasta mozliwosci nawet programistow microsoftu, ktorych windows NT w wersji na PPC wymuszal na procesorze prace w LittleEndian, mimo ze tak dzialajacy PPC jest zdziebko wolniejszy. Nie jestesmy pierwsi i nie bedziemy ostatni :)
Co do UAE zintegrowanego z pulpitem: byc moze kiedys takie cos powstanie, ale wymaga to takze calkiem sporego nakladu ze strony samego systemu i procesora. Jesli okno emulowanego w UAE programu mialoby sie otwierac na powedzmy arosowym workbenchu, musialbys stale sledzic wszystko co na tym ekranie tez jest otworzone i odzwierciedlac wszystkie struktury w BigEndianie, odpowiednio juz przetworzone.
Co do olewania emulacji. Widzisz. Pegasos czy AmigaOne maja maly problem, bo emulacja jest duzo latwiejsza do wykonania. W przypadku arosa dzialajacego na Bigendianie tez byloby duuuuuuzo latwiej. Niestety, aros dziala przede wszystkim na x86, i albo aros z systemu ktorym jest, stalby sie kolejnym emulatorem takim jak amithlon, i gawiedz cieszyla by sie starymi programami a programisci kleliby probujac pisac programy na x86, albo aros pozostanie systemem, w ktorym mozesz sobie uzyc starych programow pod UAE.
Z punktu widzenia starych amigowcow byc moze pierwsze (cos a'la amithlon) rozwiazanie byloby lepsze, ale dla nas jest nieoplacalne. My tworzymy system, a nie emulator. Jesli brak Ci starych programow, to albo uzyj UAE, albo zaniteresuj sie mocno amithlonem, bo dla takich wlasnie osob zostal on pomyslany.
A na koniec: "Jak narazie amithlon pomimo że jest już oficjalnie nierozwijany, to nadal trzyma resztę daleko w tyle."
Albert, z calym szacunkiem, ale odrozniaj prosze Cie emulator od systemu operacyjnego.
Hint: "Kurde, ten caly Gimp jest o niebo lepszy od windowsa XP..." brzmi rownie bluznierczo co twoje stwierdzenie ;)
15.07.2004 13:55
[#21]
Re: AROS - ciag dalszy ata.device
To może inaczej - napisać konwenter binarek m68k -> x86? ;);)
15.07.2004 19:01
[#22]
Re: AROS - ciag dalszy ata.device
16.07.2004 14:43
[#23]
Re: AROS - ciag dalszy ata.device
"Albert, z calym szacunkiem, ale odrozniaj prosze Cie emulator od systemu operacyjnego."
Pamiętasz film "Szczęki" ? Tam szef policji (Roy Scheider) powedział tak: tylko z morza widać że wyspa to wyspa.
Tutaj tak samo ... uzywajac amithlona nie wiesz czy to emulacja czy prawdziwa amiga .... więc jaka różnica .. chyba tylko taka że amithlon jest szybszy i dużo tańszy.
Pamiętasz film "Szczęki" ? Tam szef policji (Roy Scheider) powedział tak: tylko z morza widać że wyspa to wyspa.
Tutaj tak samo ... uzywajac amithlona nie wiesz czy to emulacja czy prawdziwa amiga .... więc jaka różnica .. chyba tylko taka że amithlon jest szybszy i dużo tańszy.
17.07.2004 18:41
[#25]
Re: AROS - ciag dalszy ata.device
Ale skoro różnica dla przeciętnego użytkownika jest to mało widoczna, to czy nie lepiej zająć się oprogramowaniem klasycznym (z myślą o amithlonie)? Zamiast tworzyć kolejne systemy tylko dla przyjemności ich tworzenia , programiści powinni napoisać więcej pożądnych sterowników do sprzętu dla amithlona, a także soft który na 68k byłby nieporozumieniem a na amithlonowym 68k będzie śmigał.
I wcale nie trzeba tu używać amithlonowego GCC (przynajmniej do tego ostatniego celu) ....
I wcale nie trzeba tu używać amithlonowego GCC (przynajmniej do tego ostatniego celu) ....
17.07.2004 20:27
[#26]
Re: AROS - ciag dalszy ata.device
@Albert Jasinski, post #25
W odpowiedzi na komentarz #25
Hmmm ale system trzeba tu i owdzie poprawic, wprowadzic nowe rzeczy...
Cóż nie czarujmy sie 12 lat od jakiegos duzego updatu systemu
minelo... I w sumie system zdaloby sie w wielu miejscach przepisach co
robia Aros-Team, Mos-team i OS4-team... Kazdy na swoj sposob :)
Hmmm ale system trzeba tu i owdzie poprawic, wprowadzic nowe rzeczy...
Cóż nie czarujmy sie 12 lat od jakiegos duzego updatu systemu
minelo... I w sumie system zdaloby sie w wielu miejscach przepisach co
robia Aros-Team, Mos-team i OS4-team... Kazdy na swoj sposob :)
18.07.2004 19:39
[#27]
Re: AROS - ciag dalszy ata.device
No i ok .... można poprawiać też wersję 68k.
I wcale nie jest to takie nierealne.
OS4 w wersji 68k działa bardzo ładnie na Amithlonie, a podobno także na UAE (tego nie udało mi się sprawdzić).
Niestety na nowego kernela dla 68k nie ma co liczyć, inne elementy systemu przestają ukazywać się w wersjach 68k, a szkoda.
Wiem, wiem.... pisanie systemu dla emulatora to "waszym" zdaniem nieporozumienie. A może jednak nie ?
Jakiś czas temu głośno było o projekcie systemu dającego pełną niezależność od sprzętu.
W pewnym sensie "wirtualna maszyna" Javy daje taką niezależność.
W przypadku Javy mamy emulator sprzętu który w wersji sprzętowej(śmiesznie to brzmi) chyba nie istnieje .... a dlaczego by nie można było zrobić czegoś takiego z amigą ?
Czy nie lepiej zrobić wersje Amithlona dla PPC , x86 i napisać jeden system pod ten wirtualny 68k, niż rozdrabniać środowisko na części ? Aros w wersjach na x86 i PPC też nie jest kompatybilny nawet z samym sobą i jedna binarka nie będzie działać na obu systemach.
Amithlon dałby taką możliwość.
O wydajności nie ma co dyskutować bo temat był wałkowany wielokrotnie i zawsze wychodziło na to że stosunek ceny do szybkości w przypadku Amiuthlona zawsze jest najlepszy.
Stabilność amithlona też jest bardzo wysoka.... porównywalna ze stabilnością nowych Amig czy pegasosów.
I wcale nie jest to takie nierealne.
OS4 w wersji 68k działa bardzo ładnie na Amithlonie, a podobno także na UAE (tego nie udało mi się sprawdzić).
Niestety na nowego kernela dla 68k nie ma co liczyć, inne elementy systemu przestają ukazywać się w wersjach 68k, a szkoda.
Wiem, wiem.... pisanie systemu dla emulatora to "waszym" zdaniem nieporozumienie. A może jednak nie ?
Jakiś czas temu głośno było o projekcie systemu dającego pełną niezależność od sprzętu.
W pewnym sensie "wirtualna maszyna" Javy daje taką niezależność.
W przypadku Javy mamy emulator sprzętu który w wersji sprzętowej(śmiesznie to brzmi) chyba nie istnieje .... a dlaczego by nie można było zrobić czegoś takiego z amigą ?
Czy nie lepiej zrobić wersje Amithlona dla PPC , x86 i napisać jeden system pod ten wirtualny 68k, niż rozdrabniać środowisko na części ? Aros w wersjach na x86 i PPC też nie jest kompatybilny nawet z samym sobą i jedna binarka nie będzie działać na obu systemach.
Amithlon dałby taką możliwość.
O wydajności nie ma co dyskutować bo temat był wałkowany wielokrotnie i zawsze wychodziło na to że stosunek ceny do szybkości w przypadku Amiuthlona zawsze jest najlepszy.
Stabilność amithlona też jest bardzo wysoka.... porównywalna ze stabilnością nowych Amig czy pegasosów.
18.07.2004 21:53
[#28]
Re: AROS - ciag dalszy ata.device
A wszystkie programy też napiszesz od nowa pod taki wirtualny sprzęt?
18.07.2004 22:28
[#30]
Re: AROS - ciag dalszy ata.device
@Jacek Rzeuski, post #28
W odpowiedzi na komentarz #10327
Oczywiście ... NIE.
Bo i po co ?
Przecież zaletą amithlona jako wirtualnej amigi jest właśnie to, że działa na tym cały soft dla amii klasycznej.
Pod OS4 odpalonym na Amithlonie też działa większość softu z os3.x (to samo co działa pod OS4 na prawdziwej amidze 68k).
Nie wiem o co właściwie Ci więc może chodzić z tym przepisywaniem.
Oczywiście ... NIE.
Bo i po co ?
Przecież zaletą amithlona jako wirtualnej amigi jest właśnie to, że działa na tym cały soft dla amii klasycznej.
Pod OS4 odpalonym na Amithlonie też działa większość softu z os3.x (to samo co działa pod OS4 na prawdziwej amidze 68k).
Nie wiem o co właściwie Ci więc może chodzić z tym przepisywaniem.