Owszem, MiNT może się sypać. Ale to są sytuacje przewidywalne. Jeśli program SCHEISSE.PRG wydany przez Application Systems Heidelberg powoduje zwałkę MiNT-a, to powoduje ją zawsze. Przeciwnie, z MagiC-em nigdy żadnej powtarzalności nie udało mi się uzyskać.

Co do nie zgadzania się, że MagiC do piachu: nie musisz się zgadzać, on już poszedł do piachu. To było jasne od samego początku, że system komercyjny zejdzie śmiertelnie w chwili, kiedy jego produkcja przestanie się opłacać. Przestała się opłacać w 1998 roku i od tamtej pory MagiC jest systemem martwym. Nawet Andreas Kromke przyznaje - cytat powyżej - że teraz to on by to "cudo" zrobił zupełnie inaczej.

Od początku było też jasne, że swobodne - powiedzmy - podejście do standardów ustalonych jeszcze przez Atari, oraz wojenka z MiNT-em, na którą wybrali się autorzy MagiC-a oraz jego dystrybutorzy, były obliczone na szybkie wycięcie z resztek atarowskiego rynku konkurencji, szybkie zarobienie na tym rynku możliwie dużej kasy, oraz przyciągnięcie jak największej liczby byłych atarowców do Maca - bo ASH jest dystrybutorem softu na Maca, jakby kto nie wiedział.

Sorry, panowie, do tej pory pusty śmiech mnie ogarnia, jak przypomnę sobie te teksty. Ta dokumentacja programistyczna do MagiC-a 5, to wybrzydzanie, ojej, MiNT jest taki przestarzały, taki prymitywny, a feEe, za to MagiC taki elegancki, taki nowoczesny ... sorry, prawda jest taka, że obsługa wszystkiego w MagiC-u poza podstawami GEMDOS-u to jest prymityw i epoka kamienia łupanego: np. u:/pipe/ nadaje się tylko do drag'n'drop, niech ktoś zrobi na tym ptysia, tu mi kaktus wyrośnie.

Phh.

MiNT na SV2k4 startował bardzo ładnie, tylko że padła mi partycja ext2fs z binariami. Na superbloku jest bad sektor, nie wiem od czego. Może od transportu :(

Co do walczenia: tłumaczyłem już Adamowi, jestem zmęczony. Poza tym - ja jestem filologiem, nie infomatykiem. Może oni mają rację, istnieje taka możliwość, aczkolwiek w nią nie wierzę za bardzo. Po prostu czekam i patrzę, co z tego wyjdzie. Na razie wychodzi na moje (tj. liczba problemów się zwiększa, chociaż wg. szumnych zapowiedzi sprzed roku miała się zmniejszać).

No, a w zasadzie dlaczego miałbym zostawać w piaskownicy, skoro zamek mi się przestał podobać?

Siedziałem przy Mincie 7 lat, w różny sposób go próbując rozwijać. Poza tym za sprawą nie kogo innego, tylko moją właśnie "the FreeMiNT project" powstał z martwych w roku 1997, bo w tej piaskownicy, kiedy się zjawiłem z wiaderkiem i grabkami, nie było już literalnie nikogo. Jak dla mnie chyba wystarczy i może powinienem się zająć czymś innym? Tym badziej, że jak mówię, zamek mi się nie podoba.

Jedno z dwojga, ponadto:

1) albo to oni wiedzą lepiej ode mnie, co z tego będzie, wobec tego poradzą sobie świetnie bez mojej osoby;

2) albo to ja wiem lepiej, wobec tego tym bardziej nie ma sensu, żebym przykładał ręki do czegoś, co się nie uda i potem będzie trzeba sprzątać.

Ja jestem reformowalny - to znaczy zmieniam zdanie - ale pod wpływem faktów, a nie słów. Wyrażenie "MagiC jest stabilny", powtarzane przez posiadaczy MagiC-a jak mantra, słyszę od początku, to jest od pojawienia się wersji 5.01, co to pierwsza na Falconie miała działać. 5.02 miał mieć "poprawioną stabilność", 5.03 miał być "dużo bardziej stabilny", a 6.0 "teraz już naprawdę stabilny". Uodporniłem się na te teksty po prostu. "Teraz Magic jest już stabilny". Teraz? Już? Przecież to jest dokładnie ten sam Magic 6.0x, co sześć lat temu:

http://groups.google.com/groups?selm=pa ... put=gplain

a sześć lat temu, to on był niestabilny jak jasna cholera. Poza tym, jak już pisałem, twierdzenie, jakoby MagiC był niestabilny tylko na Falconach, to mitologia: na STE jest niestabilny dokładnie tak samo. Pokutuje też mit, że MagiC jest stabilny na TT, bo był pisany na TT. Może i był, ale ja mam TT-tkę i MagiC wali się na niej tak samo jak na wszystkim innym.

Poza tym Vulgar się tu zachwyca, jaki to jest świetny system, a proszę, co na temat ogólnego dezajnu sądzi autor:

http://groups.google.com/groups?selm=dc ... put=gplain

Polecam łaskawej konsyderacji ostatnie zdanie. I napisał to człowiek, który przy każdej okazji glanował MiNT-a i wychwalał MagiC-a jaki to on jest świetny i jaki nowoczesny (od tego na widok wyrazu "modern" już mi się chce rzygać czasami, jak mam być szczery). A teraz - no cóż, teraz pan A.K. byłby mądrzejszy i zrobiłby dużo lepiej to co swoim własnym zdaniem poprzednio już zrobił tak świetnie.

Dobrze, dość o tym, teraz co do pryncypiów. Dla mnie system operacyjny nie musi być w stu procentach stabilny. System operacyjny może być co najmniej w 75% stabilny, ale musi za to być w stu procentach przewidywalny. Inaczej nie da się na maszynie, gdzie jest zainstalowany, pracować.

Dla mnie praca na komputerze przez lata oznaczała pisanie tekstów. Teksty do publikacji pisałem m.in. pod Papyrusem, napisałem tego całe tony, przy czym były to sesje trwające nieraz po kilkanaście godzin bez przerwy. Tak samo z pisaniem programów, nad jednym (EmuXL choćby) potrafiłem ślęczeć po 18 godzin z otwartym edytorem tekstu, od czasu do czasu save, przejście do shella, make, uruchomenie, sprawdzenie, działa/nie działa, jedziemy dalej. I tak cały dzień, albo całą noc.

Przy takiej pracy MiNT nie sypnął mi się *NIGDY*. Bywało, że komputer pracował dwie, trzy, cztery doby bez reboota, bo w tle kompresowały się pliki mp2 :-) A w MagiC-u wiadomo, to jest loteria, albo się sypnie, albo nie, nie można mu wierzyć, a juz na pewno nie można ryzykować napisania większego artykułu, bo MagiC sypnie się np. za pociśnięciem Ctrl/S i jesteśmy wiele godzin pracy do tyłu.

Tak więc, takiego zdania, że system ma mieć ładne ikonki i szybko rysować okienka, a co poza tym, to niech się dzieje wola nieba, ja respektować nie mogę - bo to jest podejście niepoważne. Ci, co tak twierdzą, używają komputera jako zabawki do bawienia się ikonkami, bo swoje pracki czy to domowe czy to zawodowe robią na pececie. Była zresztą o tym mowa nad zapiekanką w Gdańsku. Takiemu nie robi różnicy, że po 30 minutach klikania w ikonki zobaczy "FATALER FEHLER IM GEMDOS" - reboot i zapominamy o sprawie. Jakby jednak doszło przy tym do utraty rezultatów wielogodzinnej pracy - to prawdopodobnie zdanie operatora zmieniłoby się diametralnie, i nie nadawałoby się do publikacji.

Pokaż mi system z iksami w kernelu, to uwierzę :-)

Zawracasz głowę, Magic się wywala z AUTO i bez, z CPX-ami i bez, z akcesoriami i bez, oryginał i lewa wersja, na Falconie i nie na Falconie. Ja w te mity, że "stabilność Magica zależy od wielu czynników" przestałem wierzyć, kiedy zainstalowałem MagiC-a koledze na STE i sypało się dokładnie tak samo, jak u mnie na Falconie.

Z rasizmu zapewne :twisted:

Zależy, co rozumiemy pod "niedopracowany". Jest stabilniejszy niż Magic, czyli moim skronym zdaniem o tyle właśnie jest bardziej dopracowany. A co do toporności, to nie wiem co masz na myśli.

Przecież rozmawialiśmy na SV2k4, mnie ten temat niezbyt interesuje ...

CPU można zrobić na FPGA. Chyba są nawet darmowe tzw. "kory" do zaprogramowania np. Intela 8051 czy takich tam.

Za to masz gorsze rozszerzenie. Coś za coś.

[ Dodano: 14.01.2005 22:33:38 ]

Jasne, łatwość montażu to duża zaleta, wpinasz i po krzyku. Pod warunkiem, że rzecz do wpięcia masz jedną, ale załóżmy. Jednak za tę cenę - i za cenę zachowania stu procent Atari w Atari - taka dopałka będzie miała dużo mniej możliwości, przez co nie jest aż tak atrakcyjna. Ostatecznie, transfer nawet przez najszybszy port na 1,77 MHz, to nie to samo, co bezpośrednie adresowanie na 14 MHz.

Co do wycyklowanych programów: plany Pasia zakładają bardzo dużą, wręcz stuprocentową kompatybilność, bo do uruchamiania takich programów będzie używany stary procesor. A poza tym, na peceta też były cyklowane gierki i demka, i gdzie one teraz są?

[ Dodano: 14.01.2005 22:39:52 ]
PS. Zakładam, że z takimi poglądami masz standardową atarynkę, tj. z 64 albo 128 k pamięci, jak fabryka dała?

Teoretycznie można zrobić układowi DSP power on/off funkcjami Ongibit() i Offgibit(), a potem przeładować bootstrap funkcją DSP_ExecBoot() - o ile dobrze pamiętam nazwę. To są wszystko funkcje XBIOS-u. Ale, z tego co słyszałem, nie zawsze to chce działać, podobno.

A ja owszem, widzę. A to dlatego, że znam praktykę na komputerze, który ma dwa procesory, z tego jeden wyposażony we własną pamięć i podpięty przez porty I/O. Chodzi o Falcona030 i jego DSP. Bywa tak, że po tym, jak jeden program właduje się do pamięci DSP i tam namiesza, to drugi już tego nie może zrobić i DSP jest nieczynne (aż do resetu). Nie jest tak zawsze, ale tak bywa.

Właśnie dla uniknięcia takich sytuacji wolałbym w tej teoretycznej karcie koproca podział na funkcje, które są predefiniowane i zawsze takie same, oraz oddzielną możliwość ładowania i uruchamiania własnych funkcji przez program.

1 MB pamięci powinien starczyć do tego aż nadto.

No o tym właśnie mówię: można przetransferować, ale ogólnie transfery danych będą zachodzić ze starą szybkością, podczas gdy z Pasiową kartą transfer nawet po starej pamięci będzie 3-4 razy szybszy; to moim skromnym zdaniem daje lepsze pole do popisu jeśli chodzi o np. gry niż nawet najszybszy układ mnożący zamontowany na karcie.

Zwłaszcza, że jedno nie wyklucza drugiego.

Nie, to nie jest problem "generalny", tylko taka upierdliwość dnia codziennego.

No usiłuję ci właśnie przetłumaczyć, że też nie... Co ci po mocy obliczenowej Pentium 4 2,5 GHz, który ci rozpakuje divxa, jeśli 6502, nawet nie zajmując się niczym innym jak odbiorem strumienia danych od pentiuma, nie wyrobi się na wyświetlenie nawet 25 klatek animacji na sekundę?

Toteż, jak ktoś tu już cichutko napisał (ale został zignorowany), pasiowa karta wchodzi w podstawkę od procesora.

Byłoby to twierdzenie słuszne, ale następnik jest fałszywy. To znaczy: nie ma co do mej wiedzy możliwości zrobienia "tego" zewnętrznie. To znaczy, karta zewnętrzna nie będzie miała takich możliwości, jak rozszerzenie wewnętrzne. Czyli, jedna rzecz nie może zastąpić drugiej. Ale też z drugiej strony nie wykluczają się wzajemnie.

Wg. mnie zewnętrzna karta z drugim 65c816 taktowanym wysoko (np. 14 MHz) i własną pamięcią mogłaby się przydać jako koprocesor (do karty Pasia albo bez niej). Część funkcji można byoby mu przypisać na stałe (np. obliczenia zmiennoprzecinkowe), a resztę pozostawić do swobodnego wykorzystania przez programy.

Tak, jestem pewien, że na Falconach jest ten sam problem.

[ Dodano: 09.01.2005 20:26:19 ]

No właśnie, zszedłem z GG mówiąc, że idę spać, ale zanim to zrobiłem, usiadłem jeszcze do atarynki i jakoś tak mi senność minęła  ;)

Ok, co jest źle; otóż Caviar nie ruszy za chińskiego boga, jeśli się po włączeniu zasilania nie wykona tych dwóch kolejno czynności:

1) odczyta konfiguracji przez IDENTIFY DRIVE (a dotychczasowe wersje interfejsu odczytują geometrię z MBR, którego Caviar nie pozwala odczytać);

2) tejże konfiguracji nie zapoda z powrotem przez INITIALIZE PARAMETERS;

Dodatkowo, zanim się tego nie zrobi, dysku NIE WOLNO resetować softwareo'wo (jaka piękna polszczyzna).

Przerobiłem HDBIOS 1.5 pod tym kątem, wykorzystując iteracyjnie zasadę nieskończoności ("nie ma takiego programu, którego nie dałoby się skrócić o jeszcze jeden bajt"). W rezultacie powstał HDBIOS 1.6, który powinien już inicjować Caviary poprawnie.

[ Dodano: 09.01.2005 20:38:59 ]

Został mi jeden bajt wolnego miejsca i obawiam się, że żadna zasada nieskończoności już tu nie pomoże  ;)

Proszę bardzo. Lepiej, żeby działały dobrze, bo przesłać nową wersję nieprędko będę mógł  ;)