Relacja OSH-a z Amiga 30 w Neuss

15.10.2015 21:32

#a30-article { width: 50%; padding: 1rem; line-height: 1.5; text-align: justify; } #a30-article li { margin-bottom: 0.66rem; } p#a30-intro { border-left: 4px white solid; padding: 0 15rem 0 0.75rem; margin: 0 0 2.5rem 0; } @media screen and (max-width: 1024px) { #a30-article { width: 75%; } } @media screen and (max-width: 800px) { #a30-article { width: auto; } p#a30-intro { padding-right: 0; } } Aby uprzedzić wszelkie komentarze typu: „e, za mało konkretów na temat amigowych wieści” informuję, że na Amiga 30 Jahre pojechaliśmy jako osoby prywatne, a nie oficjalna delegacja PPA, w związku z czym nasza relacja jest relacją zwykłych użytkowników. Poza tym, ja byłem głównie w pobliżu naszych trzech komputerów i nie bardzo mogłem uczestniczyć we wszystkich prezentacjach. Szczegółowe informacje na temat nowinek ze świata amigowego znajdziecie zresztą w artykule mailmana. Tym razem ekipa PPA pojechała tylko w dwuosobowym składzie: alt_ i ja. Wyruszyliśmy ze Świdnicy ok. godziny 12:00. Naszym celem był Düsseldorf. Od razu po rozpoczęciu podróży ustalił się podział ról: alt_ prowadził, ja zaś zapewniałem oprawę muzyczną podróży. Nie jestem pewien, czy zawsze trafiałem w jego gusta, ale ponieważ zaprotestował tylko raz, przy próbie puszczenia Rammsteina (nie, że nie lubię, ale w tamtej chwili mnie rozpraszało - alt_), chyba udało mi się stworzyć w miarę przyjemne warunki. Podróż upłynęła bez większych przygód – pomyliliśmy trasę zaledwie trzy razy (jazda bez navi - do soboty nie działał mi internet w roamingu - alt_). Jazda niemieckimi autostradami byłaby prawdziwą przyjemnością, gdyby nie pogoda, która postanowiła pokazać co potrafi i uraczyła nas taką huśtawką, jakiej dawno nie widzieliśmy. Momentami lało tak, że wycieraczki nie nadążały z usuwaniem strug wody, po czym następował gwałtowny przeskok do strefy bezdeszczowej. Niebo miewało czasem barwę rodem z najlepszych horrorów. Koniec końców dotarliśmy do Düsseldorfu cali i zdrowi, choć nieco zmęczeni. Następnego ranka wyruszyliśmy w drogę do Neuss, znajdującego się tylko 15 km od naszej bazy. Dojechaliśmy bez przeszkód, ale prawdziwym wyzwaniem okazało się znalezienie miejsca parkingowego – zajęło nam to 15 minut, w czasie których kręciliśmy się wokół siedziby imprezy – Rheinisches Landestheater. W trakcie tych poszukiwań spotkał nas przejaw niemieckiej uprzejmości – pewna młoda (ładna!) dziewczyna zwalniała miejsce i gdy zobaczyła, że wjeżdżamy na parking, podeszła do nas i podała nam jeszcze nie do końca wykorzystany bilet. Było to bardzo miłe! Wreszcie udało się zaparkować i zaczęliśmy wynosić sprzęt, którego na szczęście nie było za dużo: moja A1200 w obudowie E/BOX oraz A1000 i potężnie uzbrojona A4000 alt_’a. Pierwszą osobą, jaką zobaczyliśmy był Stefkos, który zaoferował pomoc w instalacji na miejscu. Dziękujemy! Po rejestracji na miejscu otrzymaliśmy bilety w formie małych folderów, na których oprócz programu imprezy były też kody rejestracyjne pakietów „C64 Forever 2014” oraz „Amiga Forever 2014” firmy Cloanto. Identycznie było w czasie imprezy w Amsterdamie. Po zainstalowaniu sprzętu zaczęliśmy się rozglądać z zaciekawieniem. Ludzi było dużo, podobnie jak komputerów w najróżniejszych konfiguracjach: dostrzegłem sporo klasyków, od A1000 i A500, przez A1200, skończywszy na A3000, A4000, CDTV oraz A2000, która przyciągała uwagę, ponieważ była przemalowana na czarny kolor, co wyglądało niezwykle gustownie. Poza tym swoje stoisko miały firmy Hyperion, na których można było dostrzec Sam440 oraz AmigęOneX1000, i A-EON, gdzie pokazywano prototyp AmigiOneX5000. Widziałem też amigowego laptopa z działającym OS4.0 – Limebooka, który niestety nie wszedł do produkcji seryjnej. Jak głosił opis na tabliczce obok komputera, zbyt wcześnie poinformowano opinię publiczną o powstawaniu takiego modelu, zanim zakończono negocjacje z Lime Inc. Negocjacje nie powiodły się i firma zmuszona była anulować projekt. Wielka szkoda! Laptop z działającym OS4 – możecie sobie to wyobrazić? Oprócz tego było stoisko człowieka, który prezentował OS4.0 działający na Pegasosie II, poza tym A4000 w ładnej obudowie od Micronika i jeszcze jakąś jedną Amigę. Moją uwagę przyciągnęło stoisko promujące projekt MEGA65 – jest to inicjatywa mająca na celu wskrzeszenie komputera Commodore 65 (albo inaczej C-64 DX). Był on planowany jako następca C64 początkiem lat 90. (głupi pomysł) Prototyp został skreślony po wyprodukowaniu niewielkiej liczby prototypów mniej więcej w momencie, kiedy Commodore ogłosiło upadłość. Miał znacznie rozszerzony interpreter BASIC-a oraz wmontowaną stację dysków 3,5 cala, poza tym rozszerzone możliwości graficzne, dwa SID-y i parę innych ciekawych rozwiązań. Oprócz tego zapewniał niemal pełną kompatybilność z C-64. Udało mi się porozmawiać z jednym z ludzi stojących za tym projektem. Zamiarem jest jak najwierniejsze odtworzenie zarówno wyglądu, jak i możliwości technicznych tego komputera, z poprawieniem niektórych błędów. Sam komputer jest umieszczony w układzie FPGA. Jak się dowiedziałem, wszystko stało się możliwe po tym, gdy jeden z kolekcjonerów kupił prototyp C-65 za bagatela, 20 tys. euro (!) i wypożyczył w celu dokonania niezbędnych pomiarów oraz reverse engineeringu systemu i układów. Efekt zwala z nóg, ponieważ prototyp MEGA65 wygląda dokładnie jak oryginał i tak się też zachowuje. Moim zdaniem to bardzo ciekawa inicjatywa, a organizatorzy stawiają na w pełni profesjonalne podejście, z czym wiąże się odpowiednia promocja projektu. Zainteresowani znajdą informacje na stronie projektu. Swoje stoisko miał również Chris Hülsbeck, na którym można było kupić jego utwory wydane na płytach CD, zarówno oryginalne, jak i remiksy. Niestety, tam byłem tylko raz i w sumie niewiele zobaczyłem, ponieważ aż tak bardzo mnie to nie interesowało. Nie zabrakło oczywiście Dave’a Haynie’ego oraz R. J. Micala, który jak zwykle był w doskonałym humorze. Rzadko zdarza się spotkać człowieka tak pozytywnie nastawionego do ludzi – stale się śmiał. Alt_ wręczył R. J.-owi butelkę piwa, czym jeszcze bardziej poprawił mu humor. R. J. zaprosił nas do wysłuchania opowieści amigowych, oczywiście skorzystaliśmy z tego zaproszenia. Na scenie był też Dave Haynie. Obaj opowiadali o swoich czasach w Commodore. Przy okazji R. J. opowiedział zabawną historię: podczas projektowania Amigi, największym zagrożeniem dla delikatnych prototypów układów były ładunki elektrostatyczne. W związku z tym salę, w której projektowano układy wyłożono matami antystatycznymi, a z krzeseł porobiono korytarze, którymi należało się poruszać. Nie pamiętam dokładnie dlaczego tak było, ale R. J. mówił, że w czasie przechodzenia tymi korytarzami trzeba było co chwila się pochylać, wskutek czego wyglądało to tak, jakby konstruktorzy oddawali pokłon swojemu dziełu. Z kolei Dave opowiadał, dlaczego Amiga 2000 powstała w Niemczech. Zmagał się swego czasu z jakimś problemem i jeden z jego przełożonych zniecierpliwiony stwierdził, że „potrzebujemy do tego Niemców”. Niemcy faktycznie pojawili się w firmie. Dave pojechał do domu, puścił sobie ostrą muzykę i wtedy go olśniło. Wrócił do firmy i rozwiązał problem, przy czym jakoś tak wyszło, że zasługę przypisano Niemcom. Niestety, nie do końca rozumiałem, co mówił, tak więc nie daję gwarancji, że dokładnie o to mu chodziło. Tuż obok nas ulokował się sympatyczny Niemiec, który miał na stanowisku A500 oraz A1200 w obudowie Micronika i grał z zacięciem w Jaguara XJ220. Ponieważ to moja ulubiona wyścigówka na Amigę, nie odmówiłem sobie przyjemności stoczenia z nim pojedynku w Wielkiej Brytanii z tym, że poprosiłem go o podłączenie myszki. Bardzo go to zdziwiło, ale nie protestował i już po chwili walczyliśmy na torze. Muszę nieskromnie przyznać, że nie miał ze mną szans – myszka jest o wiele bardziej precyzyjna niż joystick. Stwierdził, że pierwszy raz widzi kogoś, kto gra myszą w amigowe gry tego typu. Potem porozmawiałem z nim chwilkę i okazało się, że jego brat pracował w Microniku i to w polskim oddziale w Bartoszycach. Obok jego stanowiska było stanowisko z grawerką, gdzie można było sobie wygrawerować na metalowych przedmiotach (własnych lub zakupionych na stoisku, np. na kłódkach), co kto chciał. Oczywiście alt_ nie przepuścił okazji i od soboty na jego telefonie można z tyłu dostrzec pewien napis. Jaki? Sami go zapytajcie. Był oczywiście też niezmordowany Petro Tyschtschenko, który sprzedawał egzemplarze swoich wspomnień z czasów kariery w Commodore. Na jego stoisku można było zobaczyć też np. pierwszą płytę główną Amigi 1200 wyprodukowaną we francuskiej firmie Solectron, zatopioną w przezroczystym plastiku oraz szereg nagród, jakie zdobył za czasów Commodore’a. Petro jest bardzo sympatyczną osobą i każdemu amigowcowi życzę, aby go mógł spotkać. Naprzeciwko stoiska Petro miał swoje stanowisko Jens Schönfeld z Individual Computers, który sprzedawał produkty ze swojej firmy. Ofertę miał bogatą, wśród nich były karty turbo ACA oraz scandoublery Indivision. Ceny były umiarkowane, alt_ skusił się na kupno ACA1221 i był z tego powodu zadowolony. Z kolei ja, jako kolekcjoner starych gier, dotarłem do stoiska innego kolekcjonera, który sprzedawał część swojej kolekcji, ponieważ, jak sam stwierdził, miał już tego za dużo. Nie chcę się nawet domyślać, ile... W każdym razie, za 20 euro wzbogaciłem się o pudełkowe niemieckie wersje „Battle Isle” oraz „Megatravellera I”. Był również Trevor Dickinson, który podczas prezentacji zapowiadał produkcję nowych płyt głównych o kodowej nazwie „Tabor”, opartych na PPC. Ceny, z tego co pamiętam, mają oscylować w granicach 700-1000 euro. To dużo, ale niestety, amigowanie jest drogim hobby... Swoją prezentację mieli także ludzie z Cloanto, którzy tradycyjnie mówili o pakiecie Amiga Forever. Był też człowiek z ekipy AROS-a, który informował, że AROS przekształca się w pełnoprawny system operacyjny, który będzie dostępny na Amigę 68k (!), PPC oraz platformy nowej generacji i x86. Nie zapamiętałem z tego niestety zbyt dużo, ponieważ słuchałem kątem ucha. Na scenie był też koncert muzyczny, ale znów niespecjalnie mnie to interesowało. Swoją prezentację miał też Dino Dini (KickOff, KickOff 2), który opowiadał o swoich grach, ale o tym tylko słyszałem. Naszemu koledze Radzikowi udało się też chwilkę porozmawiać z R. J. Micalem. Na pytanie, czy widzi sens w tym w powrocie Amigi na rynek R. J. powiedział, że jeszcze 5 lat temu zdecydowanie stwierdziłby, że to już zamknięta historia, ale teraz, patrząc na ruch, jaki zaczął się w amigowym światku, widzi szansę. Potrzebny jest jednak inwestor, który ukierunkowałby wszystkich w jednym kierunku, ponieważ niestety, w obecnej chwili każdy ciągnie w swoją stronę, a nie jest to dobry pomysł na to, aby Amiga wróciła do gry. Może więc jednak...? Czas mijał zdecydowanie za szybko, w końcu musieliśmy się pakować. Uścisnęliśmy dłoń ludziom związanym z Amigą i pozabieraliśmy sprzęty na dół przed wyjście. Alt_ poszedł po samochód, a ja podszedłem do stoiska z gadżetami. Zainteresowały mnie niemieckie wydania „Retro Gamera” i zacząłem je przeglądać. Wówczas człowiek ze stoiska zapytał, czy jestem zainteresowany. Zaprzeczyłem, powiedziałem że tylko przeglądam. Wtedy wziął dwa numery i powiedział, „to prezent”. Byłem tak zaskoczony, że ledwo dałem radę wykrztusić słowa podziękowania... W międzyczasie okazało się, że Radzik ze swoją dziewczyną i kolegą zamierzają trochę pozwiedzać Düsseldorf, zatem zapadła decyzja o wspólnej imprezie. Wbrew pozorom nie za dużo pozwiedzaliśmy, praktycznie tylko centrum, wpadliśmy do jakiejś knajpki, coś zjedliśmy. W czasie konsumpcji zajęliśmy się kontemplowaniem urody co ładniejszych dziewczyn i muszę przyznać, że opinia o brzydkich Niemkach jest moim zdaniem lekko przesadzona (aczkolwiek nie do końca jestem pewny, ile z nich było czystej krwi Niemkami ;)). Porozmawialiśmy trochę i wróciliśmy do bazy noclegowej. Powrót przebiegał spokojnie, tym razem drogę pomyliliśmy tylko raz, a pogoda była naprawdę ładna, więc mogliśmy podziwiać piękne widoki. Alt_ stwierdził, że w tę stronę słuchamy jego muzyki, w związku z czym samochód rozbrzmiewał dźwiękami albumu “Acoustic” grupy „Above & Beyond”. Szczególnie polecam tę płytę – puszczona w domu sam na sam z dziewczyną może BARDZO pozytywnie wpłynąć na atmosferę. ;) Do Świdnicy dotarliśmy cali i zdrowi ok. godziny 20:30. Tak zakończyła się nasza amigowa wyprawa. Tekst: OSH Korekta, fotografie: alt_

Wywiad z Jerome Marchalem (kwiecień 2014)

31.08.2015 09:27

Mateusz Eckert: Przedstaw się proszę pokrótce polskim amigowcom. Jerome Marchal: Nazywam się Jerome Marchal. Mam 34 lata, mieszkam we Francji. Jestem zafascynowany starymi komputerami, głównie ze stajni firmy Commodore. M.E.: Jaka jest Twoja „amigowa historia”, jak to wszystko się zaczęło? Czy przed stworzeniem X-Bench napisałeś jakieś inne programy lub brałeś udział w tworzeniu gier i produkcji scenowych? J.M.: Odkryłem Amigę 22 lata temu, po paru latach użytkowania Commodore 64. X-Bench jest moim pierwszym opublikowanym publicznie projektem. W przeszłości napisałem parę narzędzi, jednak były one dystrybuowane tylko w gronie moich znajomych. M.E.: Jak wpadłeś na pomysł stworzenia X-Bench? Jaki był Twój cel i motywacja? J.M.: Stworzyłem X-Bench, ponieważ standardowy Workbench jest dla mnie szary i brzydki, a uruchamianie gier WHDLoad spod systemu jest powolne. M.E.: Czy kiedykolwiek byłeś związany z amigową demosceną? Co zainspirowało cię do nadania X-Bench wyglądu w stylu cracktro? J.M.: Jestem założycielem grupy Grim Project, która była aktywna na amigowej scenie w początku XXI wieku. Ogólnie, pasjonuję się demosceną i ideą tworzenia jak najlepszych efektów na słabszym sprzęcie. Uwielbiam oglądać najnowsze produkcje na C64 i Amstrada, które łamią coraz to nowe bariery i stawiają coraz wyżej poprzeczkę. Nudzą mnie potężne, trójwymiarowe dema na PC, ponieważ żadnym sukcesem nie jest osiąganie takich efektów, przy ogromnej mocy nowoczesnych CPU i GPU. M.E.: Jakie są Twoje plany na przyszłość odnośnie X-Bench? Czy planujesz tworzenie dalszych aplikacji na Amigę? J.M.: Obecnie pracuję nad wersją 1.x, w której znajdzie się dużo nowych funkcji, takich jak np. screenshoty z gier, filtrowanie po kategorii, lepsze zarządzanie listą ulubionych gier, nowy wygląd i dużo więcej kolorów na ekranie (640 kolorów jednocześnie na chipsecie AGA). Kolejne wersje, powyżej 1.x, będą przynosiły bardzo dużo zmian, więc na chwilę obecną skupiam się na rozwoju X-Bench. Nowymi programami zajmę się, kiedy doprowadzę X-Bench do odpowiedniego poziomu. M.E. Ilu jest zarejestrowanych użytkowników X-Bench? J.M.: Na chwilę obecną mam parę tuzinów zarejestrowanych użytkowników, średnio jeden nowy użytkownik przybywa co tydzień. Ogółem ciężko określić ile osób korzysta z X-bench - najnowszą dostępną wersję pobrało do tej pory, w przeciągu niewiele ponad miesiąca, ponad 500 osób. Jestem pod dużym wrażeniem amigowej społeczności i jej zainteresowania, ponieważ, kiedy rozpoczynałem projekt myślałem, że zainteresowane będzie może 10-20 osób. M.E.: Co myślisz o AmigaOne, MorpOS i AROS? Czy jesteś otwarty także na systemy post-klasyczne? J.M.: Dla mnie osobiście wszystkie te rozwiązania to tylko portowanie czegoś na kształt systemu Amigi, jednak bez jej serca i duszy. Posiadam Sam440 z AmigaOS 4, ale nie używam jej zbyt często i nie zamierzam tworzyć na ten system oprogramowania. Lepiej bawię się moją A1200 z 68060 przetaktowanym na 96 MHz, niż Sam440. Nie wiem, co miałbym na tym komputerze robić. Szanuję jednak tych, którzy uważają to za następną generację Amigi. Artykuł oryginalnie pojawił się w dwunastym numerze Polskiego Pisma Amigowego.

Aquaria

21.12.2012 12:46

Gry od zawsze były domeną naszego komputera. Mimo usilnych starań zmiany tego wizerunku przez dużą część społeczeństwa amigowego, przez wiele lat Amiga nie schodziła z topu i przedstawiana była jako maszyna wykorzystywana głównie do rozrywki. Przez wiele lat wychodziło jej to zresztą bardzo dobrze, jednak czasy świetności naszej przyjaciółki już dawno odeszły w zapomnienie. Obecnie postrzegana jako komputer grupki pasjonatów nie ma szans na nowe i dobre oprogramowanie rozrywkowe. To, na co możemy dziś liczyć to głównie porty starszych tytułów, do których upubliczniono kod źródłowy. Zdarzają się jednak wyjątki, takie jak "Aquaria" - gra, jak na nasze realia młoda i świeżutka. Na dominujące platformy ukazała się w 2007 roku i zdobyła tytuł najlepszej niezależnej gry roku na festiwalu Independent Games Festival, i była debiutem zaczynającej wówczas grupy Bit Blot. Poznajmy się, czyli co w trawie piszczy Gra jest dwuwymiarową zręcznościówką (dość niespotykaną jak na współczesne standardy), której akcja rozgrywa się w podwodnym świecie o nazwie Aquaria. Poznajemy historię Naiji, samotnej istotki przypominającej z wyglądu połączenie syrenki i elfa, żyjącej sobie beztrosko w swoim świecie. W jej świadomości zaczyna rodzić się tęsknota spowodowana chęcią poznania świata, historii swojej rasy i swojego rodu. Nasza bohaterka, która jest jednocześnie naszą narratorką, decyduje się na opuszczenie swojej krainy i wyrusza w podróż w nieznane. Świat Aquarii jest ogromny i ciekawy - przez to, że jest niezwykle barwny z piękną, ręcznie rysowaną grafiką. Skrywa wiele tajemnic, chce się go zwiedzać i zajrzeć w każdy kąt i tunel, aby za chwilę zachwycić się nową, pojawiającą się na ekranie ciekawą postacią. Wraz z naszą bohaterką poznajemy historię o dawno zapomnianej cywilizacji, wojnie, miłości i zmianach, jakie zaszły w tym bajkowym, podwodnym świecie. Jest on naprawdę różnorodny, aby wymienić tu otwarte oceaniczne wody, ruiny, które prowadzą do poznania prawdy, lasy przedziwnych morskich roślin, piękne, a czasem zdradliwe i niebezpieczne. Znajdziemy tu również świat mroku i otchłani, fascynujący i zarazem przerażający, gdzie wzrok nie może dotrzeć. Na naszej drodze spotykamy przeróżne stworzenia morskie, jedne w ogóle nie są nami zainteresowane, z innymi możemy porozmawiać, a z innymi walczyć. Naija, ta zdawałoby się bezbronna istotka, ma jednak niezwykłe umiejętności, z których możemy skorzystać podczas zagrożenia. Potrafi siłą swego głosu kontrolować moc, uczy się zaklęć i pieśni, dzięki którym wpływa na otaczający ją świat. Dzięki tej umiejętności możemy wraz z Naijią przenosić przedmioty, zamieniać je w potrzebną nam broń. Naija może zmieniać postać, a jej wojownicze alter ego potrafi powalić niejednego morskiego potwora. Zagadki, których trochę tutaj mamy, nie są zbyt trudne, a sterowanie odbywa się za pomocą myszki, pada lub klawiatury. Przyznaję, że najprościej steruje się myszką, używając głównie lewego przycisku (coś w stylu starego, dobrego "Cannon Fodder"). Wymagania Jak na grę z gatunku "action adventure 2D" mamy tu spore wymagania. Minimum 512 MB pamięci (zalecane 1 GB), karta graficzna 64 MB (zalecane 128 MB). Gra wykorzystuje najnowsze wersje SDL, OpenAL i MiniGL. Na mojej Sam440-flex 667 z 512 MB RAM i Radeonem 7000, da się grać w rozdzielczości 640x480. Niestety większa rozdzielczość nie wchodzi w grę przy tej konfiguracji, a czasem zbyt duża ilość obiektów i poważniejsze zaklęcia powodują utratę pamięci i zwis programu, który kończy się resetem na moim komputerze. Nie wiem czy inni użytkownicy mają podobne problemy, ale w moim przypadku ratuję się częstym zapisywaniem stanu gry. Wrażenia Muzyka w grze jest wspaniała, melancholijna, cudownie uspokajająca, czasem nawet smutna. Gdzieś przeczytałem, że gra przypomina "Another World". Jeśli popatrzeć na to, iż zrobiły ją dwie osoby i do tego stworzyły świat "inny", niezwykle wciągający i tak rzadko kreowany wśród programistów - można rzec jedyny w swoim rodzaju - to zgadzam się z tym stwierdzeniem. Podsumowując, gra powinna wywrzeć wrażenie na osobach lubiących podwodny świat akwarystyki, ale także na ludziach wrażliwych, którym brakuje tego czegoś w dzisiejszych grach. "Aquaria" to wielka, interaktywna wyprawa po niezbadanych miejscach, niekończących się tunelach w poszukiwaniu własnego jestestwa i swoich korzeni. Artykuł być może nie przypomina typowej bezstronnej recenzji, okraszonej chłodną kalkulacją. Jest wyrazem szacunku dla autorów fascynującej i jedynej w swoim rodzaju gry, którą gorąco wszystkim polecam. Artykuł oryginalnie pojawił się w piątym numerze Polskiego Pisma Amigowego.

Port MD5 dla AmigaOS 4.1

22.10.2011 17:47

W PPA#1 opisano algorytm CRC32. Widząc dopiero zapowiedź tego artykułu jeszcze przed wydaniem numeru napotkałem na podobny problem. Otóż okazało się, że na mojej Sam440 świetnie "ściąga się" i wypala obrazy ISO (Update 1 dla AmigaOS 4.1, aktualizacje Uboot), ale nie bardzo jest jak sprawdzić ich integralność po zakończeniu operacji pobierania. Problem o tyle istotny, że OWB do dzisiaj nie dorobiło się paska postępu (na szczęście AmigaOS 4.1 sam aktualizuje wyświetlane foldery oraz objętość RAM dysku). Dodatkowo obrazy ISO z dystrybucjami Linuksa dla SAM zazwyczaj posiadają plik [nazwa_iso].md5, więc głupotą byłaby próba instalacji takiego systemu bez sprawdzenia czy obraz jest poprawny. W ten oto sposób nadarzyła się okazja do szybkiego przetestowania SDK dostarczanego przez firmę Hyperion. Dlaczego nie CRC32? Powodów jest kilka. Pierwszy to fakt, że dla obrazów ISO z dystrybucjami Linuksa sumy kontrolne są liczone w MD5. Stan taki ma swoją przyczynę. Podłożem problemu algorytmów z rodziny CRC jest fakt, iż nie dają one odpowiedniej pewności co do integralności kontrolowanego obiektu (wiadomości). Mówiąc już bardziej technicznie - nie są one kryptograficznie silne. MD5 z kolei należy do kryptograficznych, jednokierunkowych funkcji skrótu. Oznacza to w teorii, że: 1. zmiana jednego bitu w wiadomości powoduje inny wyniki funkcji 2. nie ma dwóch różnych wiadomości dających taki sam wynik funkcji 3. z wyniku funkcji nie można odczytać lub wydedukować wiadomości, która została użyta jako wejście 4. ta sama wiadomość zawsze da taki sam wynik. W praktyce charakterystyka z punktu drugiego nazywana jest brakiem kolizji. Jak się okazuje MD5 ma jednak kolizję. To jeden z powodów, dla którego od kilku lat zaleca się zastępowaniem jej silniejszymi funkcjami skrótu, np. z rodziny SHA. Na nasze potrzeby wady MD5 nie mają jednak aż tak dużego wpływu i dlatego przy niej pozostaniemy. Z perspektywy teorii bezpieczeństwa informacji CRC32 ma kilka wad, o których warto wspomnieć w kontekście MD5. Nawet jeśli użyjemy najdłuższego standardowego wielomianu 65-bitowego (CRC64), nadal pozostaje problem wykrywania określonych zmian. Sumy kontrolne zostały wymyślne do wykrywania typowych błędów w transmisji danych, a ich zadaniem była szybka kontrola komunikatu. Oznacza to, że wiadomość można tak zmodyfikować, aby jej suma kontrolna pozostała bez zmian. Dlatego do kontroli obrazów ISO czy pamięci, MD5 lub mocniejsze funkcje skrótu nadają się znacznie lepiej. Różne cele twórców algorytmów CRC i MD (MD5 jest jednym z rodziny funkcji, wcześniejsza jej wersja nazywała się MD4) mają odzwierciedlenie w ich konstrukcji. MD5 nie jest oparta o wielomian, pod który podstawia się kolejne bity wiadomości. Cała wiadomość jest dzielona na równe, 512-bitowe bloki + ostatni blok o długości 448 bitów. Bloki są uzupełniane za pomocą zer do wymaganego rozmiaru. Różnica w rozmiarze ostatniego bloku wynika z faktu tworzenia miejsca na 64-bitowy licznik oznaczający rozmiar wiadomości. W ten sposób wszystkie bloki wiadomości mają jednakową długość 512 bitów. Każdy blok przechodzi transformację, która składa się na wynik końcowy. Zainteresowanych kryptografią odsyłam do Wikipedii gdzie znajduje się dokładniejszy opis algorytmu MD5. "Portujemy" md5.c Gdy stanąłem przed problemem weryfikacji obrazu ISO, sięgnąłem do zasobów OS4Depot i stwierdziłem, że hasło "md5" zwraca zero wyników. Drugim adresem był Aminet i tutaj znalazłem 8 pakietów, z czego najnowszy był z 2000 roku (generator liczb pseudolosowych na bazie MD5 dla 68k i PPC). Ciekawą opcją wydała się wersja dla Arexxa, ale idąc tym tropem równie dobrze mógłbym skorzystać z wbudowanej w AmigaOS 4.1 wersji Pythona. Pakietów dla PPC i wersji nowszej niż 4.0 dla AmigaOS nie znalazłem. Postanowiłem zatem w pełni wykorzystać dostępne mechanizmy i aplikacje w wersji 4.1 systemu. Pierwszym krokiem była instalacja oficjalnego SDK. SDK można bezpłatnie pobrać ze strony firmy Hyperion - w momencie pisania tego artykułu najnowsza publicznie dostępna wersja była oznaczona numerem 53.20 z 1 marca 2010 roku. Ponieważ jest to wersja sprzed Update 2, to pewnie w momencie czytania tego tekstu będzie dostępna nowsza wersja. Instalacja SDK przebiega prosto. Po rozpakowaniu archiwum uruchamiany program instalacyjny i klikamy w "Next". Następnie wykonujemy jeszcze restart (choć można obyć się bez niego - szczegóły znajdziecie w dokumentacji SDK). Program instalacyjny domyślnie zakłada przypisania SDK:. Po restarcie możemy sprawdzić czy wszystko działa. W tym celu uruchamiany kompilator GCC z przełącznikiem "-version". Jeśli GCC się uruchomiło, to znaczy że kompilator działa. Nie spotkałem się z problemami podczas instalacji SDK na czystym systemie, więc niewiele mogę powiedzieć o potencjalnych pułapkach. Natomiast podczas aktualizacji lub usuwania SDK należy uważać i pamiętać o tym, aby usunąć wpisy dodane przez program instalacyjny do Startup-Sequence i User-Startup. Teraz możemy utworzyć plik hello.c: #include <stdio.h> void main() { printf(„Hello world”); } Lub jeśli wolimy c++ (wtedy plik zgodnie z przyjętymi konwencjami powinien nazywać się hello.cpp): #include <iostream.h> void main() { cout << “Hello world”; } Do utworzenia pliku w zupełności wystarczy systemowy Notepad. Po jego zapisaniu w katalogu, w którym znajduje się plik wydajemy polecenie: gcc -o hello hello.c lub gcc -o hello hello.cpp w zależności od wersji dialektu, który wybraliśmy. Przełącznik "-o" definiuje nazwę pliku wykonywalnego, który zostanie utworzony na podstawie kompilacji plików źródłowych. Domyślnie gcc tworzy plik wynikowy o nazwie a.out. W przypadku AmigaOS 4.x kompilator tworzy pliki w formacie ELF a nie HUNK, jak ma to miejsce w przypadku wcześniejszych wersji systemu. Warto o tym pamiętać, ponieważ pakiet bintools poprawnie obsługuje pliki wynikowe AmigaOS 4.x. Dzięki temu możemy na przykład korzystać z narzędzia objdump, które jest dołączone do oficjalnego SDK. Pobieramy plik źródłowy z adresu: http://people.csail.mit.edu/rivest/Md5.c i zapisujemy go na dysku. Teraz możemy skompilować nasz "port" md5.c wydając polecenie: gcc -o md5 Md5.c pod warunkiem, że znajdujemy się w tym samym katalogu, w którym zapisaliśmy kod źródłowy. Do pierwszych prób idealnie nadaje się mechanizm RAM dysku. Jeśli wszystko pójdzie dobrze, powinniśmy otrzymać plik wynikowy md5, który jest gotowy do użycia. Inne strategie portowania Do tej pory korzystaliśmy tylko z narzędzi z oficjalnego SDK. Do tak małego projektu, który składa się z jednego pliku źródłowego, wykorzystanie samego SDK ma dużo sensu. W przypadku bardziej złożonych projektów oczywiście można pisać pliki makefile i używać ich do kompilacji, jednak na dłuższą metę jest to rozwiązanie mało wygodne. Dlatego możemy wybrać dwie strategie: - wykorzystanie środowiska IDE na platformie AmigaOS, - wykorzystanie cross kompilatorów na innych platformach. Opcja druga daje szerokie możliwości i wygodę pracy (zwłaszcza jeśli ktoś tworzy przede wszystkim na inne platformy, a Amiga jest platformą mniej ważną). Można wykorzystać omawiany w poprzednim numerze PPA, AmiDevCPP na platformie Windows. Dla systemów Unix, Linux, BSD dostępne są cross kompilatory, z czego najlepsze doświadczenia miałem z tymi bazującymi na gcc. Pakiet z którym najlepiej mi się pracowało na OpenBSD został przygotowany przez Joachima "Zerohero" Birginga i jest dostępny pod adresem: http://www.zerohero.se/cross/os4.html Wybór AmigaOS jak platformy deweloperskiej stawia nas przed wyborem: Cubic IDE lub CodeBench. Oba pakiety potrzebują oficjalnego SDK. Teoretycznie można na AmigaOS 4.x uruchomić jeszcze StormC PPC, ale w moim przypadku pakiet ten na AmigaOS 4.1 nigdy nie działał stabilnie. Cubic IDE wymaga obecności SDK w wersji 51.22. Idealnie jest najpierw zainstalować Cubic IDE a potem SDK [3]. Rozmowy z twórcą pakietu pozwoliły potwierdzić, że działa on poprawnie z nowszymi wersjami SDK, ale nadal jest wymagana instalacja wersji 51.22 SDK. Niestety Hyperion Entertainment na swojej stronie, w momencie pisania artykułu, udostępniał ze starych wersji tylko 53.13. CodeBench nie był dostępny w pełnej, komercyjnej wersji w trakcie pisania tego tekstu. Chwilami przypomina on StormC PPC, co dla użytkowników tego produktu firmy Haage&Partners może być zaletą. Z drugiej strony inna filozofia działania niż w przypadku CubicIDE nie każdemu musi odpowiadać. Dlatego najlepszym rozwiązaniem jest pobranie wersji demo obu pakietów i ich samodzielne porównanie. Do dalszej pracy będziemy używać CodeBench, ponieważ obecna wersja pracuje poprawnie z aktualnym SDK 53.20. Aby wygodnie edytować kod, musimy najpierw utworzyć projekt. W tym celu wybieramy z CodeBench ToolBar przycisk "Create new project" (żółty sześcian po lewej stronie). W oknie "Project information" wpisujemy następujące elementy: W zakładce General: Project name (czyli nazwa projektu) - wpisujemy: MD5, Project base directory (czyli lokalizacja katalogu, który będzie zawierał nasze pliki) W zakładce Make zaznaczamy opcję "Create Makefile". W zakładce Linker, w polu "Executable name" ustawiamy nazwę pliku wynikowego, np. cbmd5. W oknie Project... dodajemy do pozycji "Source files" nasz plik Md5.c. Teraz zapisujemy projekt i możemy pracować dalej. Podczas pierwszej kompilacji moją uwagę zwróciło ostatnie ostrzeżenie dotyczące wyniku zwracanego przez funkcję main(). Poprawmy ten problem. W tym celu w kodzie źródłowym należy dokonać kilku zmian. Najpierw odszukaj funkcję main() - jest ona na końcu pliku. W jej definicji należy usunąć słowo kluczowe void i zastąpić je słowem kluczowym int. Teraz definicja funkcji wygląda tak: int main( argc, argv) int argc; char *argv[]; Następnie w ostatniej linijce kodu funkcji main() dodajemy kod: return(0); i zapisujemy kod źródłowy na dysk. W oknie "Build window" wybieramy opcję "Build whole Project", co spowoduje skompilowanie wszystkich plików projektu (w naszym przypadku jest to oczywiście tylko jeden plik). Teraz warto się przyjrzeć jeszcze wewnętrznej budowie programu. W oknie "Quick Links" mamy pokazane niektóre funkcje. Jak widać brakuje main() oraz kilku innych funkcji - jest to jeden z elementów do poprawy w kolejnych wersjach CodeBench. Oto kilka istotnych funkcji: MDString () - wylicza funkcję skrótu dla danej wiadomości przekazanej jako parametr MDTestSuit() - testuje poprawność algorytmu na znanych wiadomościach oraz zakodowanych poprawnych wartościach funkcji skrótu dla nich MD5Init() - inicjalizuje funkcję skrótu (bez wywołania tej funkcji algorytm nie będzie działał poprawnie) Transform() - razem z makrodefinicjami serce algorytmu MD5 (tutaj zaimplementowane są wszystkie 4 rundy przekształcenia, które decydują o sile MD5) Odnośniki Cubic IDE http://devplex.awardspace.biz/ CodeBench http://www.codebench.co.uk/ Installing the latest OS4 SDK in Cubic IDE http://www.amigans.net/modules/AMS/article.php?storyid=30 Artykuł oryginalnie pojawił się w trzecim numerze Polskiego Pisma Amigowego.

CRC32, czyli pliki pod kontrolą

25.12.2010 10:13

W ostatnich kilku latach trochę się dzieje w amigowym światku. To nowe płyty główne (Sam440), to nowe wersje systemów operacyjnych (AmigaOS 4.1, MorphOS 2.3), to nowi (starzy) amigowcy (chwała tym, co trwają bez przerw!), którzy albo odgrzebują sprzęt z rzadko przeglądanych szafek, zawalonych zbędnymi rzeczami strychów, czy też ciemnych, wilgotnych piwnic, albo polują na swoją nową przyjaciółkę, śledząc bacznie serwisy aukcyjne. Tak czy inaczej, moda na retro daje się zauważyć. Nowych użytkowników klasycznej Amigi przyciąga jej legenda, a budząca się w nich ciekawość każe przekonać się na własnej skórze, które opowiadane o niej historie to całkowita prawda, a które przesadzone brednie. Spieszą więc oni na portale aukcyjne, by po kilku dniach podchodów, wypatrywania i rywalizacji cenowej pojąć za żonę tę jedyną, najpiękniejszą, prawie dziewiczą oblubienicę. Niewygórowane ceny sprzyjają zakupom. Większość miłośników Amigi może sobie pozwolić od razu na A1200, która ma spore możliwości rozbudowy i pozwala zagrać w większość klasycznych gier (tak, tych pięknych z czasów dzieciństwa, przy których zleciała niejedna noc). Na kupnie samego komputera, zasilacza i myszki zwykle się nie kończy. Ami dobrze jest wyposażyć w łatwo dostępne w Internecie dodatki typu adaptery kart Compact Flash do złącza IDE, czytniki kart Compact Flash na złącze PCMCIA, kartę sieciową LAN lub WLAN. Niezbędnym do korzystania z programu WHDLoad, umożliwiającego beztroskie i wygodne granie w gry wprost z dysku twardego, jest wyposażenie Amigi w rozszerzenie pamięci Fast. Bardziej przyszłościowym rozwiązaniem okazuje się nabycie karty turbo z procesorem z serii 68030. Przyspiesza ona komputer kilkakrotnie, a cena prostego rozwiązania nie przekracza dwukrotności ceny rozszerzenia pamięci. Apetyt rośnie w miarę jedzenia. Pewnego dnia przychodzi do głowy myśl, czy nie byłoby dobrze spróbować coś więcej zrobić na naszej ulubienicy... Obudowa, FastATA, mostek PCI, DVD, karta graficzna, mocna karta PPC i... mogą zacząć się problemy. Podstawowy to niedobór prądu i niestabilna praca, wyświetlanie czerwonych komunikatów "Guru" i przekłamania transmisji. Zużytego i wadliwego sprzętu również nie brakuje i trzeba spróbować sobie jakoś samemu radzić i okiełznać nieposłuszną przyjaciółkę. Ten artykuł powstał z autopsji. Należę do rodzaju użytkowników Amigi, którzy porzucili ją na jakiś czas przesiadając się na PC. Aby sfinansować jego zakup, zmuszeni zostali sprzedać Amigę. A działo się to w czasach, gdy byliśmy jeszcze biednymi uczniami szkół podstawowych lub średnich. Teraz, już jako pracownicy lub właściciele własnych firm, jesteśmy na tyle zasobni (nie mamy co robić z zarabianymi pieniędzmi, żona ma nowe futro i nie wie, że istnieje WinUAE, w garażu błyszczą nowe 4 kółka, dziecko ma nowy wózek, a pieluchy tetrowe odeszły w zapomnienie), że możemy sobie pozwolić na spełnienie marzeń, które blokowały niedostateczne środki finansowe. I stało się. Kupiłem po latach A1200 (poprzednio miałem A600 z 2 MB pamięci) oraz odrębnie kartę turbo. O ile sama Amiga działała, o tyle z kartą turbo nie było tak, jak powinno być. Gdy zgrywałem na dyskietki gry z plików ADF, często pojawiały się błędy odczytu z dyskietek, nawet nowych. Co do dyskietek byłem pewien w 100% ich jakości. Testowałem je na PC, jak i pod FileMasterem i nie miały błędów przy formatowaniu. Weryfikacja również przebiegła pomyślnie. Dodatkowo używanie karty turbo sporadycznie przyprawiało Amigę o samoczynne restarty. Skontaktowałem się z poprzednim właścicielem karty. Po raz kolejny zapewnił mnie, że u niego nie było żadnych problemów. Zgrywanie dyskietek bez użycia karty turbo szło pozytywnie. Gry wczytywały się, a system pracował stabilnie. Postanowiłem na własną rękę zabawić się w detektywa. Mając do dyspozycji Internet, czystą dyskietkę, Amigę 1200 z dyskami systemowymi rozwiązałem problem na dobre! Poszlaka pierwsza - podejrzenia padają na kartę, gdyż tylko podczas jej obecności w Amidze zaczynają się problemy. Sprawdziłem kartę, nie grzała się za bardzo. Dodatkowo 68030 pobiera na tyle mało energii w stosunku do wydajniejszych modeli, że odrzuciłem hipotezę o zbyt słabym zasilaczu. Przeczyściłem tylko środkiem chemicznym złącze kart turbo na płycie głównej Amigi oraz zdemontowałem i zamontowałem ponownie kości pamięci na karcie. Niestety moje starania były bezowocne. Zastanawiającym był fakt przekłamywania zawartości dyskietek. Chciałem w jakiś sposób to sprawdzić. Wykluczyłem błędy spowodowane uszkodzeniem taśmy stacji dysków oraz samej stacji, gdyż przecież problem nie istniał, gdy karta turbo była odłączona. Ze strony karty zostają tylko: styk karty i płyty głównej Amigi, problemy z procesorem 030 lub problemy z modułem pamięci, zimne luty, przerwane ścieżki... Na pierwszy ogień poszły kości pamięci. Potrzebowałem narzędzia, które potrafi wniknąć w plik i coś mi o nim więcej powiedzieć. Żmudne przeglądanie bajt po bajcie w hex edytorze FileMastera odpadało. Odpaliłem zatem jakiś znaleziony na dyskach po poprzednim właścicielu program typu memtest. Był szybki i błyskawicznie potraktował mnie przyjaznym komunikatem, że problemów z pamięcią nie znaleziono. Niespokojny postanowiłem użyć własnej metody sprawdzania zawartości plików - szybkiej, automatycznej i dającej jednoznaczną odpowiedź - angażującej nie tylko pamięć RAM, ale i procesor. Mowa o wyznaczaniu wartości CRC32 dla danego pliku. Jeśli plik na dyskietce i plik skopiowany do pamięci RAM będą miały taką samą wartość CRC32, oznacza to, że podczas transmisji danych z dyskietki do pamięci (lub w samej pamięci) nie występuje przekłamywanie danych. Algorytm można samodzielnie odszukać w sieci (dla dociekliwych). Nam wystarczy wiedzieć, że wynikiem jego działania jest zwrócenie liczby w systemie szesnastkowym z przedziału od 00 00 00 00 - FF FF FF FF oraz fakt, że modyfikacja (lub przekłamanie) chociażby jednego bajtu w pliku zwróci inną wartość CRC32. O ile na PC przydatnym narzędziem okazuje się być Total Commander, o tyle niestety system operacyjny Amigi nie posiada zainstalowanego domyślnie oprogramowania zdolnego do wyznaczania sum kontrolnych CRC32. Z pomocą przychodzi Aminet lub ambitniejsze rozwiązanie - napisanie własnego oprogramowania. Chciałem ambitnie podejść do sprawy i samodzielnie skompilować kod źródłowy, a następnie wykorzystać go na Amidze. Dzięki takiemu podejściu zawsze pozostaje mi możliwość wprowadzania zmian w kodzie i to jest to! Narzędzia długo nie musiałem szukać - sprawdziłem forum "Programowanie" na stronie PPA.PL i okazało się, że jego bywalcy polecają darmowy pakiet programistyczny o wszystko mówiącej nazwie AmiDevCPP. Jego główną zaletą jest jego powszechna dostępność, cena (0 zł!) i możliwość kompilacji kodu na różne platformy amigowe oraz systemy operacyjne, w tym głównie nas interesującą Amigę klasyczną z AmigaOS 3.x. Dodatkowo nie trzeba się martwić wymaganiami tego zintegrowanego środowiska (IDE), gdyż nie instalujemy go na Amidze, a na swoim PC! Na wyjściu dostajemy kod wykonywalny możliwy do uruchomienia na A1200. Warto wiedzieć, że programy skompilowane pod AmiDevCPP wymagają do uruchomienia biblioteki o nazwie ixemul.library. Jej wersje dostępne są na Aminecie. Teraz pora na upolowanie w Internecie kodu źródłowego do wyznaczania sum kontrolnych CRC32. Google, po zadaniu zapytania, "CRC32" wyrzuca trochę stron. Pierwsza z nich to Wikipedia. Na niej skrótowo mamy opisaną definicję i krótko zasadę działania. Druga natomiast to ta strona. Właśnie to jest to! Bardziej szczegółowy opis oraz kod źródłowy mnie zadowolił. Kolejnym krokiem było wejście na stronę AmiDevCPP i pobranie instalatora (plik: AmiDevCpp_graceful_Bulldozer_v098_Setup.exe). Ważył ponad 160 MB, ale na łączu 8 Mb cały proces przebiegł szybko i sprawnie. Zainstalowałem oprogramowanie i uruchomiłem środowisko ze skrótu na pulpicie, który przed momentem się tam znalazł. Z menu "File" wybrałem pozycję "New", a następnie "Project". Następnie zainteresowałem się zakładką nr 3 - "Amiga_m68k" (projekt dla Amigi klasycznej) i ustawiłem typ projektu na "Hello World" (C Project). Pozostawiłem domyślną nazwę pliku na Project1 oraz kliknąłem w przycisk OK. Środowisko IDE zaproponowało mi zapisanie projektu. Tak też uczyniłem, umieszczając plik "Project1.dev" w folderze "Projekty" na dysku "C:". W oknie edycji kodu ujrzałem przykładowy program napisany w języku C. Jak nietrudno się domyślić, jego zadanie polega na wyświetleniu w Shellu napisu "Hello Amiga_m68k World!" oraz w nowej linii "Press ENTER to continue...". Jednak nie on jest naszym celem. Usunąłem cały kod źródłowy z okna edycji i wkleiłem "tak jak leciało" ten znaleziony na stronie 4programmers.net. Z menu "Execute" wybrałem pozycję "Rebuild All". Ponownie pokazał się monit z zapytaniem, gdzie zapisać plik. Wskazywał na folder "Projekty", więc tylko potwierdziłem przyciskiem "Save". Kompilator trochę pomruczał dyskiem i stworzył w folderze "Projekty" plik o nazwie "Project1.exe". Tak, na to właśnie czekałem! To nic innego jak gotowy do użycia na Amidze program stworzony w wiadomym celu. Zmieniłem mu nazwę na "CRC32.exe" - tak o wiele lepiej to wygląda. Teraz przyszła kolej na dostarczenie pliku do Amigi. Wybrałem najprostszy sposób. Wyjąłem z szafki nową dyskietkę 1.44". Poszukałem taśmy izolacyjnej i starannie zakleiłem jej lewy górny róg (okienko) zarówno z przodu, jak i z tyłu dyskietki. Włożyłem dyskietkę do stacji PC z uruchomionym Windowsem XP. Uruchomiłem konsolę i wydałem polecenie: format /N:9 /T:80 Zatwierdziłem operację klawiszem enter. Sztuczka ta pozwala na sformatowanie dyskietki 1.44" jako dyskietki 720 kB widzianej przez Amigę! Następnie skopiowałem na nią plik "CRC32.exe" oraz plik biblioteki "ixemul.library". Plik pozyskałem rozpakowując archiwum z Aminetu. WinRAR którego posiadam na PC spokojnie radzi sobie z plikami w formacie LHA. W rozpakowanym archiwum znajdują się różne wersje biblioteki dla procesorów od 020 do 060 oraz z obsługą koprocesora. Ja wybrałem wersję ixemul-020.library. Uruchomiłem Amigę i system AmigaOS 3.1 z dysku pod nazwą Workbench. Z menu "Workbench" wybrałem pozycję "Execute command". W okienku, które się pojawiło wpisałem "mount PC0:" i nacisnąłem przycisk "Execute". Włożyłem dyskietkę z PC. Workbench zobaczył dyskietkę. Wszedłem na jej zawartość i z menu "Window" wybrałem pozycję "Show", a następnie "All files". No i są! Amiga zobaczyła pliki zapisane przy pomocy PC. Plik CRC32.exe skopiowałem do katalogu "C" Workbencha a "ixemul" do "Libs". Dodatkowo zmieniłem im nazwy: bibliotekę przemianowałem na "ixemul.library" a "CRC32.exe" na "CRC32". Oto chwila prawdy... Z menu "Workbench" wybrałem pozycję "Execute command". W okienku, które się pojawiło wpisałem "new cli" i nacisnąłem przycisk "Execute". W oknie konsoli wpisałem "CRC32" i wcisnąłem ENTER. Program przywitał mnie komunikatem: CRC32 [file...] Udało się! To działa! Program czeka na podanie nazwy pliku. Wpisałem zatem w konsoli: CRC32 C:CRC32 Jako wynik otrzymałem komunikat: CRC-32 (C:CRC32) = 5a691d69 Oznacza to, że program coś wyliczył i wyświetlił wynik na ekranie. To coś, to właśnie wartość sumy kontrolnej obliczonej za pomocą algorytmu CRC-32 dla pliku wykonywalnego tego programu, który znajduje się w katalogu C Amigi. Aby przekonać się, czy ta wartość jest prawidłowa, należy uruchomić program Total Commander na PC, wskazać plik "Project1.exe" z folderu "Projekty" i z menu "Plik" wybrać pozycję "Utwórz sumy kontrolne CRC" oraz potwierdzić przyciskiem "OK". W folderze projekty zostanie utworzony plik "Project1.sfv". Klikając na ten plik dwukrotnie lewym klawiszem myszy system Windows zaproponuje program, którym ma otwierać pliki z rozszerzeniem svf. Wybrałem systemowy notatnik jako program domyślny i zaznaczyłem checkboxa, aby za każdym razem "XP-ek" otwierał te pliki właśnie w notatniku. Po otwarciu tego pliku w notatniku ujrzałem napis: Project1.exe 5a691d69 Oba kody są identyczne. Oznacza to, że program na Amidze działa poprawnie! Ze względu na samodzielną kompilację kodu czytelnikowi może wyjść odmienna wartość sumy kontrolnej. Dzieje się tak dlatego, że mogą wystąpić różnice w wersji AmiDevCPP, której używał autor niniejszego artykułu, a dostępną obecnie i używaną przez czytelnika. Najważniejsze, aby wartość uzyskana za pomocą Total Commandera była identyczna z CRC32 używanym na Amidze. Pełny radości, iż udało mi się samodzielnie uzyskać nowe, potężne narzędzie testów, przystąpiłem do dzieła. Wyczyściłem zawartość spreparowanej uprzednio dyskietki i zgrałem na nią dysk1.dms z PC. Zawierał on kopię moich dokumentów z Amigi. Za pomocą Total Commandera sprawdziłem wartość kodu CRC32 dla pliku na dyskietce. Następnie włożyłem dyskietkę do Amigi i w shellu wydałem polecenie: CRC32 PC0:dysk1.dms Amiga na chwilę zamarła, po czym wypluła wartość odpowiadającą tej z PC. Pomyślałem - "no ładnie, wszystko idzie zgodnie z planem". Przerzuciłem więc wspomniany plik do RAM Disku. Ponownie wydałem polecenie CRC32 RAM:dysk1.dms Ku mojemu zaskoczeniu wartość kodu zmieniła się! "Tu cię mam" - pomyślałem. Usunąłem plik z RAM Disku. Sprawdziłem jeszcze raz na dyskietce - wyszło pozytywnie. Przekopiowałem ponownie do RAM. Wykonałem test i otrzymałem błędną wartość. Następnie przekopiowałem plik ponownie, nie usuwając poprzedniego, a zmieniając jedynie jego nazwę na dysk2.dms. Wykonałem test. Otrzymałem pozytywny wynik! Tym razem się udało, a poprzednim razem nie? To jednoznaczny dowód na to, że pewien obszar pamięci Fast nie pracuje tak, jak powinien i dochodzi do przekłamywania danych. Plik dysk2.dms nie został uszkodzony, ponieważ kolejna część pamięci jest już sprawna i w niej nie dochodzi do przekłamań. Powtórzyłem cały test jeszcze raz otrzymując identyczne efekty. To już nie dzieje się losowo ani przypadkowo. Za każdym razem rezultat jest taki sam. Udało się znaleźć winowajcę. Dla pewności zakupiłem na aukcji internetowej inną kostkę pamięci. Gdy dotarła zamontowałem i wykonałem testy. Tym razem ich rezultat był odmienny. Dostawałem zawsze poprawną wartość zarówno w pierwszym, jak i drugim przypadku. System przestał się restartować, komunikaty "Guru" przepadły. Od tej chwili jestem szczęśliwym posiadaczem A1200 z kartą turbo. Opisaną metodą można sprawdzać poprawne działanie nie tylko pamięci RAM, ale i odczytu plików z kart CF przez port PCMCIA, interfejsy FastATA, 4xEIDE, dane na płytach DVD/CD, transfer plików z HTTP/FTP na dysk za pomocą karty sieciowej LAN/WIFI, działanie pendrive na USB itp. To jej przewaga nad programami typu memtest. W następnym artykule postaram się opisać jak przystosować kod źródłowy CRC32, aby potrafił nie tylko wyświetlać wartość sumy kontrolnej, ale również automatycznie dokonywał porównania plików wyświetlając komunikat "true" lub "false" i generował rezultat do pliku "*.svf" który następnie sprawdzi Total Commander (istotne przy przenoszeniu i weryfikacji poprawności danych z Amigi na PC). Co to jest CRC? CRC to skrót od angielskiego "cyclic redundancy check" (cykliczny kod nadmiarowy). Jest to matematyczna suma kontrolna pozwalająca zweryfikować poprawność i spójność danych, na przykład po przeniesieniu ich na nośniku danych na inny komputer. Wartość CRC jest resztą z binarnego dzielenia ciągu danych przez dzielnik, zwany generatorem lub wielomianem CRC. Najczęściej stosuje się wielomiany o długości 17 lub 33 bitów, dające odpowiednio wyniki 16- (CRC-16) i 32-bitowe (CRC-32). Artykuł oryginalnie pojawił się w pierwszym numerze Polskiego Pisma Amigowego.

Stephen Fellner (September 2009)

20.09.2009 15:55

Thank you that you agreed to have this interview. In first words, could you please introduce yourself, tell us what you do in our society. I think you already know most of that :) Yes, you are right but this is some sort of cliche. I will promise that the whole rest will not be so casual (I hope) ;) My name is Stephen Fellner, and I develop software for AmigaOS 4, more specifically DvPlayer and WarpView. I'm also an AmigaOS4 betatester and developer, I did some work on Picasso96 and the ATI Radeon driver, among other things. Let's start with the latter. You did some work on Picasso96 and ATI Radeon driver. Does it mean you are no longer involved in development of this elements? No, I'm still involved, but I'm not the main developer of these components, I only do certain parts and fixes, which are useful for video playback. For example I implemented the triplebuffering for overlay with vsync, which is very important for smooth video playback, it overcomes those annoying "raster cuts" which made animated graphics on PCs look so bad compared to Amigas, where we always had double/triplebuffering and vsync (synchronisation of the animation to the vertical blanking period of monitors). I also added support for some new YUV overlay formats which allow faster playback. So far I have achieved about 10% speedup in video playback on Sam440 systems using the new YUV formats. I have made some other contributions to OS4 as well, but I mostly concentrate on things which are related to video playback. And this is because it is your area of interest, isn't it? Tell us something about it. When and why did you decide to start making video playback tools? Lack of similar programs or maybe an attempt to prove something to someone or to yourself? Well I have to say that computer graphics is one of my main interests. It wasn't until around '98 that I began to do software development on the Amiga. At that time I met Laszlo Torok, author of the AVid video player (later to be renamed MooVId), who introduced me to software development on Amiga. First I developed some rendering routines (chunky-to-planar, and the real-time HAM-based 'Storm' routine) which I sent to Laszlo to include them in MooVId. His player did a great job of playing AVI and Quicktime (MOV) files, but there was nothing that could play MPEG files at acceptable speeds. There were some players like AmiPeg based on open-source players with optimization but they were all too slow on the average Amigas at the time. So I set out to develop my own MPEG player which I developed from scratch in 100% assembly language. This was a huge technical challenge and a very time-consuming project, but it gave me a lot of experience in the end, and it gave the Amiga platform a truly fast MPEG player. Although to be honest it still wasn't as fast as I hoped it could be. So that's how I got started. For those who don't know, you are talking about RiVA - quite decent video player for classic Amigas (by the way, you may (or may not) remember I helped Polish folks to register this tool). I do remember :) What influence did development of RiVA have on your next project which was DvPlayer? Back in the old days a lot of people were asking for a PPC version of RiVA. This would have taken a very long time because everything was in 68k assembly language and rewriting all that in PPC would have taken years, and I didn't even have a PPC card. Also, I was not satisfied with the fact that RiVA had no GUI, and because of that fell short on what you'd expect from a modern video player, but it was very difficult and time-consuming to extend the program due to its tightly optimized assembly nature, I had to realise that it is a dead end. One day I was talking to Csaba Simon (Chip) who was porting this avcodec.library for a new version of MooVId. He told me how it could be used by players for decoding. MooVId was to be included in AmigaOS 4 at the time. So I wrote a simple example code which decodes some frames from an MPEG file and it was surprisingly easy. The codec supported MPEG2 as well (RiVA only supported MPEG1) which means it would be able to handle SVCD and VOB files, which are on DVD. This was all under WarpOS, since OS4 was not released at the time, in fact at the time I didn't think OS4 will materialize. Well, it finally did and what's more, DvPlayer was the one which was included into it and superceded MooVId. Was it planned? Were you expecting this? What happened to MooVId (after all it was included into the system in pre-release version)? DvPlayer was meant to complement MooVId. The plan was to have MooVId for AVI/MOV formats, and DvPlayer for MPEG files, VideoCD and DVD, and possibly other formats which MooVId doesn't support. Me and Laszlo (the author of MooVId) are good friends, so we didn't want to compete by supporting the same formats. Unfortunately Laszlo lost interest in the Amiga scene, and development of MooVId didn't go as originally planned, therefore the plans changed, as I saw a need to have a player with GUI on OS4 which supports other formats too apart from MPEG, so now DvPlayer supports AVI and WMV formats, and support for Quicktime (MOV) and perhaps FLV will probably come in the future. Do you consider MPlayer as a competitor to DvPlayer? Basically it offers pretty much the same as your program. It is also open-sourced and many consider this as an advantage. What is your point of view on this? MPlayer is certainly a competitor. However I consider DvPlayer much better from a user-friendliness and ease-of-use point of view, and I'm very happy that we also have MPlayer available as it allows me to play video formats which are currently not supported by DvPlayer (such as MOV and FLV). It also helped me in the development of DvPlayer, because when there were issues with certian video files, I could test those with mplayer and if they were also bad with it, I knew it was just a corrupted file, otherwise I knew that I had to look into why it's not playing correctly in DvPlayer and make it work. How long did it take for DvPlayer to become fully usable and reliable tool? Well, it took several years, because a few months after starting to work on it, my A4000 broke, and it took a long time to find someone who could fix it, IIRC it was finally fixed after 9 months. When I finally got it back, I could continue for another couple of months, I became an OS4 betatester at the time so I was also able to start exploiting the benefits of OS4, but then my PPC card started playing up and eventually it died completely. I got a lot of support from Hyperion, they offered to fix my PPC card at no charge and sent me one of the early microA1's to use until it's fixed. It turned out to be unfixable so I got to keep the microA1, which despite all the anti-Articia propaganda that was going on at the time, actually turned out to be the most reliable Amiga hardware I've ever had, so development of DvPlayer progressed very well after that. Have you achieved everything you wanted when developing DvPlayer or there is something which is out of your league or is simply impossible to achieve on Amiga? Well, it's difficult to say. I think I've achieved more than I originally planned. But as with all major developments, the world moves on, new standards become dominant, so there's not much point thinking about old plans, you have to keep up with technology. At the moment High-Definition video has become really widespread, and you would really want a computer to be able to handle those without issues. However even in the PC world, low-end machines are not good enough for the latest standards/codecs. h264 is used almost exclusively now but we would need either dual or quad core G5-class hardware to handle it, or if the CPU is not so powerful, a graphics card on a PCI-Express bus, which can handle h264 decoding. The next digital camera I'm going to buy can record movies at FullHD 1080p resolution and records in MOV (Quicktime) format, so I'll be wanting to implement that format in DvPlayer obviously (it's been planned for a long time), but without suitable hardware it won't be very useful for playing those kinds of resolutions. Let's move away from DvPlayer now and tell me something about WarpView. Why another picture viewer? What does your tool have and does not have any other? WarpView wasn't originally meant as a picture viewer. One day I was pondering how they make 3D engines and how they solve hardware limitations like texture size limitations (texture sizes must be a power of 2 and there's also a maximum limit, like 256 on Voodoo cards IIRC). So I worked out how to split up images into smaller textures and seamlessly blend the texture edges (that's the tricky part with bilinear interpolation). Once the proof-of-concept program worked, I realized that this allows me to zoom and rotate images in real time very smoothly with hardly any CPU usage. So I thought why not make an image viewer out of it, which makes use of these capabilities of the GPU. So that's where it all started. As far as I know, WarpView is the only application on AmigaOS which does this, and with the wipes it's all very impressive. Another important feature is the handling of Exif information which digital cameras embed into the image, I think that beside WarpView, only AmiPhoto handles that. However I'm very proud of the scaling and crop functionality. The 'Lanczos' scaling algorithm in WarpView is among the best quality algorithms available today, and to my knowledge no other application under AmigaOS has that, even ImageFX uses an old averaging method which preserves considerably less detail when scaling down. I spent a lot of time optimizing it and it came out really fast in the end. I've been gearing towards extending the image processing capabilities, because most people today have digital cameras and have the need to sort and touch up their photos (scale, crop, enhance, repair). There's now an Unsharp Mask filter which allows sharpening, and I've been doing a lot of research on noise-reduction algorithms, because image noise/grain is a big issue in digital photography. Are you generally satisfied with the sales volume of WarpView and DvPlayer? Is it hard to sell shareware products this day and age? The Amiga market is extremely tiny, therefore nobody who develops software for this platform has high expectations when it comes to sales, nobody is going to get rich developing software for this platform :) If I looked at the amount of time I've put into developing these apps and the number of registrations, it would obviously be a disappointing figure, but the few registrations that do come in help to keep me motivated, but positive feedback is worth much more, reading about people being satisfied and doing nice things with my software is, I have to say, the best part of it all and this is what makes it all worthwhile for me. Are you working on something new or you are planning to work? Could shed some light on it? I started looking at MiniGL as I planned to switch to that in WarpView instead of Warp3D, and in the process I made a simple game engine just for fun, but I didn't have the time yet to make anything serious out of that. In the meantime we now have compositing which will be much better to use in WarpView than MiniGL. I've also been thinking about video editing software, but that would probably require a team effort, rather than a single person, and I'd rather get a few more things finished in my current projects (such as MOV support in DvPlayer) before I start on anything big like that. In your opinion what is the future of AmigaOS and AmigaOS like systems? In my opinion AmigaOS and similar systems should exploit the "low resource requirements" feature, which becomes a huge advantage on portable devices where processing power and battery life are limited. Are we going to be surprised with something? That depends on your expectations :) But I think there will be one or two things which will be a big surprise for most people. What are your wishes concerning Amiga and AmigaOS? I would like to see more developers join us so that I can retire :) Seriously though, we do need more people who develop or port things and I'm glad to see quite a few people giving it a try on our platform. I think AmigaOS is the best platform for hobby developers, simply because on this platform even simple applications are very welcome as opposed to the mainframe OS'es where there are hundreds of different applications available for doing the same thing. Here programmers can really make a difference even with a moderate amount effort. Stephen, it was great pleasure to have this interview with you. Thank you for answering all my questions. I wish you all the best with your projects. Would you like to say something which will nicely wrap everything up? Thank you, it's been a privilege likewise. It's good to have people like you from the old days still with us. This decade has been a very difficult time for the Amiga platform and it's a miracle that despite all the unfortunate events that happened the platform still survived, developments continue in all areas (hardware, OS, software) and the user base is steadily growing again. I'd like to thank everyone who worked hard to keep this platform alive and also those who have not lost faith and hope in the darkest times and stayed with us.

Stephen Fellner (Wrzesień 2009)

20.09.2009 15:54

Dziękuję, że zgodziłeś się na tę rozmowę. Na początek, czy mógłbyś się przedstawić i powiedzieć czym zajmujesz się w naszej społeczności? Wydaje mi się, że odpowiedź na to już znasz :) Masz rację, ale to jest pewnego rodzaju rutynowe pytanie. Obiecuję, że reszta nie będzie już taka stereotypowa (mam przynajmniej nadzieję) ;) Nazywam się Stephen Fellner i tworzę programy dla AmigaOS 4. Konkretnie są to DvPlayer i WarpView. Jestem również betatesterem i deweloperem AmigaOS 4. Pracowałem m.in. nad Picasso96 oraz sterownikami dla kart ATI Radeon. Zacznijmy od tego ostatniego elementu. Pracowałeś, tzn. że już nie jesteś zaangażowany w rozwój tych elementów? Nie, nadal się nimi zajmuję, lecz nie jestem głównym programistą tych komponentów. Wykonuję jedynie konkretne zadania oraz poprawki związane z odtwarzaniem wideo. Dla przykładu, zaimplementowałem potrójne buforowanie dla overlaya z synchronizacją pionową, co jest bardzo ważne dla płynnego odtwarzania obrazu. Pozwala to obejść te drażniące tzw. "raster cuts", które sprawiają, że animowana grafika na PC wygląda tak fatalnie w porównaniu z amigową. W końcu my zawsze mieliśmy podwójne/potrójne buforowanie i synchronizację pionową (synchronizacja animacji do wygaszania pionowego monitora). Dodałem również obsługę kilku nowych modeli barw YUV, co zapewnia szybsze odtwarzanie. Jak dotąd, udało mi się uzyskać około dziesięcioprocentowe przyspieszenie w odtwarzaniu wideo na Sam440, przy wykorzystaniu modelu YUV. Przyczyniłem się również do innych programów dla AmigaOS 4, lecz głównie skupiam się na rzeczach związanych z odtwarzaniem obrazu. Dzieje się tak głównie dlatego, że jest to obszar Twoich zainteresowań, prawda? Powiedz nam więcej o tym. Kiedy i w jakich okolicznościach zdecydowałeś się tworzyć narzędzia do odtwarzania plików wideo? Czy było to spowodowane brakiem podobnych programów, a może próbowałeś coś komuś lub sobie samemu udowodnić? Muszę przyznać, że grafika komputerowa to jedno z moich głównych zainteresowań. Programy dla Amigi zacząłem pisać w roku 1998. Wówczas poznałem Laszlo Toroka, autora programu do odtwarzania plików wideo AVid (później przemianowanego na MooVId), który wprowadził mnie w to wszystko. Na początku napisałem kilka procedur renderowania obrazu (chunky-to-planar oraz "Storm" - procedurę renderowania obrazu opartego na trybie HAM w czasie rzeczywistym), które wysłałem do Laszlo, aby dołączył je do MooVida. Jego program spisywał się doskonale odtwarzając pliki w formatach AVI i Quicktime (MOV), ale nie istniało nic, co radziłoby sobie z odtwarzaniem z akceptowalną prędkością plików MPEG. Były jakieś odtwarzacze typu AmiPeg oparte na otwartych źródłach innych programów, lecz były zbyt powolne na średnio rozbudowanych Amigach. Przystąpiłem więc do pracy nad własnym programem, który napisałem w całości w asemblerze. To było spore techniczne wyzwanie i jednocześnie bardzo czasochłonne zajęcie. Nauczyłem się jednak wiele, a Amiga otrzymała naprawdę szybki program do odtwarzania plików MPEG. Szczerze mówiąc jednak, liczyłem na to, że będzie szybszy. Tak to się właśnie zaczęło. Dla tych co nie wiedzą, mówisz o programie RiVA - całkiem niezły program do odtwarzania plików MPEG dla Amig klasycznych (może pamiętasz (lub nie), że pomagałem rejestrować ten program u Ciebie osobom z Polski). Pamiętam :) Jaki wpływ miał rozwój programu RiVA na Twój kolejny projekt, którym był DvPlayer? Za czasów RiVY wiele osób pytało o program w wersji dla procesorów PPC. Stworzenie czegoś takiego zajęłoby mi mnóstwo czasu, gdyż całość napisana została w asemblerze 68k. Przepisanie tego na PPC zajęłoby lata, a poza tym nie miałem wówczas karty z procesorem PPC. Poza tym nie byłem zadowolony z faktu, że RiVA nie posiadała GUI i między innymi z tego powodu nie spełniała do końca oczekiwań, jeśli chodzi o nowoczesny program do odtwarzania filmów. Z uwagi na bardzo mocno zoptymalizowaną budowę programu, rozszerzenie go o GUI było rzeczą trudną i czasochłonną. Zdałem sobie sprawę, że zabrnąłem w ślepą uliczkę. Pewnego dnia rozmawiałem z Csaba Simonem (Chip), który pracował nad portem biblioteki avcodec na potrzeby nowej wersji MooVIda. Powiedział mi jak można ją wykorzystać w odtwarzaczach. MooVId miał być wówczas częścią AmigaOS 4. Napisałem więc krótki przykładowy kod, który dekodował kilka klatek z pliku MPEG. Okazało się to zaskakująco proste. Kodek obsługiwał także MPEG2 (RiVA potrafiła odtwarzać jedynie MPEG1), co oznaczało, że poradziłby sobie z SVCD i plikami VOB znajdującymi się na płytach DVD. To wszystko było jeszcze pod WarpOS - nie wydano wtedy jeszcze AmigaOS 4 - tak po prawdzie, to nie sądziłem wówczas, że kiedykolwiek ujrzy on światło dzienne. W końcu się to udało i co więcej, DvPlayer był tym programem, który był do niego dołączony oraz wyparł MooVIda. Czy było to zamierzone? Spodziewałeś się tego? Co stało się z MooVIdem (bądź co bądź, był dołączony do systemu w wersji pre-release)? DvPlayer miał uzupełniać MooVIda. Plan był taki, aby MooVId służył do plików AVI/MOV, a DvPlayer do MPEG, VideoCD i DVD oraz być może też innych, z którymi MooVId by sobie nie radził. Jesteśmy z Laszlo (autorem MooVIda) dobrymi przyjaciółmi i nie chcieliśmy ze sobą rywalizować, pracując nad obsługą tych samych formatów. Niestety Laszlo przestał interesować się Amigą, a w związku z tym rozwój MooVIda nie potoczył się tak, jak oryginalnie planowano. Dostrzegłem potrzebę posiadania programu do odtwarzania filmów, który posiadałby GUI oraz radziłby sobie z formatami, których obsługi początkowo nie planowałem. Tak więc DvPlayer obsługuje AVI i WMV, a Quicktime (MOV) i być może FLV zamierzam dodać w przyszłości. Czy traktujesz MPlayera jako konkurencję dla DvPlayera? Zasadniczo oferuje on to samo, co Twój program. Jest oparty na otwartym kodzie źródłowym, co wielu uważa za zaletę. Jaki jest Twój punkt widzenia w tej kwestii? MPlayer z całą pewnością stanowi konkurencję. Niemniej jednak uważam, że DvPlayer jest znacznie wygodniejszy i prostszy w obsłudze dla użytkownika. Nie zmienia to jednak faktu, że bardzo się cieszę, iż mamy MPlayera, który umożliwia odtwarzanie formatów, z którymi DvPlayer sobie nie radzi (np. MOV i FLV). Program ten również pomógł mi w pracy nad DvPlayerem. Mając problemy z jakimiś plikami wideo, mogłem je testować właśnie na MPlayerze, aby sprawdzić czy on radził sobie z nimi podobnie. W ten sposób mogłem sprawdzić czy problemem jest uszkodzony plik, czy też musiałem skupić się na odnalezieniu błędu w DvPlayerze. Ile czasu upłynęło, zanim DvPlayer stał się w pełni użytecznym, niezawodnym w działaniu programem? Kilka lat z przerwą. Po paru miesiącach od rozpoczęcia prac, zepsuła się moja A4000. Zajęło mi trochę czasu odszukanie osoby, która potrafiłaby ją naprawić. Jeśli dobrze pamiętam, trwało to łącznie dziewięć miesięcy. Gdy dostałem komputer z powrotem, przez kolejnych kilka miesięcy mogłem pracować dalej. Wtedy też nadszedł moment, gdy zostałem betatesterem AmigaOS 4 i mogłem zacząć wykorzystywać jego możliwości. Niestety, sprzęt znowu dał o sobie znać - padła moja karta PPC. Duże wsparcie otrzymałem od Hyperion-Entertainment. Zaoferowali się, że naprawią moją kartę za darmo i wyślą wczesną wersję MicroA1, z której będę mógł w tym czasie korzystać. Okazało się, że karty nie można wskrzesić, więc pozwolono mi zatrzymać MicroA1, która wbrew całej propagandzie związanej z układem Articia, którą wówczas przerabialiśmy, okazała się najbardziej niezawodnym amigowym sprzętem jaki kiedykolwiek miałem. Od tego momentu rozwój DvPlayera postępował bez żadnych problemów. Czy pracując nad DvPlayerem osiągnąłeś wszystko co chciałeś, czy też jest coś, co po prosto wykracza poza Twoje możliwości lub jest nieosiągalne na amigowym sprzęcie? Trudno powiedzieć. Sądzę, że osiągnąłem więcej niż pierwotnie zakładałem. Ale jak to bywa ze wszystkimi większymi projektami, świat idzie do przodu, zaczynają obowiązywać nowe standardy, tak więc oglądanie się za siebie i przeglądanie starych założeń nie ma sensu. Trzeba podążać za postępem technologicznym. Obecnie coraz popularniejsze jest High-Definition i na pewno chciałoby się, aby komputer sobie z tym radził bez żadnych problemów. Niemniej jednak, nawet w świecie PC, maszyny low-end nie są wystarczające, aby cieszyć się najnowszymi standardami/kodekami. Najpopularniejszy obecnie kodek h264 wymaga przynajmniej procesora G5 Dual lub Quad Core, aby zapewnić komfort oglądania. W przypadku słabszego procesora niezbędna jest karta graficzna na złączu PCI-Express z funkcją dekodowania h264. Aparat cyfrowy, który zamierzam kupić, nagrywa filmy w rozdzielczości FullHD 1080p w formacie MOV (Quicktime). Będę więc dążył do tego, aby DvPlayer go obsługiwał (planuję to od dłuższego czasu), lecz bez odpowiedniego sprzętu, nie będzie zbytniego pożytku z odtwarzania filmów w takiej rozdzielczości. Odsuńmy się nieco od DvPlayera i porozmawiajmy o WarpView. Po co kolejna przeglądarka obrazków? Co posiada Twój program, czego nie mają inne? Pierwotnie WarpView nie miał być przeglądarką obrazków. Kiedyś zgłębiałem tajniki tworzenia silników 3D i w jaki sposób radzą sobie z ograniczeniami sprzętu w przypadku rozmiarów tekstur (rozmiary tekstury muszą być wartością będącą potęgą dwójki, a ponadto mamy górny limit, taki jak na przykład 256 na kartach Voodoo - z tego co pamiętam). Wymyśliłem w jaki sposób podzielić obrazy na mniejsze tekstury i bez widocznego miejsca styku połączyć je ze sobą krawędziami (sztuczka polega na wykorzystaniu bilinearnej interpolacji). Gdy przykładowy program zadziałał prawidłowo, zdałem sobie sprawę, że mogę w ten sposób skalować i obracać obrazy w czasie rzeczywistym. Wszystko to odbywało się bardzo płynnie, praktycznie bez obciążenia procesora. Pomyślałem więc, dlaczego nie wykorzystać tego do zrobienia przeglądarki obrazków, która robiłaby użytek z procesora karty graficznej. No i tak się to zaczęło. Z tego co wiem, WarpView jest jedyną aplikacją dla AmigaOS, która potrafi coś takiego. Ważną cechą programu jest również obsługa informacji EXIF zaszywanych przez aparaty cyfrowe w zdjęciach. Zdaje się, że poza WarpView, jedynie AmiPhoto to obsługuje. Jestem również bardzo dumny z funkcji zmiany wielkości oraz przycinania obrazów. Algorytm skalowania "Lanczos" zaimplementowany w WarpView jest jednym z najlepszych obecnie dostępnych i chyba nie jest wykorzystywany przez żaden inny program dla AmigaOS. Nawet ImageFX korzysta ze starej metody uśredniania, która traci więcej szczegółów podczas zmniejszania. Spędziłem dużo czasu na optymalizacji tego elementu, a w efekcie otrzymałem coś bardzo szybkiego w działaniu. Skłaniam się ku rozszerzeniu programu o funkcje przetwarzania obrazu. Większość osób posiada dzisiaj aparat cyfrowy i chciałaby poprawić nieco swoje zdjęcia (zmniejszyć, przyciąć, wyostrzyć). Już istnieje wbudowany w program filtr "Unsharp Mask", który wyostrza obraz. Sporo czasu spędziłem na analizowaniu tematu algorytmów redukcji szumu (ziarnistości), gdyż w świecie fotografii cyfrowej jest to powszechnie występujący problem. Czy zasadniczo jesteś zadowolony z poziomu sprzedaży WarpView i DvPlayera? Czy obecnie trudno jest sprzedawać programy na licencji shareware? Amigowy rynek jest niezmiernie mały, tak więc nikt, kto rozwija jakieś oprogramowanie na tę platformę, nie ma wysokich oczekiwań dotyczących sprzedaży. Z pewnością na tym rynku nikt się nie wzbogaci :). Jeśli spojrzę przez pryzmat czasu, jaki poświęciłem na rozwój swoich programów i porównam to z liczbą rejestracji, wówczas można się rozczarować. Te kilka okazjonalnych klientów jednak pomaga mnie zmotywować, choć większe znaczenie ma pozytywny wydźwięk i opinie. Przyjemnie jest poczytać o ludziach zadowolonych i robiących ciekawe rzeczy moimi programami. Muszę przyznać, że właściwie to właśnie to odgrywa dla mnie największą rolę i sprawia, że warto. Czy pracujesz nad czymś nowym lub masz taki zamiar? Czy mógłbyś podzielić się nieco informacjami z tym związanymi? Przyglądałem się MiniGL, gdyż planowałem odejść od Warp3D i zrobić z tego użytek w WarpView. W efekcie powstał, tak dla zabawy, prosty silnik gry. Nie miałem jednak jeszcze czasu, aby zamienić go w coś poważnego. Obecnie w systemie mamy kompozycję obrazu i zdaje się, że ta funkcja będzie znacznie bardziej nadawała się do wykorzystania w WarpView niż MiniGL. Zastanawiam się również nad oprogramowaniem do obróbki filmów, lecz to nie jest zadanie dla jednej osoby i prawdopodobnie będzie wymagało pracy jakiegoś zespołu. Poza tym chcę najpierw ukończyć kilka rozpoczętych projektów (np. obsługa plików MOV w DvPlayer) zanim zacznę robić coś tak dużego. Twoim zdaniem, jaka przyszłość czeka AmigaOS i systemy pochodne? Moim zdaniem AmigaOS i jemu podobne systemy powinny korzystać ze swoich "niskozasobowych wymagań", które stają się ogromną zaletą na urządzeniach przenośnych, gdzie moc oraz żywotność baterii są ograniczone. Czy zostaniemy czymś zaskoczeni? To zależy od oczekiwań. :) Sądzę jednak, że zdarzy się kilka rzeczy, które dla wielu osób będą wielką niespodzianką. Jakie są Twoje życzenia dotyczące Amigi i AmigaOS? Chciałbym, aby w naszej społeczności pojawiło się więcej deweloperów, abym mógł odejść na emeryturę. :) Poważnie jednak mówiąc, potrzeba nam więcej ludzi do pisania oprogramowania lub tworzenia portów. Cieszę się, że kilka osób próbuje tego dokonać. Sądzę, że AmigaOS to najlepsza platforma dla deweloperów-hobbystów. Z prostej przyczyny - na tej platformie nawet proste programy są bardzo mile widziane, w przeciwieństwie do systemów wiodących, gdzie są setki różnych aplikacji robiących to samo. Tutaj programiści mogą naprawdę wiele zdziałać, nawet niskim nakładem pracy. Stephen, było mi naprawdę miło móc z Tobą porozmawiać. Dziękuję za odpowiedzi na wszystkie moje pytania. Życzę Ci powodzenia w pracach nad Twoimi projektami. Czy na zakończenie chciałbyś coś jeszcze powiedzieć, co ładnie by wszystko podsumowało? Dziękuję. Mnie również było miło. To dobrze, że tacy ludzie jak Ty, których pamięta się ze starych czasów, nadal są z nami. Ostatnie dziesięć lat było trudnym okresem dla Amigi i to w zasadzie cud, że pomimo tylu nieszczęśliwych wydarzeń, udało się tej platformie przetrwać. Rozwój w każdym obszarze (sprzęt, system, oprogramowanie) nadal trwa, a grupa użytkownikom powolutku znowu rośnie. Chciałbym podziękować wszystkim, którzy ciężko pracowali na to, aby Amiga nadal żyła oraz tym, którzy nie stracili wiary i nadziei w najgorszym okresie i nadal są z nami. Korekta: Konrad Czuba i Aleksander Chyliński

Chris Young (November 2008)

21.11.2008 14:07

Could you introduce yourself and briefly describe what you do? My name is Chris Young, I live in a fairly quiet corner of Bedfordshire in England and am unofficially "Joint Software Manager" of Unsatisfactory Software, whatever that means (it's not my day job). I'm responsible for Facts, Wet, the 7-Zip and (partially) RAR3 plug-ins for XAD, various other things which aren't quite as popular, and of course the OS4 port of NetSurf. Which Amigas do you use? An AmigaOne G4-XE, 800 MHz, 512 MB RAM with AmigaOS 4.1. It's one of the ones with a 933 MHz G4 but I daren't clock it up to that! I also have an A1200 with AmigaOS 3.5 but I can't remember the last time I switched it on. Could you describe circumstances that made you interested in Amiga? My Dad bought one, I hijacked it mostly to play "Lemmings", eventually got my own and it spiralled out of control from there. What is NetSurf? NetSurf is a fast, open source, CSS capable web browser written originally for RISC OS (an operating system by Acorn for their Archimedes/RiscPC computers which were popular in schools in the UK - subsequent events unfortunately mirror the Amiga situation quite closely) How long have you been secretly working on it? Possibly one of the world's worst-kept secrets! I started working on it back in July I think. Why have you chosen NetSurf? What is so special about it that you have decided to focus on it? I ported an emulator called ArcEm - see this link - a couple of years ago, and had NetSurf for RISC OS running on that (albeit rather slowly). It then cropped up again in a thread on amigaworld.net - the usual "why doesn't somebody port this?" affair. I didn't realise quite how portable NetSurf was until this thread pointed it out, despite having used it and briefly checked out the source in the past. Edgar Schwan compiled it for his OS4 X11 environment very quickly, so I thought I'd take a look at it. I was expecting the project to end up on my increasing pile of software I'd started writing/porting and then given up with, but the support from the developers mailing list was very good and it didn't take very long to get it to compile, or to add a very basic GUI to get a display out of it. What other function are you planning to add to NetSurf port in addition to what`s already in original version? The most recent beta I've uploaded is fairly complete in terms of features. A text search is quite high priority, and opening local files is obviously useful. I have a context menu on my build now. The options GUI needs writing. There are a lot of bugs and bad/temporary implementations of features which need fixing (such as frames opening in individual windows). What way of evolution of do you foresee for Amiga version of your port? Once it is feature-complete and bug-free, it will mostly inherit features implemented in the core code. Will it support/work with Flash? Not at the moment. With Flash going open source and Flash libraries already available, I'm sure it will be added in the future - however it's something which needs to be added to the core code, so probably won't be me implementing it. There is a group of people working on NetSurf. Why haven`t you decided to support author of OWB or to develop something more advanced? OWB is a great browser, it certainly has the best rendering engine of any of the OS4 compatible Amiga browsers. However, it was designed for handhelds so anything which needs to be added needs to be written from scratch. The rendering side is complete but slow, and startup of OWB takes several seconds. NetSurf however has a custom-made rendering engine which is designed to be very fast (RISC OS coders are like Amiga coders in that regard), but is still in development so missing some features. It is designed for desktop platforms, so features like bookmarks (hotlist), downloads etc are already implemented and just need a small amount of AmigaOS specific support code for them to be used. This has enabled me to very quickly get it up to some sort of minimum browser standard. The situation with web browsers for AmigaOS 4.x is amusing. There was none and suddenly there 10 of them. Instead of working on many browser the developers should unite and make one good product. Don`t you agree? Yes, to an extent. However a bit of competition in the browser market helps spur the development and we end up with stronger browsers in the end and some more choice. Also I think we'd all be standing on each other's toes, and have to use the AWeb core as that's the only one we have half a chance of knowing how it works :-) Currently there are three OS4 native browsers and they all have different strengths - AWeb has the most complete UI and featureset, is fast and 100% Amiga native but doesn't support CSS. OWB is the other end, has the best rendering engine with CSS but is slow and the UI is minimal. NetSurf falls somewhere in the middle - the UI has most of the basic features that are expected, the rendering engine is fast and supports CSS but is incomplete in places (and there is no support for JavaScript yet). Are there any chances for AmigaOS 3.X, MorphOS or AROS versions of NetSurf? I originally started out writing the NetSurf Amiga specific code in such a way that it would work on OS3.x, if somebody had the time to port all the dependecies. That quickly went out the window when features I needed were either only available on OS4 or there was a better way of doing them on OS4. I still think it can be done, but it would require a lot more work. Certainly the speed of NetSurf is comparable to AWeb and should be ideal for the sort of hardware OS3 is running on. I have had contact from people interested in helping port to OS3 but nothing has come of it yet. MorphOS and AROS have the additional problem of using MUI as their native UI. Somebody did contact me regarding porting NetSurf to AROS and I'll help out where I can, but if you're using MUI (or Zune or whatever) then most of the work I've done needs to be repeated again for MUI. MorphOS users may be better off sticking with Sputnik unless somebody particulary wants to put the effort in. Are you planning to develop WET program further? Yes, but it has taken a back seat. I intend to update the HTTP code to that in http-handler (Wet's HTTP code doesn't support HTTP/1.1 properly), and I have plans for an ARexx-based plug-in system so Wet can be expanded to get data from other sources. Let's imagine you successfully finished NetSurf port. You are happy with the result. What's going to be next? Which software you would like to put your interest in? Or maybe you already have one? Something to be ported or written from scratch? I can't imagine a time when people are no longer bugging me for features! I'd probably implement the answer to previous question, and then see what comes along. I don't tend to plan what I'm going to do - something will spark me off and it'll be "I wonder if...", and then I won't get any sleep for the next three days as I start working on it. Could you shed some light on the projects which are on the pile of the software you weren't able to finish? What are they? Which of them are rather close to be finished? Which of them you would like to be finished? Heh. A quick browse through my old Projects directory reveals: DTZ - a joint collaboration with Russell Glover and Juha Niemimaki to bring little-known secret Saturn game Death Tank Zwei to OS4. It's a reasonable tech demo: you can move and fire pixels to take chunks out of a randomly-generated landscape. Triffic - a little commodity which was going to do for travel news what Wet did for weather. At the moment it will happily drag reports of the latest jams down from the BBC's website. There are others, such as the AmigaInput driver for parallel-port connected CD32 pads, a MailNotifyDocky, TuneNet XMP plugin, the long-awaited FactsPPC - which will never see the light of day, although an OS4 compile of the old version might - and various intentions of porting things (even an AmigaGuide reader, although I forget why). I have little patience for ports - if they don't compile straight away, unless it's something I really want or need I'll give up quite quickly. I also hate lazy ports, I try to add some element of "Amiga-ness", even if it is only replacing some dodgy SDL-rendered custom file requesters with ASL equivalents. Overall though, I prefer to work with my own code. Some things which start out with the intention of being an "enhanced port" of something, and end up being written from scratch when I can't decipher the original code or it isn't flexible enough for my needs. Most of my projects get released in one form or another, if they sit around for long enough and are in some way useable, I'll upload with the usual intentions of updating them later - or include the source and refuse to have any more involvement (which doesn't seem to deter people from reporting bugs - I swear I get more questions about programs I have no further interest in). What do you think about whole situation related to AmigaOS 4.0 and Hyperion-Entertainment? Hyperion are doing a great job on OS4.x, it's a shame they have been hampered by legal issues. Apart from Amiga, what are you interested in? What are your other hobbies? I'd like to say something exotic, but it's reading, sleeping, eating and going to various comedy events. Oh, and my Wii. 17. What are your best and the worse experiences related with Amiga? I had my car door taken off by a bus as I attempted to secure an AmigaOne. That was a low point. There were many more good experiences but after the downfall of Commodore amount mostly to short-lived optimism. Do you have any final words you would like to say to our readers? If there's a piece of Amiga software you use regulary, tell the person who created it how much you like it. Also, buy a Sam440 and OS4.1. Thank you very much for your time answering all these questions. Good luck in your present and future projects.

Chris Young (listopad 2008)

21.11.2008 08:47

Czy mógłbyś się przedstawić i krótko opowiedzieć czym się zajmujesz? Nazywam się Chris Young. Mieszkam w dosyć spokojnym miejscu w Wielkiej Brytanii, w miejscowości Bedfordshire. Nieoficjalnie pełnię funkcję "Joint Software Manager" w grupie programistycznej Unsatisfactory Software, cokolwiek ta nazwa znaczy (tak na marginesie, to nie jest to, z czego się utrzymuję). Popełniłem kilka programów takich jak Facts, Wet oraz wtyczki 7-Zip i (częściowo) RAR3 dla pakietu XAD. Mam na swoim koncie kilka mniej popularnych narzędzi, ale także moje najmłodsze dziecko - port NetSurf dla AmigaOS 4.x. Jakich Amig używasz? AmigaOne G4-XE, 800 MHz, 512 MB RAM z AmigaOS 4.1. To jedna z tych nielicznych, które mają możliwość pracować z taktowaniem 933 MHz, lecz nie odważyłbym się tak jej podkręcić! Mam również A1200 z AmigaOS 3.5, lecz nie pamiętam kiedy ją ostatni raz włączałem. W jakich okolicznościach zainteresowałeś się Amigą? Mój tata kupił jeden egzemplarz. W chwili gdy stał nie używany, przejmowałem go głównie, aby pograć w "Lemmings". Wkrótce nabyłem swój własny i tak nakręciła się ta machina. Czym jest NetSurf? NetSurf to szybka, oparta na kodzie open source, przeglądarka internetowa obsługująca CSS, która pierwotnie powstała dla systemu operacyjnego RISC (wykorzystywany w komputerach Archimedes/RiscPC autorstwa firmy Acorn, które były popularne w szkołach w Wielkiej Brytanii - historia tego systemu i komputera bardzo przypominają realia Amigi). Pracowałeś nad portem w tajemnicy. Od jak dawna? To chyba jedna z najsłabiej utrzymanych tajemnic świata! Prace rozpocząłem w lipcu. Dlaczego NetSurf? Co jest w nim takiego nadzwyczajnego, co sprawiło, że postanowiłeś się nim zająć? Kilka lat temu przygotowałem port emulatora o nazwie "ArcEm" (więcej) i działał na nim NetSurf pod kontrolą RISC OS (raczej wolno, ale działał). Następnie ktoś w jednym z wielu podobnych wątków na forum AmigaWorld.net zapytał "dlaczego ktoś tego nie przeportuje". Do tego momentu, pomimo tego, że programu używałem i nawet kiedyś przyglądałem się jego źródłom, nie zdawałem sobie nawet sprawy jak łatwo jest przenosić kod NetSurf pomiędzy różnymi platformami. Edgar Schwan bardzo szybko przygotował kompilację dla AmigaOS 4.x pod środowisko X11, więc pomyślałem, że przyjrzę się temu. Spodziewałem się, że projekt skończy tak jak wiele innych - na stale powiększającej się górze oprogramowania, które zacząłem pisać/portować, aby wkrótce porzucić prace. Niemniej uzyskana pomoc z listy dyskusyjnej dla deweloperów była bardzo pomocna i nie zajęło zbyt wiele czasu pomyślne skompilowanie programu oraz dodanie bardzo prostego GUI do jego obsługi. Jakie dodatkowe funkcje planujesz dodać do portu NetSurf, czego na próżno szukać w oryginale? Ostatnia wersja beta zawiera w zasadzie wszystko, czego można się spodziewać. Wysoki priorytet postawiłem na wyszukiwanie tekstu oraz na bardzo użyteczną funkcję wczytywania plików z dysków lokalnych. W wersji, którą obecnie skompilowałem dodane zostało menu kontekstowe. Moduł ustawień również wymaga sporo pracy (obecnie ustawienie zmienia się modyfikując plik tekstowy). Poza tym jest mnóstwo błędów i rozwiązań tymczasowych, które muszą być poprawione (np. ramki otwierają się w osobnych oknach). Jak według Ciebie, amigowa wersja NetSurf wyewoluuje ponad oryginał? Gdy już wszystkie zakładane funkcje będą działały prawidłowo i bezbłędnie, program raczej będzie podążał zgodnie ze ścieżką rozwoju oryginalnego kodu. Jak przedstawia się obsługa Flasha? Już działa, będzie działać? W tej chwili nie działa. Wraz z tym jak Flash przeszedł na open source, a jego biblioteki są już dostępne, jestem pewien, że w przyszłości obsługa tego elementu będzie dodana. Niemniej jednak, jest to funkcjonalność, która będzie musiała być dodana na poziomie oryginalnego kodu, tak więc nie ja się będę tym zajmował. Nad NetSurf pracuje pewna grupa osób. Dlaczego nie zdecydowaliście się raczej wesprzeć autora OWB lub spróbować sił z nieco bardziej zaawansowanym projektem? OWB to wspaniała przeglądarka i z całą pewnością posiada najlepszy silnik wyświetlania stron jaki mógł się trafić amigowej przeglądarce. Niemniej, program ten zaprojektowany został z myślą o urządzeniach przenośnych i dodanie jakiegokolwiek elementu wiąże się tak naprawdę z napisaniem go od początku. Silnik wyświetlania jest ukończony, lecz wolny. Samo uruchomienie OWB trwa kilka sekund. NetSurf posiada indywidualny silnik wyświetlania zaprojektowany tak, aby był bardzo szybki (programiści RISC OS są bardzo podobni do programistów AmigaOS z punktu widzenia optymalizacji kodu), lecz z punktu widzenia rozwoju tego projektu, nadal trochę mu brakuje. Zaprojektowany został z myślą o komputerach desktop, tak więc takie elementy jak książka adresów URL, menadżer pobierania plików itd. są już zaimplementowane i wymagają jedynie niewielkich dostosowań do realiów AmigaOS. W ten sposób udało mi się bardzo szybko dostosować go do stanu, w który przypomina przeglądarkę zapewniającą minimalny standard. Sytuacja związana z przeglądarkami dla AmigaOS 4.x jest dosyć zabawna. Długo nie było nic, lecz nagle mamy ich przysłowiowe "dziesięć". Czy nie zgodzisz się ze mną, że zamiast pracować nad wieloma, programiści powinni złączyć siły i stworzyć jeden, ale dobry produkt? Tak, ale tylko do pewnego stopnia. Jak wiadomo, odrobina konkurencji wśród przeglądarek internetowych tylko przyspiesza ich rozwój i prawdopodobnie wkrótce będziemy mieć do wyboru kilka naprawdę dobrych programów. Poza tym wydaje mi się, że deptalibyśmy sobie po piętach, gdyż wszyscy grzebalibyśmy w kodzie AWeba, jako że jest to jedyny, o którym chociaż w połowie wiemy jak działa :-) Obecnie dla AmigaOS 4.x są trzy natywne przeglądarki i każda z nich posiada inne zalety. AWeb posiada najlepszy, bogaty w wiele funkcji interfejs użytkownika. Program jest szybki, w 100% amigowy, lecz nie obsługuje CSS. OWB z kolei, posiada najlepszy silnik wyświetlania z obsługą CSS, lecz jest wolny, a jego interfejs użytkownika bardzo prosty, minimalistyczny. NetSurf z kolei wypada gdzieś po środku - interfejs użytkownika zapewnia podstawową funkcjonalność w zakresie tego, czego może potrzebować użytkownik. Silnik wyświetlania jest szybki i obsługuje CSS. Niestety nie jest kompletny w kilku miejscach (np. na chwilę obecną brak obsługi JavaScript). Czy są szanse na to, aby NetSurf pojawił się dla AmigaOS 3.X, MorphOS-a lub AROS-a? Pierwotnie rozpocząłem prace nad NetSurf pisząc go w taki sposób, aby działał pod AmigaOS 3.x - to tak na wypadek, gdyby ktoś chciał go przeportować. Wkrótce jednak okazało się to mało praktyczne, gdyż wiele elementów, które chciałem zaimplementować dostępnych jest wyłącznie pod AmigaOS 4.x lub sposób ich rozwiązania był o wiele lepszy pod AmigaOS 4.x. Nie twierdzę jednak, że wersja dla AmigaOS 3.x nie jest możliwa - wymaga jednak dużo pracy. Prędkość działania NetSurf jest porównywalna z AWebem i powinna się sprawdzić pod klasycznym sprzętem na jakim działa AmigaOS 3.x. Kilka osób interesowało się już portem dla tego systemu, lecz póki co nic z tego jeszcze nie wyszło. MorphOS i AROS mają problem z przywiązaniem do MUI jako ich natywnego interfejsu użytkownika. Kontaktowano się już ze mną w sprawie portu dla AROS-a, zaoferowałem swoją pomoc, lecz trzeba mieć świadomość, że korzystając z MUI (lub Zune) większość pracy z tym związanej trzeba wykonać samemu. Dla użytkowników MorphOS-a będzie lepiej, jeżeli będą trzymać się Sputnika. No chyba, że ktoś bardzo chce spróbować swoich sił. Masz w planach dalszy rozwój programu Wet? Tak, lecz na chwilę obecną odłożyłem go nieco. Zamierzam uaktualnić nieco kod odpowiedzialny za łączność z serwerami HTTP, aby był zgodny z http-handler (kod HTTP zaimplementowany w Wet nie obsługuje poprawnie HTTP/1.1). Chciałbym także stworzyć system wtyczek oparty na ARexx, aby Wet mógł pobierać dane z innych źródeł. Wyobraźmy sobie, że pomyślnie ukończyłeś port NetSurf. Jesteś zadowolony z rezultatu. Co będzie następne? Jakim programem chciałbyś się zainteresować? A może już taki jest? Coś co będziesz portował, czy pisał od podstaw? Nie potrafię wyobrazić sobie sytuacji, że ludzie nie będą mnie nagabywać, abym dodawał nowe elementy do tego programu, ale jeżeli już, to zajmę się programem Wet, o którym wspomniałem wcześniej. Później zobaczymy co wyjdzie. Nie zwykłem robić planów - coś we mnie drgnie i będzie się zastanawiał "a co jeżeli...". Skończy się to tym, że nie będę mógł spać przez kolejne trzy noce do chwili, gdy nie zacznę nad tym pracować po nocach. Czy mógłbyś opowiedzieć nieco więcej na temat "stale powiększającej się góry oprogramowania, którego nie byłeś w stanie dokończyć"? Co to za programy? Które są bliskie ukończenia, a które chciałbyś ukończyć? Szybki rzut okiem na ten katalog i widzimy: DTZ - wspólny projekt, nad którym pracuję wraz z Russellem Gloverem i Juha Niemimaki. Planujemy przenieść dla AmigaOS 4.x niezbyt znaną, tajemniczą grę dla konsoli Saturn "Death Tank Zwei". Mamy już nadające się do czegoś techniczne demo: możesz się przemieszczać i strzelać pikselami niszcząc fragmenty losowo generowane krajobrazu. Triffic - mały programik, który śledzi informacje na temat wycieczek. Działa on podobnie jak Wet. Na tę chwilę pobierane są dane z ostatnich ofert ze strony BBC. Mam też kilka innych jak np. sterownik dla AmigaInput dla podłączanych pod port równoległy joypadów CD32, MailNotifyDocky, wtyczka XMP dla TuneNet, długo oczekiwana nowa wersja FactsPPC, która jednak nigdy się nie pojawi (choć prawdopodobne jest pojawienie się kompilacji dla AmigaOS 4.x starszej wersji) oraz masa innych portów (nawet przeglądarka plików AmigaGuide, choć nie wiem dlaczego). Brakuje mi cierpliwości do portów - jeśli się nie kompilują takie jakie są lub gdy ich naprawdę nie potrzebuję, to szybko porzucam temat. Z drugiej strony nie lubię takich "zwykłych" portów - zawsze staram się dodawać jakiś amigowy element, nawet jeśli to tylko zamiana jakichś kiepskich SDL-owych okien wyboru plików przez ich ASL-owy odpowiednik. Ogólnie jednak rzecz biorąc, preferuję pracę nad własnymi rzeczami. Niektóre rzeczy, które w założeniu mają być "rozszerzoną wersją portu", przeobrażają się w formy pisane od podstaw, zwłaszcza wtedy, gdy nie mogę rozszyfrować oryginalnego kodu lub nie jest on zbyt elastyczny na moje potrzeby. Większość moich projektów zostaje wydanych w takiej bądź innej formie. Jeśli kiszą się na moim dysku, ale w jakiś sposób nadają się do użytkowania, wrzucam je na sieć z zamiarem dalszej nad nimi pracy lub dołączam kod źródłowy i wyraźnie zaznaczam, że nie będę się już tym więcej zajmował (co oczywiście nie powstrzymuje ludzi przez dalszym zgłaszaniem błędów - przysięgam, że dostaję więcej zgłoszeń odnośnie programów, którymi się już nie zajmuję). Co sądzisz na temat całej sytuacji wokół AmigaOS 4.x i Hyperion Entertainment? Hyperion Entertainment odwala kawał naprawdę dobrej roboty wokół AmigaOS 4.x. Wstyd tylko, że z powodów prawnych ich praca jest blokowana. Czym interesujesz się poza Amigą? Masz jeszcze jakieś hobby? Chciałbym powiedzieć coś nietypowego, ale prawda jest taka, że lubię czytać, spać, jeść i chodzić na kabarety. A, no i jeszcze grać na moim Wii. Jakie są Twoje najlepsze i najgorsze amigowe wspomnienia? Autobus oderwał mi drzwi samochodu, gdy wkładałem do środka AmigaOne. To by było to złe. O wiele więcej było dobrych wspomnień, lecz po upadku Commodore, mój optymizm jest bardzo krótkotrwały. Czy chciałbyś coś powiedzieć na zakończenie? Jeśli jest jakiś program, którego używasz na codzień lub bardzo często, powiedz osobie, która go stworzyła jak bardzo go lubisz. I jeszcze jedno - kupujcie Sam440 i AmigaOS 4.1. Dziękuję za poświęcony na udzielenie odpowiedzi czas. Życzę powodzenia w pracy nad obecnymi i przyszłymi projektami. Tłumaczenie: Sebastian Rosa