Praktyczne wskazówki na temat użytkowania edytora Panther w systemie TURBO BLIZZARDDo przerabiania magnetofonu na turbo zabrałem się jakieś trzy lata temu i dość przypadkowo wybrałem system Blizzard. Jak się później okazało, był to wyjątkowo szczęśliwy wybór - spośród wszystkich znanych mi systemów tylko on był projektowany z myślą o używaniu go do pracy, a nie tylko do wczytywania gier.
Blizzard COS przestrzega wszystkich zasad narzuconych na DOS'y i udostępnia sterownik urządzenia T:. Wszystkie zapisane pod nim pliki mają jednakową postać, co pozwala np. wygenerować z BASIC'a na kasetę za pomocą Zgrywusa program maszynowy, czy też wprowadzić nieśmiertelność do ulubionej, ale za trudnej gry. Transmisja jest bardzo szybka i niezawodna. W trybie turbo błędy nie występują prawie nigdy. Udało mi się nawet kiedyś wczytać River Raid z kasety, która przeleżała dwa lata w szufladzie! W porównaniu z innymi systemami Blizzard wypada więc bardzo dobrze. Najlepiej świadczy o tym przypadek mojego kolegi, który kupił sobie AST. Po pół roku wymontował je i założył Blizzarda. Nie było w tym nic dziwnego, gdyż reklamowana przez producenta niezawodność systemu opierała się - jak nam się zaczęło wydawać - na braku sumy kontrolnej. Błędy istotnie nie pojawiały się nigdy, ale za to gry wczytywały się z olbrzymimi przekłamaniami. Raz nawet w ten sposób samoistnie pojawiła się nieśmiertelność, ale przecież nie o to chodzi. Gdy kupiłem Panthera, miałem już za sobą kilka miesięcy użytkowania pakietu QA. Wszystkie programy z tego pakietu działają pod systemem Blizzard, więc i teraz nie przewidywałem żadnych trudności. Po przegraniu Panther bezbłędnie się wczytał, rozpoznał, że był wczytywany z urządzenia T: i rozpoczął odczyt swego pliku konfiguracyjnego. I tu wystąpił problem - mimo, że nadałem mu nazwę PANTHER.SET, procedury obsługi transmisji turbo jakoś nie chciały go otworzyć i odczytać, tak jakby nie zgadzała się nazwa pliku. Po kilku próbach doszedłem, co wywoływało ten niemiły zgrzyt. Powodem było to, że Panther żąda odczytania pliku T1:PANTHER.SET, a autorzy systemu Blizzard nie przewidzieli, że ktoś może się chcieć odwołać do T1:, skoro jest to równoznaczne z T:. Niedopracowana procedura rozpoznawania nazwy zalicza w takim przypadku dwukropek do nazwy pliku jako jego pierwszy znak. Jasne jest, że plik konfiguracyjny nie mógł być wczytany, gdyż na taśmie był poszukiwany plik o nazwie :PANTHER.SET! Rozwiązanie narzuca się samo - właśnie takie nazwy zaczynające się od dwukropka trzeba nadać plikom: konfiguracyjnemu, znaków oraz konwersji. Można to osiągnąć podając podczas ich kopiowania nazwy typu T1:PANTHER.SET lub T::PANTHER.SET (oczywiście dla następnych plików rozszerzeniem nazwy będzie .FN0, .FNT, .CVN). Teraz czas na wczytywanie fontów przy pomocy opcji Display. Tutaj się z kolei okazało, że Panther żąda otwarcia pliku T1:*.FNT, wobec czego pliki ze znakami muszą mieć nazwy zaczynające się od *.FNT. Ta sama uwaga odnosi się do tablic konwersji, z tym że tutaj nazwa musi się zaczynać od *.CVN. Po tych rozważaniach teoretycznych czas na praktykę. Mój zestaw na kasecie składa się z następujących plików: PANTHER.COM, :PANTHER.SET, :PANTHER.FN0. Nie nagrałem plików :PANTHER.FNT i PANTHER.CVN, gdyż ich nie używam. Po wczytaniu Panther odczytuje pliki .SET i .FN0, a potem przerywam mu dalszy odczyt podwójnym BREAK. Dalej na kasecie mam pliki :*.FNT-POLSKIE i :*.FNT-PE. Doczytuję sobie opcją Display ten, który jest mi w danej chwili potrzebny. Plików konwersji nie używam, bo jak na razie nie mam drukarki. I jeszcze drobna uwaga na temat opcji Save oraz Load. Jeśli nie podamy nazwy urządzenia, to Panther uzupełni nazwę o Tl: ze wszystkimi wynikającymi stąd konsekwencjami. Ktoś się może zapyta: po co to wszystko, skoro wystarczy wczytać Panthera podając T2:*, tak żeby się później odwoływał do T2:, a nie do tego feralnego Tl:? Niestety, ten trick nie skutkuje, a mając opracowaną powyższą metodę postępowania już nie chciało mi się badać dlaczego. Wojciech Palacz
|