Transcription

Dzień dobry. Zajmiemy się dziś niezwykle cenną zawartością tej oto bardzo wyjątkowej czarnej skrzynki. Próba utrzymania aury tajemniczości wokół tego urządzenia była kusząca, ale w zasadzie nie ma sensu. Charakterystyczny grill przedniego panelu i czerwony LED po lewej stronie od razu zdradzają, że mamy do czynienia z dyskiem twardym. Rzut oka na to, co znajduje się z tyłu może trochę zbić z tropu, bo to już raczej zapomniane złącza, ale za to gniazdo zasilania każdemu użytkownikowi peceta wyda się znajome. Tylko ta perforowana obudowa jakaś taka dziwnie niepecetowa. To dlatego, że mimo iż typ dysku faktycznie kojarzyć należy z pierwszymi komputerami PC, to ten konkretny egzemplarz podłączony był do Mary 400. Był on elementem minikomputera, który pracował na Politechnice Poznańskiej. A biorąc pod uwagę fakt, że był to jeden z najsilniejszych ośrodków, jeśli o rozwój oprogramowania dla Mary 400 chodzi, to potraficie sobie chyba wyobrazić, jak bezcennym skarbem są dla mnie zapisane na nim dane. Komputer, w którym dysk pracował, znalazł się w rękach Marcina z polskiejkomputery.pl, który podjął trudną, acz jedyną słuszną decyzję. Powierzył mi zadanie odczytania jego zawartości. Rozpakujmy więc prezent i pomyślmy, jak do tego podejść. Pierwsze, co obrzuca się w oczy po wyjęciu napędu, to trzydziestokilkuletni kurz o kolorze i zapachu tysięcy wypalonych klubowych. Ale nawet przez tę grubą warstwę możemy wreszcie przeczytać, z czym mamy do czynienia. NEC D5126 Wybaczcie, ale zanim przejdę do sedna, muszę najpierw zrobić coś z tym. Ponieważ miska z wodą raczej nie wchodzi w grę, a odkurzacz na niewiele by się tutaj zdał, to użyję wilgotnych ściereczek do czyszczenia ekranów. Powinny być wystarczająco skuteczne, a jednocześnie na tyle delikatne, żeby nie zmyć odręcznych opisów na etykietach na powierzchni obudowy. A to mogłoby się stać, gdybym użył izopropanolu. Rezultat przeszedł moje oczekiwania. Dysk nie tylko wygląda o niebo lepiej, ale przede wszystkim widać już, że jest w doskonałym stanie. A to tylko potęguje nadzieję na udany odczyt. Nie mówi to oczywiście nic o stanie nośnika, ale bądźmy dobrej myśli. Po tej kosmetyce zająłem się trochę dokładniej wyeksponowanymi częściami napędu zespołu głowic. Nie chciałbym, żeby coś później przeszkadzało w ich pozycjonowaniu. Przetarłem też przednią zaślepkę, o której zapomniałem wcześniej, a na koniec zająłem się złączami. Te wymagają osobnego potraktowania preparatem do czyszczenia styków, bo na ich powierzchni wciąż widać brunatny nalot. Po tych zabiegach dysk wygląda naprawdę niemal jak w lutym roku 1986, kiedy to został wyprodukowany. Na sam koniec zająłem się jeszcze obudową, w której dysk był zamontowany. I choć w tej historii jej rola skończyła się wraz ze sceną otwierającą odcinek, to postanowiłem zostawić to krótkie nagranie dla tych z Was, którzy, podobnie jak ja, zmywanie trzydziestoletniego brudu mogą uznać za satysfakcjonujące. No dobrze, ale wróćmy do gwiazdy dzisiejszego odcinka. Pierwsze pytanie, na które muszę odpowiedzieć, zanim zabiorę się za odczyt zawartości, to co to właściwie za urządzenie? Tego typu dyski nazywane były zwyczajowo Winchesterami lub dyskami MFM. Ale skoro dyski ze złączem SCSI nazywamy dyskami SCSI, a dyski ze złączem SATA nazywamy dyskami SATA, to te powinniśmy raczej nazywać dyskami ST506, bo tak właśnie nazywa się interfejs przez nieużywany. Tego interfejsu po raz pierwszy użył Seagate w roku 1980, wprowadzając na rynek pięciomegabajtowy dysk twardy o symbolu ST506. Później stał się on standardem dla pamięci masowych, używanych w pierwszych komputerach PC, XT i AT, skąd wzięła się jego popularność. Przed odczytem danych z powierzchni bohatera dzisiejszego odcinka trzeba będzie zrobić kilka eksperymentów. Zaopatrzyłem się więc w drugi egzemplarz, na którym będę mógł bezkarnie wszystko testować. Nie jest on już w pełni sprawny i, co najważniejsze, nie zawiera żadnych istotnych danych. Mogę więc równie dobrze z jego pomocą pokazać Wam, co siedzi w środku takiego dysku. A jest na co patrzeć. Model, z którym mamy do czynienia, pojawił się na rynku w roku 1984. Ma dwa talerze zapisywane dwustronnie przez razem cztery głowice. Na każdej powierzchni mamy 615 ścieżek, które standardowo formatowane były na 17 sektorów. Przy 512 bajtach na sektor daje to łączną pojemność około 200 megabajtów. Ciekawostką jest tutaj liniowy napęd zespołu głowic, nieco podobny do tych spotykanych w stacjach dyskietek. Za ich ruch odpowiada silnik krokowy, widoczny nawet bez otwierania dysku. Taki napęd głowic został bardzo szybko wyparty przez jego rotacyjny odpowiednik, który w całości, razem z talerzami, chowa się w obudowie dysku. Kiedy dysk jest wyłączony, głowice są mechanicznie zablokowane. Dopiero pojawienie się zasilania aktywuje elektromagnez, który działa z tego głowicą. Skoro doszliśmy już tak daleko, to równie dobrze możemy dysk uruchomić i popatrzeć, jak pracuje. Choć głównym powodem tych eksperymentów była ciekawość i chęć pokazania uroku tej mechaniki precyzyjnej sprzed lat, to mają one też swoją wartość. Wiem już, czego spodziewać się, kiedy włączę dysk, który będę odczytywał. Wiem już, jak na ucho powinien pracować silnik i jak brzmi sekwencja kalibrowania głowicy, którą widzieliśmy tuż po ustabilizowaniu prędkości silnika. Na koniec spróbuję jeszcze uchwycić przesunięcie głowic o jedną ścieżkę. Linijka dla skali. Ledwo ten ruch widać, bo na każdym milimetrze promienia talerza mieści się aż 27 ścieżek. No dobrze, ale wróćmy do meritum. Co dysk z peceta robił w merze 400? W połowie lat 80. pojawiły się dwa rozwiązania pozwalające na podłączenie tego typu pamięci masowych do naszego minikomputera. Jednym z nich były procesory peryferyjne produkowane przez Amepol. Drugim było rozwiązanie proponowane przez firmę Computex. I ten dysk podłączony był właśnie do takiego urządzenia. Składało się ono z dwóch części. Pierwsza oznaczona jest jako HDC-M400. To właściwy kontroler mieszczący się na dużym pakiecie. Druga część to wąski pakiet, którego jedynym zadaniem jest zasilanie dysku. 5V dostarczał wprost z platera systemu, a oprócz tego 15V używane przez system A400 regulował do 12V wymaganych przez dysk. Producent najwyraźniej bardzo nie chciał, żebyśmy odgadli jego architekturę, bo kluczowe układy mają oznaczenia wymazane papierem ściernym. Deasemblacja zawartości pamięci EEPROM zdradza, że procesor to 8085 Intera. Zgaduje w takim razie, że układ obok niego to pewnie 8237, kontroler DMA. Jeśli natomiast chodzi o układ bezpośrednio współpracujący z dyskiem, to oznaczenia na górze może i są starte, ale po opisach pod spodem można chips zidentyfikować jako WD2010 Western Digitala, kontroler dysków MFM. A ponieważ ten układ potrzebuje swojego własnego kawałka pamięci do przechowywania odczytanych sektorów, to chyba podejrzewam, czym są dwa kolejne układy ze startymi oznaczeniami. Niestety, tak czy inaczej, za pomocą tego kontrolera dysku nie odczytam. Nie odnalazła się jeszcze żadna jego dokumentacja i nie wiadomo ani jak kontrolera użyć, ani jak z nim rozmawiać. Poza tym ma on podejrzaną ilość przeróbek i nie wiadomo nawet, czy działa. Ale skoro zarówno dysk, jak i kontroler wywodzą się z lata pecetów, to jego odczytanie powinno być banalnie proste. Wystarczy wziąć odpowiednio starego peceta z odpowiednio starym kontrolerem, podłączyć dysk i po prostu go przeczytać, prawda? Jak zwykle sprawa nie jest taka prosta. Pozwólcie, że opowiem Wam historyjkę. Dawno, dawno temu, bo minęło od tego czasu niemal dokładnie 10 lat, chciałem odczytać dane z takiego samego dysku podłączonego do Mary 400, zapisanego podobnie niby pecetowym kontrolerem Amepolu. Pełen optymizmu zaopatrzyłem się więc w odpowiednio starą płytę główną i zainstalowałem w niej odpowiednio stary kontroler. Potem kupiłem drugi kontroler i trzeci, i czwarty. I mimo, że wszystkie one bez trudu czytały inne tego typu dyski, to z tym jednym szczególnym nie chciały się dogadać. Okazuje się, że choć wszystkie te dyski i kontrolery używają tego samego interfejsu, to niekoniecznie dysk zapisany jednym kontrolerem da się odczytać z użyciem innego. A ponieważ część ich parametrów określana jest przez programową konfigurację układu scalonego zapewniającego komunikację z dyskiem, to nawet dwa kontrolery zbudowane w oparciu o dokładnie ten sam układ scalony mogą obsługiwać dysk nieco inaczej. Dziś, podobnie jak te 10 lat temu, mam do czynienia z kontrolerem zbudowanym dla zupełnie innego systemu, który nie musi spełniać żadnych wymogów kompatybilności. A w dodatku używającym bardzo prostego układu z początków epoki interfejsu ST506. Biorąc więc pod uwagę moje wcześniejsze doświadczenia, nawet nie będę próbował odczytać tego dysku w pececie. Użyję innego sposobu. Takiego, którego z powodzeniem użyłem przed dziesięcioma laty. Żeby zrozumieć przyczynę niekompatybilności między kontrolerami dla dysków ST506 i znaleźć sposób na odczytanie danych, musimy spojrzeć na to, jak wygląda komunikacja kontrolera z takim dyskiem. Wszystkie bardziej współczesne dyski łączą się z komputerem za pomocą kabla będącego dedykowaną magistralą, a z punktu widzenia kontrolera płyną po prostu bajty informacji. Te bajty zorganizowane są w polecenia i odpowiedzi wymieniane między kontrolerem a dyskiem. Kontroler może na przykład poprosić dysk o blok danych numer 1234, a ten w odpowiedzi odeśle żądane 512 bajtów. I sprawa załatwiona. Kontroler nie wie nic o tym, gdzie te dane znajdują się na talerzu, ani w jaki sposób zostały tam zapisane i jak się do nich dostać. Wszystkim zajmuje się dysk. Sytuacja jest znacznie bardziej skomplikowana. Łączy się on z kontrolerem za pomocą dwóch wielopinowych złącz, ale trudno tutaj mówić o magistrali i przesyłaniu bajtów ułożonych w polecenia. W tym interfejsie mamy do czynienia ze zbiorem pojedynczych sygnałów, za pomocą których kontroler steruje wprost elektroniką i mechaniką dysku, a dysk osobnymi sygnałami informuje kontroler o swoim stanie. Odczyt sektora 1234 wyglądałby tutaj następująco. Przede wszystkim kontroler nie używa logicznych adresów bloków, a więc jeśli chcemy odczytać blok o numerze 1234, to program musi powiedzieć kontrolerowi, że chodzi o jedenasty sektor na cylindrze osiemnastym na powierzchni talerza numer zero. Pierwsza różnica jest więc taka, że kontroler musi rozumieć geometrię dysku. Żeby przeczytać dane z tego sektora, kontroler najpierw wybiera dysk, z którym chce się skomunikować z celindrem osiemnastym. Następnie musi ustawić głowicę na właściwie cylindrze. Żeby to zrobić, musi na bieżąco pamiętać, na którym cylindrze aktualnie się ona znajduje. Załóżmy, że jest to cylinder dwudziesty, a więc żeby ustawić głowicę na cylindrze osiemnastym, trzeba ją przesunąć o dwa cylindry w stronę zewnętrznej krawędzi dysku. Kontroler wysterowuje więc do dysku sygnał przesuwu głowic na zewnątrz i wysyła dwa sygnały z rób jeden krok, które powinny ustawić głowicę tam, gdzie trzeba. Następnie funkcjonowanie głowic zostało zakończone. Wtedy kontroler może aktywować głowicę zerową, pod którą spodziewa się sektora, o który poprosiliśmy. I tutaj dzieje się najciekawsze. Zauważcie, że do tej pory kontroler wciąż nie powiedział dyskowi, który sektor na ścieżce chce przeczytać. Jest tak dlatego, że ten dysk, w przeciwieństwie do współczesnych dysków, nie wie absolutnie nic na temat tego, jak dane są zorganizowane i zapisane na powierzchni jego talerzy. Czyli po jej wybraniu zaczyna do niego przesyłać sygnał, który głowica na bieżąco czyta z powierzchni dysku. Sygnał, nie dane. Jeśli zapisany byłby tam dźwięk, niczym na taśmie magnetofonowej, to taki sygnał powędrowałby do kontrolera. Prawie taki sam, bo jest on przez elektronikę dysku nieco przekształcany. Ale oczywiście to, co znajduje się na powierzchni dysku, zostało uprzednio zapisane również przez kontroler, więc sygnał płynący z głowic będzie miał dla niego sens. Kontroler taki sygnał na bieżąco analizuje, szukając w nim początku interesującego go sektora. Tutaj sektora o numerze 11. Kiedy rozpozna nagłówek sektora, jego rozkodowaną zawartość zacznie zapisywać w swojej pamięci buforowej. Następnie zweryfikuje sumę kontrolną odczytanych danych, przepisze je do pamięci komputera i poinformuje program, że dane zostały odczytane. Na koniec zdejmie sygnał aktywujący głowicę i będzie czekał na kolejne polecenie. Widzicie więc już, skąd mogą brać się niekompatybilności z tym interfejsem? To kontroler ma pełną władzę nad tym, w jaki sposób dane zostaną zapisane na powierzchni magnetycznej dysku. Wystarczy zmienić trochę format ścieżki, zmienić sposób liczenia sumy kontrolnej, a nawet trochę inaczej formować impulsy przesyłane przy zapisie do głowicy i cała kompatybilność idzie w malinę. Kontroler zrobiony dla Marek 400 nie musi zachowywać żadnej kompatybilności. Ale skoro interfejs ST506 pozwala nam z jednej strony a z drugiej daje dostęp do sygnału płynącego niemalże wprost ze ścieżki na talerzu, to problem braku kompatybilności między kontrolerami możemy całkowicie obejść, robiąc własny kontroler. Bardzo prosty i jednocześnie bardzo uniwersalny. Zrobimy tak. Podzielimy proces odczytu danych z dysku na dwa etapy. Akwizycji i analizy. W pierwszym etapie przeczytamy ścieżka po ścieżce sygnał, który jest zapisany na talerzach lub na boku w plikach. Niemal tak, jakbyśmy muzykę z taśmy magnetofonowej zgrywali przez wejście karty dźwiękowej i zapisywali na komputerze. W drugim etapie, analizy, ten surowy zapis sygnału odczytanego z powierzchni dysku przepuścimy przez program, również naszej produkcji, który sygnał przeanalizuje i da w wyniku zwykły bajtowy obraz całego dysku. Dzięki takiemu programowemu podejściu będziemy mogli dowoli zmieniać i poprawiać algorytm dekodowania sygnału i dopasować go dokładnie do tego, co robił kontroler Computexu, który jest zapisany. Takie dwuetapowe podejście ma też inną zaletę, która jest dla mnie bardzo istotna. Choć jestem pełen optymizmu, jeśli chodzi o sprawność tego dysku, to biorąc pod uwagę, jak cenne są dla mnie zapisane na nim dane, muszę brać pod uwagę najczarniejsze scenariusze. Dysk zostanie uruchomiony po raz pierwszy od 30 kilku lat. Nie wiem, czy jego mechanika ma przed sobą 5 lat czy 5 minut życia. Być może dysk uruchomi się tylko ten jeden, jedyny raz. Może wysiądzie napęd, może zatrze się łożysko, a z kolejnej ścieżki będzie zostawiała za sobą nieodwracalne uszkodzenie powierzchni. Nie wiem. Dlatego zależy mi na tym, żeby uniknąć eksperymentowania na żywym organizmie i żeby już pierwsza próba odczytu zawartości dała na 100% pozytywny skutek. A rozdzielenie samego procesu odczytywania sygnału od potencjalnie długotrwałych eksperymentów z jego analizą daje mi taką możliwość. Zacznijmy w takim razie od pierwszego kroku – procesu akwizycji. Przede wszystkim będziemy musieli dyskiem sterować. W sposób, o którym opowiadałem wcześniej, a więc wybierając dysk, wybierając głowicę, poruszając ją i sprawdzając kilka linii stanu. Wymagane sekwencje tych sygnałów sterujących można znaleźć w dokumentacji dowolnego dysku z interfejsem ST506. Ponieważ jest to proste manipulowanie sygnałami zerojedynkowymi, a wszystko może odbywać się bez szczególnego pośpiechu, to idealnie do tego zadania nada się jakiś prosty mikrokontroler. Dlatego sercem mojego sterownika stał się pierwszy lepszy Atmel wyciągnięty z szuflady. Z jednej strony podłączony jest bezpośrednio do sygnałów stanu i sterujących dysku, a z drugiej przez port szeregowy USB do peceta. Proste oprogramowanie mikrokontrolera będzie odczytywało polecenia wysyłane z komputera i zamieniało je na odpowiednie sekwencje sygnałów sterujących do dysku, a w odpowiedzi informowało o jego stanie. Kolejna sprawa to sygnał danych, który muszę jakoś zapisać do pliku. Dotrze on również do płytki uproszczonego sterownika, ale nim nie zajmie się mikrokontroler. Kolejny sygnał danych z dysku napięciowego do TTL wyślę do analizatora stanów logicznych. Analizator, podłączony do tego samego peceta co kontroler, będzie naszym urządzeniem do akwizycji danych. Za jego pomocą spróbuję ten sygnał z rozdzielczością 100 milionów sampli na sekundę i zapiszę do pliku. Razem z sygnałem z głowicy do analizatora dotrze jeszcze jeden sygnał – indeks. Za pomocą tego sygnału dysk krótkim impulsem informuje, jak działa sygnał i dzięki temu zapisywać do pliku obraz jednej pełnej ścieżki od początku do końca. Zobaczmy jeszcze najpierw, jak te dwa sygnały wyglądają w oprogramowaniu analizatora stanów logicznych. Wykorzystam tutaj po raz kolejny mój dysk do eksperymentów. Po wybraniu głowicy i włączeniu na jedną sekundę akwizycji danych, możemy na pierwszym kanale zobaczyć mnóstwo sygnałów początku ścieżki, w odstępach co 16 milisekund z ogonkiem. Nic dziwnego, bo talerz dysku kręci się z jednej strony, na drugim kanale mamy natomiast gęsty sygnał odczytany z jego powierzchni. Powiększając przebieg można dostrzec w nim regularności, które są odzwierciedleniem tego, jak dysk jest sformatowany. Ale analizą tego przebiegu zajmiemy się później. Nie mam oczywiście zamiaru każdej z tych prawie dwóch i pół tysiąca ścieżek próbkować ręcznie, klikając po programie dostarczonym z analizatorem stanów. Jego producent udostępnia również bibliotekę, która pozwala oprogramować całą pracę analizatora. Najpierw ustawi i aktywuje głowicę, komunikując się z naszym uproszczonym kontrolerem. Następnie zleci analizatorowi próbkowanie sygnału z dysku i wytnie jego fragment między dwoma kolejnymi impulsami sygnału indeks. Po czym przesunie głowicę dysku na kolejną ścieżkę, poinstruuje analizator, żeby ją spróbkował i tak w kółko aż nie zobrazuje ścieżek ze wszystkich czterech powierzchni na wszystkich 615 cylindrach dysku. I to już wszystkie elementy tej układanki. Czas więc na główny punkt programu. Gwiazdą na scenie jest oczywiście nasz staruszek dysk. Kontroler własnej konstrukcji i analizator stanów logicznych zagrają rolę drugoplanowe. A na trzecim planie wystąpi jeszcze niezbędny zasilacz. Dysk łączy się z kontrolerem taśmą, standardową dla takich dysków, a analizator wpina się do kontrolera w trzech punktach. Masa, sygnał indeks oraz sygnał danych. Analizator jak i kontroler podłączone są do sterującego wszystkim peceta za pomocą dwóch kabli USB. Wszystko połączone, a więc czas na chwilę prawdy. Czy dysk zadziała? Nie chce w ogóle wystartować. Coś piszczy, ale talerze dysku się nie kręcą. Spróbujmy jeszcze raz. Nic z tego. Nie chcę go w takim stanie zostawiać zasilanego na dłużej, bo nie wiem jakie mogą być tego konsekwencje. Dysk do eksperymentów startował natychmiast, więc z tym coś jest nie tak. Wygląda, że po 30 latach leżakowania łożysko się zastało i biedaczek nie może ruszyć. Ale wcześniejsze eksperymenty nauczyły mnie dwóch rzeczy. Po pierwsze, że dysk kręci się w lewo. A po drugie, że rotor silnika razem z talerzami jest bardzo ciężki, przez co ma sporą bezwładność. A to podsuwa mi pewien pomysł. Odpalimy nasz dysk na popych. Po tej interwencji wszystko brzmi jak trzeba. Wstępna kalibracja głowicy również zabrzmiała znajomo. Jesteśmy więc w domu i mogę uruchomić program, który będzie zarządzał całą operacją. Połączy się on najpierw z analizatorem stanów, co ten potwierdzi pulsującą zieloną diodą, a potem z kontrolerem i odda nam sterowanie. Wybiorę najpierw dysk, z którym będę pracował. Następnie sprawdzę jego stan i zweryfikuję, że głowice ustawiły się na ścieżce zerowej. Wykonam też dla testu pozycjonowanie głowicy i z powrotem na zerową, żeby zobaczyć, czy sterowanie działa. Głowica poprawnie wróciła na ścieżkę zerową, więc nie zwlekając już dłużej, mogę uruchomić proces obrazowania. Idzie to całkiem szybko, niemniej jednak 615 cylindrów to sporo. Wykonane obrazowanie dysku zajmie około 6 minut, a ja nie zadowolę się oczywiście jednym odczytem. Na wszelki wypadek wykonam ich kilka, nieco zmieniając po drodze ich warunki, co zwiększy moje szanse później. Któryś z obrazów może okaże się lepszy do analizy. Pierwszą zmienną będzie oczywiście temperatura. Każdy kolejny odczyt wykona się na nieco bardziej rozgrzanym dysku, co będzie miało wpływ zarówno na jego elektronikę, jak i mechanikę. Kolejny ruchem do wewnątrz, kolejny na zewnątrz i tak na zmianę. Określa to dodatkowy argument BW albo FW polecenia dump w moim programie. Jeśli mechanizm głowicy ma gdzieś jakieś luzy, to być może pozwoli to wybrać później odczyt, w którym pozycjonowanie było dokładniejsze. Podobny cel będzie miała kolejna zmienna. Pomiędzy odczytami wykonam czasem kilka dodatkowych, szybkich ruchów głowicą, w nadziei, że być może pomoże to rozruszać jakiś element mechaniki w czasie, gdzie nie trzeba. I jeszcze ostatnia zmienna. Dwa odczyty zrobię ustawiając dysk raz na lewym i raz na prawym boku. Nie wiem, czy to coś zmieni, ale dopóki grawitacja istnieje i może wpływać na pracę mechaniki, to warto się zabezpieczyć. Na marginesie robiłem to bardzo wolno, bo dysku podczas pracy nie powinno się obracać. Efekt żyroskopowy może spowodować uszkodzenie talerzy i głowic. Po zakończeniu ostatniego odczytu zostaje jeszcze jedna czynność porządkowa. Głowice od czasów, szczególnie takie z silnikiem krokowym, wymagały przed wyłączeniem zasilania zaparkowania głowic na nieużywanym cylindrze. Po to, żeby głowice przypadkiem nie uszkodziły zapisanej powierzchni talerza, co było szczególnie istotne, kiedy dysk miał być transportowany. Dlatego dysku cylinder parkingowy to 664. I gotowe. Zrobiłem łącznie pięć obrazów sygnału zapisanego na powierzchni dysku. To około 1000 plików, po jednym na każdą ścieżkę, zajmujących razem 500 megabajtów. W sumie 2,5 gigabajta danych, a więc całkiem sporo jak na 20-megabajtowy dysk. Teraz trzeba jeszcze jakoś tę binarną papkę zamienić na faktyczne dane, które ktoś 30 z hakiem lat temu zapisał na dysku. Ale tym zajmiemy się już w następnym odcinku. Do zobaczenia. Napisy stworzone przez społeczność Amara.org