• Fredrik Wikstrom (Sierpień 2009)

03.09.2009 21:30, autor artykułu: Sebastian Rosa
odsłon: 3481, powiększ obrazki, wersja do wydruku,

Dziękuję, że zgodziłeś się na tę rozmowę. Na początek, mógłbyś się przedstawić i powiedzieć czym się zajmujesz w naszej społeczności?

Nazywam się Fredrik Wikström. Mam 24 lata i obecnie studiuję fizykę na uniwersytecie w Helsinkach, w Finlandii.

Po raz pierwszy zetknąłem się z Amigą, gdy mój ojciec wraz ze starszym bratem przywieźli z wycieczki do Wielkiej Brytanii A500. Wydaje mi się, że miało to miejsce na początku lat 90-tych (niezbyt dobrze idzie mi zapamiętywanie lat). Później dokupiliśmy do niej rozszerzenie pamięci o kolejne 512 kB oraz monitor 1085S. Później mój brat kupił sobie PC (75 MHz Pentium), co oznaczało, że A500 została w moich rękach. Obecnie posiada on Macintosha i prowadzi własną firmę informatyczną.

Zanim staliśmy się posiadaczami A500 mieliśmy coś, co się nazywało SpectraVideo. Nie używałem tego zbyt często (przynajmniej nie tak często, jak bym chciał), bo jedyną grą, którą sam potrafiłem uruchomić była dwuosobowa gra walczących ze sobą czołgów. W A500 wystarczyło wrzucić dyskietkę do napędu, a gra uruchamiała się automatycznie.

Cały czas mówisz o grach. Kiedy zacząłeś interesować się programowaniem/kodowaniem?

Po raz pierwszy zainteresowałem się programowaniem w momencie, gdy chciałem tworzyć własne gry. Oczywiście nie miałem wtedy żadnego pojęcia na temat tego, jakiego nakładu pracy to wymaga. Udało mi się przekonać mojego brata/rodziców, aby kupili mi AMOS-a. Wykorzystując go napisałem kilka prostych gier/programów. Później stałem się użytkownikiem Blitz Basic 2.1. AMOS miał pewne ograniczenia, np. odnośnie ilości linii kodu programu. Poza tym Blitz uzyskiwał całkiem dobre recenzje w magazynach amigowych.

Dużo później mój brat kupił mi książkę z kursem assemblera ("Amiga assembler" Paula Overaa) skąd nauczyłem się kodować w assemblerze M68000. W ten sposób zacząłem wykorzystywać funkcje Blitza do włączania kodu assemblerowego, a tym samym optymalizację programu. Zainteresowałem się również programowaniem z wykorzystaniem funkcji systemowych. Zdobyłem RKRM w formacie AmigaGuide i przepisałem kilka przykładów w C na język Blitza.

Czynnikiem, który sprawił, że przesiadłem się z Blitz Basica na C było to, że chciałem, aby moje programy mogły działać natywnie na AmigaOS 4.0, o którym czytałem na os.amiga.com. Zanim to nastąpiło, i tak wszystko co pisałem w Blitzu bardzo przypominało C (newtypy, wskaźniki, starałem się prawie w ogóle nie wykorzystywać komend Blitza), przesiadka nie była więc taka trudna. Od tamtej pory nie oglądam się wstecz. Będąc szczerym, C okazuje się na wiele sposobów językiem prostszym i oferującym znacznie większe możliwości niż Blitz. Dla przykładu, posiada znacznie bardziej przejrzystą składnię, nie musisz korzystać z instrukcji Peek i Poke, aby uzyskać dostęp do niektórych wskaźników, nie wymusza wykorzystywania do wszystkiego zmiennych globalnych. Blitz posiada co prawda pewien rodzaj funkcji, które potrafią wykorzystać zmienne lokalne, lecz ich implementacja, moim zdaniem, nie jest zbyt dobrze pomyślana.

Bawiłem się również nieco C++, lecz cała ta sprawa związana z OOP wydaje się być dla mnie zbyt skomplikowana. Poza tym, w moim odczuciu, wszystko co może być zrobione w C++ również dobrze można wykonać w C.

W jakich okolicznościach zainteresowałeś się AmigaOS 4.x?

Gdy zamknięto Amiga Format a moja A1200 przestała działać, straciłem nieco zainteresowanie Amigą. Okazjonalnie, raz na kilka miesięcy, sprawdzałem korzystając z PC nowinki na amiga.com. W ten sposób dowiedziałem się o pracach nad AmigaOS 4 i zainstalowałem pakiet Amiga Forever. Mogłem uruchamiać gry i programy amigowe na moim PC. Gdy dowiedziałem się o portalu amigaworld.net, który posiadał forum dyskusyjne oraz zamieszczał więcej informacji poświęconych OS4 (nie wspominając o mniejszej liczbie pecetowych trolli), zaprzestałem odwiedzać stronę os.amiga.com.

Co mnie najbardziej zainteresowało w AmigaOS 4.0, to fakt, że system ten był (i nadal jest) rozwijany, w odróżnieniu od będącego ślepą uliczką AmigaOS 3.x, który mogłem uruchamiać na WinUAE.

Jesteś dosyć produktywnym programistą. Stworzyłeś wiele różnorakich i potrzebnych programów, choćby SRec, AmiSoundED, diskimage.device, ISO-o-matic, Battle for Wesnoth. Niektóre z tych tytułów to Twoje pomysły, całkowicie przez Ciebie rozwijane, podczas gdy inne są portami. Czy z któregoś z nich jesteś szczególnie dumny? Twoim zdaniem, które z Twoich dokonań programistycznych okazało się najbardziej potrzebne a amigowcy są naprawdę szczęśliwi z faktu jego posiadania?

Programy, z których jestem szczególnie dumny to diskimage.device, SRec, CDXLPlay i AminetReadme. Ze wszystkich, które napisałem, najwięcej czasu poświęciłem na tworzenie i dalszy rozwój diskimage.device.

Co się zaś tyczy użyteczności, osobiście najczęściej korzystam z AminetReadme. Bardzo ułatwia mi pracę podczas tworzenia plików readme. Z informacji, które uzyskuję od użytkowników, czy to na e-mail, czy też w postaci komentarzy na forach wynika, że najczęściej używanymi moimi programami są Battle for Wesnoth, AmiSoundED, diskimage.device, ISO-O-Matic, SRec i TD64Patch. Sam osobiście nie używam i nie używałem TD64Patch. Jest jednak wiele osób, które czerpią z tego pożytek i twierdzą, że TD64Patch wykonuje swoją pracę doskonale.

Pomysły na stworzenie niektórych programów (np. SRec, TD64Patch, ptreplay.library, medplayer.library) czerpię z wątków na forach internetowych. Inne programy piszę dlatego, że ich po prostu potrzebuję (np. diskimage.device, AmiSoundED, AminetReadme) lub aby wypełnić jakąś lukę (np. CDXLPlay).

Wspomniałeś o interesującej rzeczy. Jak to jest, gdy rozwija się narzędzie, z którego samemu się nie korzysta?

TD64Patch był dosyć prosty do napisania, a w związku z tym, nie wymagał dużej liczby testów. Jedyna różnica pomiędzy komendami TD64 i NSD64 to wykorzystywane kody komend. W większości przypadków testuję program, czy działa poprawnie i nie wiesza się, nawet jeżeli sam z niego nie korzystam.

Pomijając to, że czasami otrzymuję jakieś prace zlecone od mojego brata, za które dostaję pieniądze, programowanie to moje hobby. Prawdopodobnie zabiera mi najwięcej czasu, jaki spędzam przy komputerze. W większości przypadków piszę programy, które są dla mnie użyteczne lub ich napisanie z jakiegoś powodu jest ciekawe. Na przykład pisanie SRec było interesujące, gdyż nigdy wcześniej nie zrobiłem nic, co wiązałoby się z wykorzystaniem kodeków wideo. Z kolei na potrzeby CDXLPlay musiałem napisać konwersję z trybu planar do chunky, która to powstała ostatecznie w asemblerze PPC.

Rzeczy jak ptreplay.library, datatypy i wtyczki do TuneNet to również była zabawa. Efekty pracy osiąga się w takich przypadkach dosyć szybko. Z całą pewnością nie można czerpać przyjemności z tego, gdy po spędzeniu kilku godzin klepania 1000 linii kodu okazuje się, że coś nie działa i aby wykryć błąd trzeba poświęcić kolejne kilka godzin na debug.

Twoje ostatnie osiągnięcie - SRec - całkiem nieźle się rozwija. To samo tyczy się diskimage.device. Jaki jest plan rozwoju tych narzędzi? Co jeszcze planujesz w nich zaimplementować?

Jeśli chodzi o SRec, to chciałbym popracować nad usprawnieniem części odpowiedzialnej za zapis dźwięku. Z pewnym względów jest to obecnie niemożliwe. Na MicroA1-C mam z tym problemy, gdyż sterownik dźwięku CMI8738 podczas nagrywania wymusza swoje własne ustawienia głośności pomijając ustawienia Mixera. Z racji tego, że moja metoda polega na tym, aby doprowadzić wyjście dźwięku do wejścia mikrofonu, ważne jest, aby mikrofon był wyciszony. W przypadku SAM440ep wciąż czekam na kartę rozszerzeń wejścia/wyjścia, abym mógł mieć wejście dźwięku na jakimś porcie. Poza tym chciałbym ten program poddać ogólnej optymalizacji oraz być może dodać obsługę innych formatów (rozważam m.in. format mkv). Konfigurowalny zoom z całą pewnością byłby czymś ciekawym, lecz musiałby zostać wyposażony w jakiś mechanizm, który podawałby jak bardzo obraz jest powiększony.

Co się zaś tyczy diskimage.device, chciałbym dodać montowanie obrazów dysków z wykorzystaniem plików .cue oraz obsługę ścieżek audio. To ostatnie będzie wymagało dodania obsługi komend SCSI, takich jak READTOC czy READMSF, aby poprawnie zadziałała zarówno funkcja AmigaOS 4.x pozwalająca na przeglądanie ścieżek jako plików AIFF, jak i mój program PlayCDDA. Dla PlayCDDA konieczna będzie obsługa kilku dodatkowych komend standardu SCSI. Następnie prawdopodobnie przyjrzę się możliwości dodania obsługi plików .ccd, które działają podobnie do plików .cue, lecz przechowują informacje nieco inaczej.

Czy masz jakieś plany na stworzenie nowych, innowacyjnych narzędzi dla AmigaOS 4.x lub być może planujesz port czegoś, na co amigowcy mogli czekać od bardzo dawna?

Nie bardzo. Na tę chwilę mam w planach małe (i mam nadzieję użyteczne) narzędzia. Na przykład, rozważam stworzenie dla AmigaOS 4.x zamienników starych bibliotek i urządzeń pisanych pod 680x0, takich jak cd.device, streplay.library, playsid.library, rtgmaster.library oraz poddaję pod ewentualną możliwość powstanie narzędzi do modyfikacji filmów stworzonych przy pomocy SRec. Rozważałem również napisanie programu graficznego podobnego do DPaint, lecz ze znacznie bardziej nowoczesnym interfejsem i funkcjami (GUI w ReAction, wczytywanie obrazków przy wykorzystaniu datatypów, tryb truecolour, kanału alpha itd.). Wymagałoby to jednak znacznie więcej czasu i motywacji niż mam obecnie.

Zmieniając temat, Twoim zdaniem, jaka przyszłość czeka AmigaOS i systemy z niego się wywodzące? Czy zostaniemy jeszcze czymś zaskoczeni? Jakie są Twoje życzenia dotyczące Amigi i AmigaOS?

Nie oczekuję, że AmigaOS zawojuje świat, czy też liczba jego użytkowników sięgnie liczby użytkowników Linuksa czy systemu Mac OS. Mam jednak nadzieję, że AmigaOS będzie w stanie przetrwać jako system niszowy/hobbystyczny. Czy jest to realne, nie potrafię powiedzieć (ani mi na tym w sumie nie zależy).

Biorąc pod uwagę fakt, że Hyperion wiele już razy zaskakiwał nas nowymi rzeczami (uaktualnienia AmigaOS, przeciąganie ekranów, współdzielone obiekty, kompozycja, AmigaOS 4.1 dla SAM, AmigaOS 4.1 dla Pegasosa II...) nie wydaje mi się bezpodstawnym spodziewać się, że ten ich "ambitny projekt", nad którym pracują, okaże się równie przyjemną niespodzianką.

Co do moich życzeń dotyczących Amigi i AmigaOS. Dla AmigaOS życzyłbym sobie chyba usprawnionego Workbencha (w zasadzie to całkowitego przepisania), obsługi USB 2.0 i ulepszonej ochrony pamięci. Dla samej Amigi wydaje mi się, że byłoby miło, gdyby proces Amiga Inc. się skończył. Choćby tylko z tego powodu, że trolle miałyby jeden temat mniej, na który mogłyby wypisywać bzdury.

Fredrik, było mi bardzo miło, że mogłem z Tobą porozmawiać. Dziękuję, że odpowiedziałeś na wszystkie moje pytania. Życzę Ci powodzenia w pracy nad Twoimi projektami. Twoje ostatnie trzy akapity zdają się być dobrym podsumowaniem, ale może chciałbyś na koniec coś jeszcze dodać?

Dziękuję za rozmowę. Chciałbym podziękować wszystkim, którzy w jakikolwiek sposób okazują swoje uznanie, czy też nadsyłają raporty błędów dotyczące moich programów. Zawsze jest miło wiedzieć, że są ludzie, którzy ich używają i są dla nich użyteczne.

Korekta: Konrad Czuba i Aleksander Chyliński

    
dodaj komentarz
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem