Amiga początkowo utożsamiana była z grami, które rozprowadzane były na dyskietkach. Z czasem ten nośnik przestał być funkcjonalny, zarówno ze względu na prędkość odczytu danych, pojemność, jak i żywotność. Dodatkowe rozszerzenia sprzętowe, w które amigowcy wyposażali swoje "przyjaciółki" zaczynały ograniczać działanie starszego oprogramowania, a wachlowanie dyskietkami w dobie twardych dysków przestało być wygodne. Naturalną koleją rzeczy było więc pojawienie się czegoś, co ułatwi trudny żywot tym, którzy lubią czasami w coś zagrać. Zaczęły więc pojawiać się tzw. HD łatki, które umożliwiały "oszukanie" gry, aby nie odwoływała się na sztywno do urządzenia DFx: w celu odczytania danych, pozwalając tym samym na uruchomienie gry z twardego dysku. To rozwiązanie było zadowalające, lecz bardzo szybko okazało się, że posiada pewne wady. W większości przypadków taka łatka działała z jedną, konkretną wersją gry - głównie piracką. Osoby, które posiadały wersję oryginalną, dystrybuowaną na zabezpieczonych przed kopiowaniem dyskietkach, nadal miały problem, gdyż takiej gry nijak nie szło przenieść na dysk twardy, nawet pomimo dołączonych do "łatki" narzędzi tworzących obraz dysku. Dodatkowo bardzo często taka łatka działała w obrębie pewnych konfiguracji sprzętowych. Zaistniała więc w ten sposób potrzeba narzędzia, które nie tylko "oszuka" grę, aby czytała dane z innego miejsca, ale również aby gra "myślała", że jest uruchamiana na domyślnie ustalonej konfiguracji, bez znaczenia jaka ona w rzeczywistości jest. W ten właśnie sposób narodziły się HDLoadery z funkcją degradera, które pozwalają odłączyć lub wyłączyć niektóre komponenty systemu, aby możliwe było uruchomienie danej aplikacji w tak jakby emulowanym środowisku innej maszyny. Jak więc widać, jest to kolejne "oszustwo", którym gra jest traktowana. Amigowy software market opanowały dwa takie programy: JST oraz WHDLoad. Ich cel był dokładnie taki sam, lecz filozofia działania, choć również zbliżona, okazała się lepsza i bardziej przyszłościowa wyłącznie u jednego z nich - WHDLoad. Autor JST szybko to dostrzegł, porzucił jego rozwój i dołączył do ekipy wspierającej rozwój bohatera niniejszego artykułu.

Odważę się stwierdzić, że WHDLoad to statystycznie najpopularniejszy i najczęściej uruchamiany amigowy program. I choćby znalazło się kilka, kilkanaście lub kilkadziesiąt osób, które być może z niego nie korzystają, to na pewno stanowią one niewielki odsetek wszystkich amigowców, którzy o WHDLoad musieli chociażby słyszeć. Autorem programu jest niemiecki programista Bert Jahn, który pierwszą, publiczną wersje beta programu wydał w sierpniu 1996 roku, podczas gdy pierwszą wersję 1.1 prawie dwa lata później, w maju 1998, jednocześnie szybko zmieniając sposób numerowania wersji, co sprawiło, że w lipcu 1998 otrzymaliśmy wersję 7.0. Początkowo jego działanie było bardzo skromne i ograniczało się wyłącznie do jego podstawowej funkcjonalności, aby zapewnić możliwość uruchamiania gier z twardego dysku. Z wersji na wersję jego możliwości jednak przybywało, a program rozwijany jest aż do dziś.

Co to jest?

WHDLoad to, jak już wspomniałem, program, który zwykło nazywać się mianem degraderów, czyli narzędzi służących do "odłączania" niektórych komponentów "silniejszych" konfiguracji w celu uruchomienia starszych gier lub programów (to tak pobieżne, dla laików). WHDLoad posiada jednak znacznie większe możliwości, gdyż działa niczym emulator, który uruchamia zazwyczaj gry nie z dysku, lecz ze specjalnie przygotowanych obrazów dysków. Dodatkowo WHDLoad potrafi "uaktywnić" nieistniejące w oryginalnej grze elementy, takie jak na przykład zapisywanie tabeli najlepszych wyników, zapewnić wyjście z gry z powrotem do systemu czy uaktywnieniu tzw. cheatów. Idea działania zainstalowanych gier lub programów przy pomocy WHDLoad oparta jest na zasadzie "pana i niewolnika". Niewolnikiem jest plik slave, który zawiera szereg instrukcji i poleceń interpretowanych przez WHDLoad (pana), pozwalających ominąć lub podmienić wiele elementów, które sprawiają problemy na innych konfiguracjach niż pierwotnie zakładali twórcy danej gry.

Jak korzystać z WHDLoad?

Na początek należy upewnić się, że nasza konfiguracja sprzętowa posiada niezbędne do działania WHDLoad wymagania. Program nie jest wcale wybredny i zadowoli się każdym procesorem linii 68k (choć pewne funkcje są dostępne dopiero dla 68010), kickstartem 2.0 oraz minimum 1 MB pamięci. Gdy to mamy już za sobą, czas pobrać archiwum. Do wyboru mamy dwie opcje: archiwum użytkownika (USR) lub dewelopera (DEV). Proponuję zainteresować się tym pierwszym i korzystając ze znajdującego się tam skryptu instalacyjnego, zainstalować program. W zasadzie wszystko co niezbędne to raptem kilka plików (WHDLOAD, DIC, RawDIC), które zostaną umieszczone w katalogu C: partycji systemowej oraz dokumentacja (dostępna także w języku polskim). Jeżeli z jakichkolwiek przyczyn, program nie będzie chciał się nam zainstalować lub chcielibyśmy zrobić to ręcznie, to cała tajemnica polega na przekopiowaniu plików z katalogu C: znajdującego się w archiwum WHDLoad do katalogu C: znajdującego się na partycji systemowej (wskazywanego domyślnie przez C:) lub innego, wskazanego przez polecenie PATH. Posiadanie WHDLoad na twardym dysku to jednak nie koniec.

Niektóre pliki slave używają tak zwanego trybu kickemu w celu zapewnienia kompletnego (czytaj - bardziej wiernego) środowiska dla zainstalowanego programu. Do tego celu tryb kickemu wymaga pliku z obrazem oryginalnego Kickstartu, który należy zrzucić (na przykład programem GrabKick) z naszej Amigi. Obrazy Kickstartu 1.2 i 1.3 mogą być zgrane tylko z komputera Amiga 500, podczas gdy wersja 3.1 może być zgrywana z komputerów Amiga 500/600/1200 oraz Amiga 2000/3000/4000, które są wyposażone w kości ROM z Kickstartem 3.1. Do kompletu brakuje nam jeszcze plików relokacji (RTB), które można znaleźć w aminetowym archiwum SKick. Tutaj pierwsza uwaga, gdyż jest to jeden z najczęściej popełnianych błędów przy instalacji WHDLoad. Zrzucony obraz Kickstartu musi zostać odpowiednio nazwany, a nazwa ta jest podana w dokumentacji WHDLoad i jest uzależniona od wersji i pochodzenia naszego Kickstartu. Druga uwaga jest taka, że pliki relokacji muszą odpowiadać naszej wersji Kickstartu i muszą również być odpowiednio nazwane. Zarówno plik/pliki obrazu Kickstartu oraz odpowiadające im pliki relokacji należy umieścić na partycji systemowej w katalogu DEVS:Kickstarts.

Na koniec, gdy już zdecydujemy się na zarejestrowanie programu, pozostaje umieszczenie w katalogu C:, L: lub S: klucza rejestracyjnego.

Instalujemy grę

Kolejnym krokiem jest zainstalowanie gry, dema lub programu, który chcemy uruchomić. Ze strony programu należy pobrać archiwum z interesującym nas pakietem instalacyjnym. W nim znajduje się kilka plików, które mogą być inne dla każdej z gier, którą będziemy instalować, lecz trzy z nich są obowiązkowe:

• plik slave, kluczowy element pakietu indywidualnie napisany dla każdej obsługiwanej gry,
• plik readme, w którym zapisane są m. in. informacje o wymaganiach gry oraz specjalnych ustawieniach i funkcjach slave,
• skrypt instalacyjny wraz z ikonką, przy pomocy którego należy zainstalować grę/demo/program na twardym dysku.

Opcjonalnie w archiwum może znajdować się także jeszcze jeden plik - z rozszerzeniem islave, który służy w większości przypadków do zainstalowania gier zabezpieczonych przed kopiowaniem, a także dodatkowe ikonki w różnych standardach, dokumentacja do gry, sposób przejścia, porady i inne.

Po rozpakowaniu archiwum należy zapoznać się z wymaganiami slave. Jest to bardzo istotny element każdego slave, o czym wielu użytkowników WHDLoad zapomina. W przypadku WHDLoad nie ma znaczenia, że gra oryginalnie śmiga na A500 z 512 kB Ram. Budowa i metoda działania programu sprawia, że taka gra może bezwzględnie wymagać np. 1 MB pamięci Fast lub 0,5 MB pamięci Chip i 0,5 MB pamięci Fast (co niejako stanowi minimalne wymagania samego programu). Inna może dać się uruchomić na nierozbudowanej A600, lecz z wyłączoną funkcją PRELOAD (o tym później) i aby ją włączyć potrzebujemy dodatkowej pamięci. Przeczytanie tych kilku linijek tekstu czasami potrafi zaoszczędzić nam wiele czasu na analizowanie powodów niedziałania gry, a dodatkowo możemy dowiedzieć się, na przykład, o nowych funkcjach wbudowanych w slave (np. zapisywaniu tablicy najlepszych wyników, co w oryginalnej grze uruchamianej z dyskietek nie miało miejsca).

Gdy już wiemy, że nasz system sprosta wymaganiom instalowanej gry, możemy rozpocząć proces instalacji gry. Uruchamiamy skrypt instalacyjny i postępujemy zgodnie z wyświetlanymi tam poleceniami. Między innymi wskazujemy źródłowe urządzenie, z którego dane będą kopiowane (do wyboru możemy mieć np. fizyczną stację dysków (DF0, DFx, RAD czy też plik ADF), miejsce docelowe na dysku twardym, gdzie zostanie zainstalowana gra oraz wybieramy stosowną ikonkę (jeżeli są jakieś do wyboru). Niektóre skrypty pozwalają również ustawić odpowiednie parametry instalowanej gry, które zapisują się w tooltypach ikony. Warto mieć również na uwadze, że bez posiadania oryginalnych dyskietek z grą lub oryginalnych obrazów dysków (np. w postaci plików IPF), w większości przypadków nie będziemy w stanie zainstalować gry. Twórcy slave'ów do WHDLoad wyszli z założenia, że nie ma sensu wspierać pięciu scrackowanych wersji gry i lepiej skupić się na jednej, która jest dokładnie w takiej postaci binarnej, w jakiej napisali ją jej autorzy. Dodatkowo, z początkiem istnienia WHDLoad pod wątpliwość stawiano jego bycie w zgodzie z prawem autorskim i dyskutowano czy program go przypadkiem nie łamie. Na szczęście dla użytkowników i autora tego typu zarzuty okazały się bezpodstawne.

Po zakończeniu procesu instalacji możemy spróbować uruchomić grę z katalogu, do którego nakazaliśmy jej instalację. W przypadku problemów z uruchomieniem należy upewnić się, że nasza konfiguracja spełnia wymagania stawiane przez slave lub czy nie są wymagane specjalne ustawienia, o których wspomniane jest w pliku README. A co jeżeli sprostaliśmy wymaganiom, a gra nadal nie chce działać? Pozostaje...

Zabawa parametrami

Z uwagi na swoją mnogą funkcjonalność WHDLoad zapewnia ogromne możliwości konfiguracyjne, zarówno pod kątem działania sterowanej przez slave gry, jak również dodatkowych funkcji. Te pierwsze czasami trzeba stosować w różnych kombinacjach i są one różne dla różnych konfiguracji sprzętowych i procesorów, w które są wyposażone. Parametry, w zależności od sposobu uruchamiania gry, dema lub programu mogą znajdować się w tooltypach ikony lub być podawane jako parametr komendy CLI. Część z tych parametrów możemy również potraktować jako globalne, czyli znajdujące zastosowanie dla każdego slave (uruchamianej gry) bez potrzeby ich wpisywania w ikonce lub jak parametr przy uruchamianiu z CLI. Wówczas należy wpisać odpowiedni parametr (lub zmodyfikować istniejący) w pliku WHDLoad.prefs znajdującym się w katalogu S: partycji systemowej.

Lista parametrów jest bardzo długa i dobrze opisana w dokumentacji programu. Najpopularniejsze, z którymi zetknie się praktycznie każdy użytkownik to:

• PRELOAD - funkcja do wczytania całej gry do pamięci, dzięki czemu doczytywanie danych w trakcie gry jest praktycznie niezauważalne dla użytkownika. Brak aktywacji tej funkcji pozwala na uruchomienie większości gier na słabszych konfiguracjach, lecz należy liczyć się z tym, że WHDLoad doczytując dane będzie zmuszony połączyć się z systemem, aby wykonać operację dyskową, a to skutkować będzie charakterystycznym migotaniem ekranu;
• SLAVE=nazwaslave.slave - ten parametr jest obowiązkowy dla każdego slave i wskazuje nazwę pliku slave, który ma zostać wywołany przez WHDLoad;
• QUITKEY=$xx - każdy slave posiada domyślnie ustawiony klawisz, który powoduje wyjście do Workbencha z uruchomionej gry lub dema. Ten parametr pozwala ustawić inny klawisz wyjścia (funkcja bardzo przydatna dla posiadaczy A600, którzy nie posiadają klawiatury numerycznej, a bardzo często domyślnie klawisze wyjścia przypisane są do tam znajdujących się klawiszy);
• NOCACHE - wyłączenie cache procesora. Funkcja zazwyczaj przydaje się, gdy gra działa zbyt szybko lub występują artefakty graficzne na ekranie. Posiadacze procesorów 68040 i 68060 mogą również korzystać z dodatkowych funkcji związanych z cache procesora, takich jak CHIPNOCACHE, BRANCHCACHE, DCACHE;
• CUSTOM - parametr służące do kontroli specyficznych elementów slave. Dla przykładu autor slave mógł zapisać w nim, że zastosowanie CUSTOM=1 będzie skutkować włączeniem nieskończonej liczby żyć, a CUSTOM=2 brak kolizji. W innych tytułach mogą one oznaczać rozpoczęcie gry od podanego etapu lub włączenie jakiejś ukrytej funkcji.

WHDLoad i CD32

Ukłonem autora w kierunku posiadaczy Amigi CD32 jest specjalna wersja WHDLoad przygotowana właśnie dla tej maszyny. Została zoptymalizowana pod ten sprzęt i uruchomi się jedynie na "gołej", nierozbudowanej Amidze CD32. Pakiet nie uruchomi się na tym komputerze z dodatkiem SX-32, jak i na żadnej innej maszynie. WHDLoadCD32 nie wymaga rejestracji, ale jednocześnie oferuje znacznie mniej w stosunku do oryginału. Nie posiada wielu funkcji uruchamiających i emulujących pewne środowiska, nie zapisuje wyników ani nie adresuje więcej niż 2 MB pamięci Chip. Wydaje się być bardzo okrojoną wersją, jaką niektórzy mogliby określić mianem dema lub bety. Pomimo, że można odnieść takie wrażenie, to jednak tak nie jest, a WHDLoadCD32 to odpowiednie dostosowanie programu do działania w określonym środowisku - w tym przypadku na Amidze CD32.

Co jeszcze warto wiedzieć?

WHDLoad to oprócz głównego programu i plików slave do obsługi poszczególnych tytułów, również szereg innych narzędzi, z którymi spotkamy się albo podczas instalacji, albo gdy nieco bardziej zaczniemy zgłębiać jego tajniki. Już wspominałem o czymś takim, jak DIC i RawDIC, ale może warto napisać o nich kilka słów. Mianowicie, WHDLoad sam w sobie uruchamia grę lub demo, ale najpierw należy ją przecież zainstalować. W przypadku tzw. gier "dosowych" sprawa wygląda prosto, gdyż skrypt instalacyjny po prostu kopiuje pliki z dyskietek lub ich obrazów (choć nie zawsze) we wskazane miejsce do specjalnie stworzonego tam katalogu DATA. Jeżeli mamy do czynienia z dyskietkami zapisanymi w formacie NDOS, sprawa już wygląda nieco inaczej i właśnie w tym momencie do akcji wkraczają narzędzia pomocnicze. Najpopularniejszym jest DIC, który wykonuje zrzut fizycznego dysku znajdującego się w napędzie DFx: do postaci obrazu dyskietki o rozmiarze 901120 bajtów. Rozeznani w temacie szybko zauważą, że jest to najzwyklejszy plik ADF i zapewne już nie raz kombinowali z podmianą takich plików na ich własne lub tworzyli je na przykład poza skryptem instalacyjnym i po prostu wgrywali w odpowiednie miejsce. Czasami zdarza się jednak, że rozmiar takiego obrazu dyskietki jest mniejszy lub większy niż ADF. Co wtedy? Jeżeli mamy do czynienia z pierwszą sytuacją, oznacza to, że autor slave miał do czynienia z grą, która oryginalnie nie zajmowała całego dysku, a na przykład pierwszych 40 ścieżek (a więc połowę). Wówczas nie ma sensu tworzyć pełnego obrazu dysku i poświęcić ponad 400 kB na coś, co będzie wypełnione zerami i przy pomocy programu DIC zrzucono wyłącznie pewien obszar. Tego typu rozwiązanie stosowano bardzo często przy pierwszych instalatorach, gdy duże dyski twarde w Amigach nie były jeszcze tak popularne i zanim autor WHDLoad nie zaimplementował obsługi spakowanych obrazów przy pomocy XPK. Obecnie tego typu sztuczki już raczej nie są stosowane.

A co w sytuacji, gdy rozmiar obrazu jest większy niż standardowego pliku ADF? Tutaj do akcji wkracza drugi wspomniany program, czyli RawDIC. Jest to narzędzie służące do tworzenia plików lub obrazów dyskietek z oryginalnych dyskietek zapisanych w ich własnym formacie, w większości przypadków NDOS z funkcjami zabezpieczającymi. Zasadą działania RawDIC przypomina WHDLoad, który jest "panem" i potrzebuje do pracy niewolnika - w tym przypadku jest to plik islave zawierający wszystkie kluczowe informacje pozwalające "rozkodować" dyskietkę. Ale RawDIC nie służy tylko do tego. Czasami gra, która oryginalnie była na dyskietce typu NDOS, może zawierać strukturę plików, którą wykorzysta WHDLoad i będzie uruchamiać grę nie z obrazów, lecz bezpośrednio z plików znajdujących się w katalogu DATA (co pozwala nie tylko zaoszczędzić miejsce, ale również ogranicza wykorzystanie pamięci przez WHDLoad, który nie potrzebuje już alokować tyle pamięci ile zawierają obrazy dyskietek, lecz tyle ile faktycznie zajmują pliki). Z racji tego, że sami we własnym zakresie z dyskietki NDOS nie potrafimy zrzucić plików, RawDIC i pomocniczy plik islave zrobią to za nas. Przykładem takich gier jest np. "Perihelion" czy też "Putty Squad", ale tytuły można mnożyć. Warto jednak pamiętać, że tak zrzuconego obrazu ponownie nie "wgramy" na dyskietkę (przynajmniej nie przy wykorzystaniu ogólnodostępnych programów, których większość z Was wykorzystuje przy zabawie ADF-ami). Starsze skrypty instalacyjne wykorzystywały również program Patcher, który jest uboższą wersją RawDIC i nie jest już obecnie wykorzystywany przez nowo pisane slave'y.

Osoby zainteresowane tematem innych narzędzi pomocniczych dla WHDLoad (jak i być może tematem pisania własnych slave) mogą pobrać wspomniane wcześniej archiwum dla programistów (DEV). Znaleźć tam można kilka innych ciekawych programów, jak na przykład program SP, który służy do analizy obrazów zrzutu pamięci WHDLoad w celu wyciągnięcia z niej obrazków czy ITD do przenoszenia obrazów dyskietek na fizyczne nośniki. Programy tam znajdujące się wymagają już nieco więcej wiedzy technicznej z obszaru WHDLoad, jak i programowania w assemblerze i nie będę się na nich koncentrować.

Jeżeli przyjrzymy się bliżej stronie WHDLoad, znajdziemy na niej również sekcję poświęconą wersjom beta programu, które są testowane przez szerokie grono testerów. W tym samym miejscu znaleźć można także starsze wersje programu na wypadek problemów z kompatybilnością (o tym za chwilę), jak również dalsze ciekawostki, takie jak chociażby tzw. uniwersalny slave dla programów działających pod systemem. Można zadać pytanie, w jakim celu coś takiego istnieje? Odpowiedź jest bardzo prosta. Po pierwsze, gra lub program mogą działać pod starszą wersją systemu i na obecnie przez nas używanej może wywoływać zawieszenia, a po drugie jej systemowe napisanie sprawia, że nie są wymagane specjalnie "hacki" istniejące w znacznej większości typowych plików slave.

Nie ma róży bez kolców

WHDLoad to program, którego działanie i praca jaką wykonuje są niezwykle skomplikowane i wymagają sporej wiedzy nie tylko programistycznej, ale także i tzw. znajomości Amigi od środka. Dlatego też zasada dotycząca posiadania najnowszej wersji programu na dysku w wielu przypadkach nie zdaje egzaminu. Pliki slave są tworzone przeważnie pod mechanizm programu WHDLoad (zazwyczaj najnowsza wersja), jaki ma akurat autor pod ręką w chwili przygotowywania instalatora. W miarę rozwoju programu jego algorytm działania oraz zmiany w API mogą spowodować niekompatybilności z plikami slave napisanymi pod stare wersje programu. Objawiają się one np. poprzez pojawianie się okien z błędami, których nie rozumiemy. Warto w takich przypadkach, przy próbie uruchamiania takich pozycji, cofnąć się do poprzedniej wersji WHDLoad. Jak ich wspólnie używać? Można w dwojaki sposób. Pierwszym jest skopiowanie pliku WHDLOAD starszej wersji do katalogu z grą, drugim jest umieszczenie pliku WHDLOAD pod zmienioną nazwą w katalogu C: (np WHDLOAD w wersji 16.1 możemy nazwać whdload161) oraz modyfikacja wpisu w ikonie danej gry i zastąpienie frazy WHDLOAD przez tę, która odpowiada wymaganej przez dany tytuł wersji (np. wspomniana wcześniej nazwa whdload161). Jak więc widać czasami trzeba się trochę nagimnastykować, ale warto pamiętać o zasadzie, aby jednak problematyczny slave był uruchamiany przez WHDLoad, pod który był stworzony (jeżeli nie ma do slave aktualizacji).

Kolejną niedogodnością może być to, że program wydaje się być nieco skomplikowany w obsłudze. Oczywiście ja bym się tutaj spierał, gdyż osobiście nic w nim skomplikowanego nie widzę, no ale nie każdy musi dobrze czuć się w tych wszystkich parametrach i ustawieniach. Na to jednak wymyślono ułatwienie w postaci tzw. launcherów, czyli odpalaczek, które przeszukują dysk lub wskazany na nim katalog w celu zbudowania bazy dostępnych gier i ich uruchomienie. Do takich launcherów należy zaliczyć iGame, TinyLauncher czy też X-bEnCh (dwa z nich były już opisywane na łamach naszego magazynu). Każdy z nich napisany jest przez inną osobę i charakteryzuje się innymi dla niego elementami, które stanowią jego wyróżnik.

Największy problem, z jakim mogą spotkać się użytkownicy WHDLoad, to konflikt z innymi urządzeniami i oprogramowaniem, które wywołują przerwania w regularnych lub losowych odstępach czasu. Przykładem tutaj są aktywnie działające karty sieciowe i urządzenia USB. Rozwiązaniem najprostszym jest wyłączenie stosów TCP/IP oraz USB na czas używania WHDLoad (chociaż od wersji 16.8 posiadacze urządzeń USB wpiętych w mostki Mediator nie muszą już tego robić). Niestety natura i filozofia działania WHDLoad jest obciążona tą niedogodnością i osobiście nie liczyłbym na rychłe (o ile w ogóle) rozwiązanie tego problemu.

Należy też pamiętać, że większość błędów i problemów, z którymi spotykają się użytkownicy nie wynika z tego, że WHDLoad jest wadliwe, lecz wiąże się z niepoprawną konfiguracją pewnych ustawień systemowych. W dokumentacji jasno zostało napisane, że na potrzeby użytkowania WHDLoad z wykorzystaniem kart CF należy wprowadzić odpowiednie ustawienia parametrów MaxTransfer i Mask w programie HDToolBox dla każdej partycji urządzenia, a użytkownicy pakietu Picasso96 powinni mieć wyłączoną obsługę „FakeNativeModes”. Faktem jest jednak niestety to, że WHDLoad „nie lubi” współpracować z pewnymi rozszerzeniami pamięci i kartami procesorowymi. Z tym problemem autor WHDLoad próbuje walczyć i lista obsługiwanego sprzętu stale się powiększa.

Wnioski

Zapominając jednak o wszelkich niedogodnościach programu (bo ciężko jest je nazwać błędami), trzeba przyznać, że jest to kawał dobrego, amigowego rzemiosła. WHDLoad z całą pewnością zajmuje specjalne miejsce w amigowej historii i nie można zapominać jak duży wkład w amigową społeczność miał Bert Jahn i rzesza twórców slave'ów (niektórzy nawet już nie żyją). Warto to docenić i nie żałować tych kilkudziesięciu złotych, aby program zarejestrować (zwłaszcza że czasami można zdobyć u autora całkiem sporą zniżkę). Jest naprawdę wart swoich pieniędzy, zwłaszcza, że większość z Was na pewno będzie programu bardzo często używać... No bo czyż nie ma większej frajdy niż zagrać rundkę w "Lotusa 2", uzyskać wpis do listy najlepszych, a później, przy kolejnym uruchomieniu gry próbować ten swój wynik poprawić?

Rejestracja programu

WHDLoad można zarejestrować bezpośrednio u autora odnajdując na stronie programu bezpośrednią informację o sposobie płatności oraz kwocie (Od 23 grudnia 2015 roku program jest już darmowy - przyp. mailman). Autor akceptuje wpłaty na rachunek bankowy, jak również płatności za pomocą PayPal. Od czasu do czasu na naszym forum organizowana jest akcja mająca na celu zebranie grupy osób zainteresowanych rejestracją programu. Wówczas autor programu wyraża zgodę na obniżenie ceny pojedynczego klucza rejestracyjnego dla każdej osoby. W ten sposób większość polskich użytkowników posiada zarejestrowany program w cenie nieomalże o połowę taniej.

Pomyślne zarejestrowanie programu kończy się nadesłaniem pliku-klucza bezpośrednio od autora. Plik należy umieścić w katalogu C:, L: lub S: partycji systemowej, aby cieszyć się w pełni zarejestrowaną wersją programu. Rejestracja programu nie tylko oznacza wsparcie dla autora i podziękowanie za jego pracę – niektóre slave wymagają zarejestrowanej wersji, aby odblokować pewne ukryte funkcje.

Nie opłaca się udostępniać swoich pliki-kluczy osobom trzecim, gdyż autor skutecznie tego typu akty piractwa blokuje wraz z każdą nowo wydaną wersją programu. Objawy korzystania z pirackich kluczy to zawieszenia pracy programu (czarny ekran) lub dziwne komunikaty przed uruchomieniem gry.

Oficjalna strona programu - www.whdload.de

Artykuł oryginalnie pojawił się w czternastym numerze Polskiego Pisma Amigowego.