Pecetowa nostalgia: co napędza modę na retro PC?

Moda na retro nie ustaje. Elektroniczna estetyka lat 80- i 90-tych nie jest być może mainstreamem, ale wysyp „klasycznych” wersji konsol (wykorzystujących emulację), niesłabnąca popularność gier typu arcade oraz oszałamiające ceny wszelkich staroci na Allegro to dowody na to, że na tęsknocie da się zarobić. Nostalgia nie dotyczy wyłącznie wymarłych komputerów i architektur, jak Amiga, Commodore czy Sinclair Spectrum, ale także zwykłych pecetów. Może się to wydawać zaskakujące. O ile np. komputer Atari ST lub konsola GameCube to urządzenia niepodobne do niczego, co jest dziś w użyciu (i dodatku potrafi sprawiać problemy z emulacją), to stary pecet jest po prostu poprzednią iteracją dzisiejszych urządzeń. Czy to oznacza, że retro-PC jest jedynie „tym samym, tylko gorzej”? Czy w świetle powolnej ewolucji standardu PC, da się w ogóle postawić granicę między retro, a nowoczesnością? I za czym tak naprawdę tęsknimy, sięgając po stare pecety?

Wedle wielu kryteriów, dzisiejsze komputery PC to ta sama klasa urządzeń, co nudne, szare pudła z hałaśliwymi dyskami, używane trzydzieści lat temu. Przemawia za tym stosowany model programowania: możliwe jest stworzenie programu, który w niezmienionej postaci zadziała na systemie z 1985 roku i z przedwczoraj (dobrym przykładem jest tu wzorcowy wirus EICAR). Różnice zaczynają się pojawiać dopiero, gdy przyjrzymy się sprzętowi nieco bliżej. Prędko wyjdzie na jaw, że jedynie bardzo skromny podzbiór składników dzisiejszego peceta zachowuje zgodność z oryginałem. Próba zainstalowania klasycznych systemów operacyjnych zakończy się niepowodzeniem: MS-DOS wymaga kontrolera dyskietek, nieobecnego od lat. W systemach o ustroju UEFI, kontroler FDD nie jest już nawet programistyczną zaślepką. W ogóle nie istnieje. Systemy dystrybuowane na dyskach CD-ROM również będą miały spore kłopoty z działaniem. Instalator Windows 98 będzie nieużywalny, ze względu na założenie istnienia klasycznego, wbudowanego w sprzęt kontrolera klawiatury (AT lub PS/2). Dzisiejsze pecety bardzo często nie wykorzystują koncepcji magistrali PS/2, zamiast tego korzystając z abstrakcyjnego modelu urządzeń sterujących, zdefiniowanego nad interfejsem USB. Również w tym przypadku, zerwanie z BIOS-em pozwoliło całkowicie wyrzucić nawet „zastubowaną” obsługę PS/2. Jeżeli mimo to uda się przejść przez instalator, który akurat będzie zdolny bez artefaktów wyświetlić się na dzisiejszych kartach graficznych, nędznie obsługujących podstawowe VGA, system może wyłożyć się na nadmiarze pamięci operacyjnej. Będzie również obsługiwał wyłącznie jeden rdzeń (bez hiperwątkowości), a o wszelkich sterownikach możemy naturalnie zapomnieć.

Powyższe przesłanki pozwalają wysnuć podejrzenie, że stare pecety nie do końca są tylko słabszymi wersjami dzisiejszych modeli, serwującymi „to samo, tylko gorzej”. Zamiast tego są odmiennymi urządzeniami, których obsługa przebiega w odmienny sposób. Zapewne ta właśnie odmienność jest źródłem nostalgicznych ciągot w kwestii pecetów. Spróbujmy ją zdefiniować, zaczynając od sprzętu, by potem poruszyć kwestię systemu i aplikacji (a wraz z nimi – specyfiki obsługi).

Udało nam się mimochodem zdefiniować, że „klasyczny” pecet będzie posiadał kontroler dyskietek, najlepiej dwukanałowy. Wszystkie komputery PC typu AT i ATX przez całe lata dziewięćdziesiąte aż do ery procesorów Core 2 Duo zawierały kontroler i przynajmniej jeden napęd dyskietek. Obsługa magnetycznych dyskietek była ważna do takiego stopnia, że ich kontrolery były wbudowane w chipset płyt głównych. Warto tu nadmienić, że oryginalny projekt IBM PC nie zakłada obecności takiego kontrolera. Nie zakłada on bowiem obecności żadnego kontrolera i obsługa żadnego z nich nie jest zawarta w chipsecie, jego bowiem również nie ma. Dyskietki są jednak urządzeniami obsługiwanymi przez BIOS klasycznego peceta, nie wymagają sterowników, są dostępne „zawsze” i możliwe jest uruchomienie komputera bezpośrednio z zawartego na dyskietce systemu.

Dyskietki to fascynujące medium, godne oddzielnego artykułu opisującego chociażby różne ich logiczne formaty i gęstości w ramach tego samego formatu fizycznego („trzy i pół cala” zdecydowanie nie było wystarczającym opisem nośnika!). Są także doskonałym studium w kwestii źródeł retro-nostalgii. Dziś fizyczne nośniki danych bardzo często są zastępowane przechowywaniem na dyskach sieciowych (na własnym serwerze lub, częściej, w „chmurze” oferowanej za grosze przez gigantów branży IT). Jeżeli nie chcemy używać sieci do przenoszenia danych, bo na przykład nie ma to sensu w danym scenariuszu, korzystamy dziś z pendrive’ów. Kwestia, którą nigdy już nie przejmujemy się podczas kopiowania na danych na pendrive, jest jego pojemność. Wielogigabajtowe nośniki są dostępne w bardzo przystępnych cenach, a ich trwałość można mierzyć w latach. Dyskietki to zupełnie inne medium. Najpowszechniej używany format oferował poniżej 1440 kilobajtów (!) pojemności. Naturalnie, pliki stosowane w czasach świetności dyskietek były proporcjonalnie mniejsze względem dzisiejszych, ale nie aż do takiego stopnia, by niska pojemność dysków magnetycznych nie była poważnym problemem.

Ciasnota dyskietek wymuszała dyscyplinę w zarządzaniu tworzonymi plikami. Coraz szybsze komputery bez trudności przetwarzały pliki w rozmiarze nawet kilku megabajtów, ale ich archiwizacja i przenoszenie stanowiło poważny problem! Z tego powodu powszechną praktyką była dbałość o minimalizację rozmiaru efektów pracy. Wspomagano się również różnymi algorytmami kompresji, w ostateczności – narzędziami do podziału plików na części. Wszystko to, by uniknąć stosowania wachlarza dysków. Dla przykładu: system Windows NT 3.5 rozprowadzano na dwudziestu pięciu dyskietkach. Prędkość odczytu każdej z nich to maksymalnie okolice 64 kilobajtów ma sekundę. „Płaskie” kopiowanie 1:1 z takiego dysku trwało więc co najmniej pół minuty, jeżeli mieliśmy szczęście, a dysk twardy nie miał czkawki skutkującej opóźnieniami. Do tego należy doliczyć czas na dekompresję oraz... fizyczną wymianę dysków w napędzie! Proces kopiowania 50 megabajtów potrafił być więc czasochłonny i wymagający: nie można było odejść od biurka i czekać aż pasek postępu dojdzie do końca. Koniecznym było pokornie siedzieć i wymieniać dysk po dysku, drżąc na myśl o ryzyku, że osiemnasty z zestawu dwudziestu sześciu okaże się wadliwy i niemożliwy do odczytania.

Mimo to, dyskietki nie były nienawidzone wprost, a raczej narzucały pokorę. Tworzenie niepotrzebnie wielkich plików uchodziło za niechlujstwo, a dbałość o rozmiar danych zmuszała do kreatywności i świadomego korzystania z komputera. Co zabawne, zachodziło również nieco bardziej „metafizyczne” zjawisko, dość wychowawcze: dyskietki były bardzo wrażliwe. Dzisiejsze pendrive’y można bezkarnie zrzucić ze schodów i kopnąć na piach, po czym otrzepać i będą działać dalej. Smartfona możemy utopić w kawie i też pewnie nic mu się nie stanie. Dyskietki natomiast zachorują na demencję, jeżeli będą zbyt długo leżeć obok namagnesowanych kluczy do mieszkania. Zniszczą dane i najpewniej także sam napęd, jeżeli będą brudne. Dziś nikt się tym już nie przejmuje. Życie stało się łatwiejsze, ale owa łatwizna potrafi za mocno rozleniwić.

Poza nośnikami danych, obsługa komputera wymaga również stosowania urządzeń peryferyjnych. Dziś wszystko jest na USB lub Bluetooth i potrafi automatycznie pobrać sterowniki z usługi aktualizacji lub repozytorium, jeżeli akurat brakuje ich w systemowym inwentarzu lub wśród modułów jądra. Przed popularyzacją USB stosowano znacznie prostszy port szeregowy o bardzo niskiej prędkości przesyłu (RS-232). Jest mniej funkcjonalny niż USB, ale jego prostota stanowi niewątpliwą zaletę podczas projektowania sprzętu. Do dziś wiele urządzeń oferuje interfejs szeregowy wyprowadzony wtykiem DB-9. „Uniwersalny” Port Szeregowy (od tego pochodzi skrót USB) okazuje się bowiem znacznie mniej uniwersalny i o wiele bardziej skomplikowany, niż interfejs, który wymaga jedynie dziewięciożyłowego kabla i informacji o prędkości transmisji (9600 bodów?).

Interfejs portu szeregowego, oznaczonego „COM”, był rozpowszechniony nie mniej, niż kontrolery dyskietek i z tego powodu był wbudowany w chipsety większości płyt głównych. Najczęstszym zastosowaniem portów COM było wykorzystanie ich do podpięcia myszki i modemu. Porty COM nie były interfejsem Plug-and-Play: zasób (IRQ 3 i 4 dla UART) był przydzielony dla portu, a nie dla urządzenia. Nie ma tutaj mowy o dynamicznej alokacji zasobów ani o rozpoznawaniu urządzeń. Zresztą z perspektywy systemu operacyjnego „urządzenie” już jest rozpoznane: jest nim port COM. Autodetekcja myszki szeregowej, dostępna w Windows 95, to efekt zgadywanki, a nie obsługi PnP. Dlatego sterowniki dla urządzeń COM są specyficzne. Mapują one funkcję ogólnego urządzenia (np. modemu) na komunikację z portem COM. W zupełnie inny sposób działa interfejs USB, który „rozwidla się” na dwa urządzenia, gdy coś zostanie podpięte do portu. Innymi słowy, w systemie widoczne są oddzielnie port i oddzielnie urządzenie. Prostota poprzednika USB pozwala nawiązać komunikację z urządzeniem nawet, jak niewiele o nim wiadomo oraz odtworzyć protokół komunikacji, gdy sterownik zaginął. Najgorsze, co może się stać, to otrzymanie śmieci na wyjściu. Taki projekt jest zaskakująco skuteczną postacią odporności na niekompatybilność wsteczną. Sterowniki dla urządzeń USB muszą być zgodne z systemem operacyjnym, a urządzenia COM działają jeżeli tylko w systemie jest sterownik – ale do portu COM! W ten sposób wszelkie antyczne modemy i terminale nie stanowią bariery i wciąż można się z nimi dogadać, nawet dziś. Interfejsy komunikacyjne obdarzone taką cechą, płynącą z prostoty, są dziś rzadkością. Gniazdo Thunderbolt 3 wymienia certyfikat cyfrowy podczas negocjowania połączenia i pozwala załadować wyłącznie podpisany firmware. Komunikacja, która przez nie przebiega jest bardzo skomplikowana, a w dodatku wymaga posiadania licencji. Aktualizacja systemu operacyjnego będzie wymagać nowej wersji sterownika (o ile ten powstanie). W międzyczasie, urządzenia komunikujące się przez COM będą działać tak samo.

Sprzęt wymagający bardziej skomplikowanej lub szybszej komunikacji był dostarczany w komplecie z dedykowaną kartą rozszerzeń (ISA). Należało umieścić ją wewnątrz komputera i załadować dla niej sterownik. Dopiero taki rodzaj urządzeń był z perspektywy komputera czymś nowym. Gniazda szeregowe (COM), port równoległy (LPT) i napędy dyskietek (FDD) istniały w systemie niezależnie od tego, czy coś było pod nie podpięte. To port i napęd były urządzeniem, a nie to, co było po drugiej stronie. Nawet, jeżeli nie były w użyciu, komputer przydzielał im przerwanie: miejsce na liście sprzętu do obsługi. Każda nowa karta rozszerzeń musiała otrzymać nowe przerwanie (IRQ). Wbudowane gniazda i napędy otrzymywały przerwania automatycznie, karta rozszerzeń musiała otrzymać nowe przerwanie podczas konfiguracji. Popularnym urządzeniem peryferyjnym obsługiwanym z wykorzystaniem dedykowanej karty rozszerzeń był skaner. Bardziej prozaicznym i powszechniejszym przykładem, również dostępnym w postaci karty, jest karta dźwiękowa.

Samo umieszczenie karty ISA w komputerze nie daje szczególnego efektu. Nie następuje żadna automatyczna detekcja ani konfiguracja urządzenia. Jedyne, co ma miejsce po wkręceniu nowej karty to obecność urządzenia reagującego (jakimś swoim działaniem) na zmiany pewnego obszaru pamięci komputera. Adres tego obszaru pamięci jest wbudowany w urządzenie, ewentualnie możliwy do wybrania z mało elastycznego zakresu za pomocą zworek. Jednak ani system nie wie, że ma cokolwiek pisać po owym obszarze pamięci, ani urządzenie nie musi wiedzieć, w jaki sposób zgłosić się po wysłanie danych. Aby umożliwić komunikację z kartą, urządzenie musi wysłać sygnał do procesora, aby ten przerwał pracę i odebrał komunikację z karty. Takim sygnałem jest przerwanie o określonym numerze. Na podstawie numeru przerwania, system wie któremu urządzeniu oddać kontrolę nad dostępem do pamięci. Niektóre urządzenia zawsze korzystają z jednego, konkretnego przerwania (co redukuje zbiór dostępnych konfiguracji). Inne, lepsze, pozwalają wybrać przerwanie zworką. Mądrzejsze karty da się skonfigurować z wykorzystaniem sterownika: zapisze on w oczekiwanym obszarze pamięci numer przerwania i dopiero po jego przeczytaniu, karta będzie używać konkretnego IRQ.

Zatem aby skorzystać z kart rozszerzeń, należy znać adresy pamięci, z których każda z owych kart będzie korzystać. Wiedza ta jest niezbędna, by nie doprowadzić do kolizji, w której kilka urządzeń pisze po tym samym obszarze pamięci, niszcząc nawzajem efekty swojej pracy. Ponadto, adres pamięci należy przekazać jako parametr do sterownika, ponieważ nie istniał mechanizm odpytywania urządzeń o adresy. Wreszcie, należało znać (i odpowiednio przydzielić, w razie możliwości) numer przerwania dla każdego urządzenia. Wprawni użytkownicy pecetów trzymali listę używanych obszarów pamięci i numerów przerwań (oraz kanałów DMA), przydatną podczas wprowadzania modernizacji. Konfiguracja z użyciem zworek i manualne ładowanie sterownika urządzenia pozwalały na pełną kontrolę nad tym, które urządzenie korzysta z których zasobów. Wszelkie problemy były możliwe do zdiagnozowania, podczas gdy jest to niemożliwe w przypadku interfejsów stosujących automatyczną konfigurację. Ręcznie przydzielając zasoby sprzętowe, użytkownik mógł się czuć właścicielem swojego sprzętu, nad którym ma pełną kontrolę.

Praktyka była jednak nieco inna. Przede wszystkim należy zadać sobie pytanie, dlaczego IBM nie zdecydował się na sztywne przydzielenie numerów przerwań i zakresów pamięci dla każdego gniazda ISA? Zlikwidowałoby to szansę na jakiekolwiek konflikty i sprowadziłoby konfigurację urządzenia do wyboru numerka. Oszczędzając wszystkim trudu tej szlachetnej, acz głupiej zabawy z przydzielaniem zakresów 0x03F8, 0x02F8, 0x0378. Wychodzi tu na jaw, jak mało przekonany był IBM co do szans na sukces swojego produktu PC. Sztywne przydzielenie zakresów wymagałoby stworzenia dedykowanego kontrolera przerwań (APIC) i przyspawałoby urządzenia peryferyjne do celowania w standard PC. IBM zakładał, że urządzenia peryferyjne będą uniwersalne, bo nikt nie odważy się projektować sprzętu pod komputer, którego za dwa lata może nie być na rynku... Gdy PC okazał się hitem, urządzenia peryferyjne rozpanoszyły się bez składu po całej pamięci i stosowały wszystkie możliwe kombinacje przerwań, przez co na naprawę tego stanu rzeczy było już za późno.

Ponieważ pecet był zbyt trudny do konfiguracji dla typowych użytkowników, a możliwość uporządkowania przydziału zasobów już zniknęła z horyzontu, rozwiązaniem było wprowadzenie automatycznej konfiguracji. Magistrala PCI, będąca następczynią szyny ISA, wykorzystuje kilka przerwań IRQ dla siebie i samodzielnie decyduje (zwłaszcza gdy zezwoli się jej na IRQ Steering, zresztą to nie do końca takie proste), które przydzielić której karcie, pozwalając jednocześnie na uwspólnienie jednego przerwania między wiele kart. Jeżeli karty ISA starego typu mają koegzystować z kartami PCI, konieczne jest wywłaszczenie i zarezerwowanie IRQ, de facto ukrywając je przed sterownikiem PCI. Jeżeli dwa urządzenia PCI wylosują to samo przerwanie i okazują się nieprawidłowo pracować w takim zestawieniu, mamy problem. To jednak rzadkość. O wiele częstsze problemy to konflikt między kartami PCI, a kartami ISA starego typu. PCI teoretycznie ma chronić i przed tym problemem: przemapować przerwania w locie, by „przekroczyć” urządzenia starego typu i nie dopuszczać do spotkania się kart PCI niezdolnych do gadania przez jedno przerwanie. Teoretycznie. Oznacza to, że zazwyczaj nie będziemy mieli problemów, ale gdy wystąpią, będą niemal niemożliwe do zdiagnozowania.

Powyższe zdanie jest doskonałym podsumowaniem źródeł nostalgii za dawnym sprzętem: komputerami o prostych, przewidywalnych interfejsach i pełnej kontroli nad pamięcią. Urządzenia firmy Apple były o wiele prostsze w montażu i nie wymagały szamańskich zabiegów przy ustawianiu przerwań i zakresów I/O, jednocześnie jednak pozbawiały użytkownika elastyczności. Dzisiejsze pecety składa się, jak z klocków. Istnieje tylko jedna właściwa metoda złożenia zestawu, a jeżeli jakiś sprzęt nie chce się dogadać z innym, bardzo rzadko jest nam dane poznać, dlaczego. Złożoność nowych, automatycznych interfesjów i protokołów wpędziła użytkowników w diagnostyczną bezradność, a jak pokazują ostatnie miesiące – także w spore kłopoty z bezpieczeństwem.

W kolejnej części zajmiemy się kwestiami oprogramowania i tym, w jaki sposób zmieniły się nasze scenariusze wykorzystania systemów. A czy ktoś z Was złożył lub planuje złożyć retro-peceta? Dajcie nam znać w komentarzach!