• CRC32, czyli pliki pod kontrolą

25.12.2010 10:13, autor artykułu: Jacek "pong777" Kremski
odsłon: 6718, powiększ obrazki, wersja do wydruku,

W ostatnich kilku latach trochę się dzieje w amigowym światku. To nowe płyty główne (Sam440), to nowe wersje systemów operacyjnych (AmigaOS 4.1, MorphOS 2.3), to nowi (starzy) amigowcy (chwała tym, co trwają bez przerw!), którzy albo odgrzebują sprzęt z rzadko przeglądanych szafek, zawalonych zbędnymi rzeczami strychów, czy też ciemnych, wilgotnych piwnic, albo polują na swoją nową przyjaciółkę, śledząc bacznie serwisy aukcyjne. Tak czy inaczej, moda na retro daje się zauważyć.

Nowych użytkowników klasycznej Amigi przyciąga jej legenda, a budząca się w nich ciekawość każe przekonać się na własnej skórze, które opowiadane o niej historie to całkowita prawda, a które przesadzone brednie. Spieszą więc oni na portale aukcyjne, by po kilku dniach podchodów, wypatrywania i rywalizacji cenowej pojąć za żonę tę jedyną, najpiękniejszą, prawie dziewiczą oblubienicę. Niewygórowane ceny sprzyjają zakupom. Większość miłośników Amigi może sobie pozwolić od razu na A1200, która ma spore możliwości rozbudowy i pozwala zagrać w większość klasycznych gier (tak, tych pięknych z czasów dzieciństwa, przy których zleciała niejedna noc). Na kupnie samego komputera, zasilacza i myszki zwykle się nie kończy. Ami dobrze jest wyposażyć w łatwo dostępne w Internecie dodatki typu adaptery kart Compact Flash do złącza IDE, czytniki kart Compact Flash na złącze PCMCIA, kartę sieciową LAN lub WLAN. Niezbędnym do korzystania z programu WHDLoad, umożliwiającego beztroskie i wygodne granie w gry wprost z dysku twardego, jest wyposażenie Amigi w rozszerzenie pamięci Fast. Bardziej przyszłościowym rozwiązaniem okazuje się nabycie karty turbo z procesorem z serii 68030. Przyspiesza ona komputer kilkakrotnie, a cena prostego rozwiązania nie przekracza dwukrotności ceny rozszerzenia pamięci. Apetyt rośnie w miarę jedzenia. Pewnego dnia przychodzi do głowy myśl, czy nie byłoby dobrze spróbować coś więcej zrobić na naszej ulubienicy... Obudowa, FastATA, mostek PCI, DVD, karta graficzna, mocna karta PPC i... mogą zacząć się problemy. Podstawowy to niedobór prądu i niestabilna praca, wyświetlanie czerwonych komunikatów "Guru" i przekłamania transmisji. Zużytego i wadliwego sprzętu również nie brakuje i trzeba spróbować sobie jakoś samemu radzić i okiełznać nieposłuszną przyjaciółkę.

Ten artykuł powstał z autopsji. Należę do rodzaju użytkowników Amigi, którzy porzucili ją na jakiś czas przesiadając się na PC. Aby sfinansować jego zakup, zmuszeni zostali sprzedać Amigę. A działo się to w czasach, gdy byliśmy jeszcze biednymi uczniami szkół podstawowych lub średnich. Teraz, już jako pracownicy lub właściciele własnych firm, jesteśmy na tyle zasobni (nie mamy co robić z zarabianymi pieniędzmi, żona ma nowe futro i nie wie, że istnieje WinUAE, w garażu błyszczą nowe 4 kółka, dziecko ma nowy wózek, a pieluchy tetrowe odeszły w zapomnienie), że możemy sobie pozwolić na spełnienie marzeń, które blokowały niedostateczne środki finansowe.

I stało się. Kupiłem po latach A1200 (poprzednio miałem A600 z 2 MB pamięci) oraz odrębnie kartę turbo. O ile sama Amiga działała, o tyle z kartą turbo nie było tak, jak powinno być. Gdy zgrywałem na dyskietki gry z plików ADF, często pojawiały się błędy odczytu z dyskietek, nawet nowych. Co do dyskietek byłem pewien w 100% ich jakości. Testowałem je na PC, jak i pod FileMasterem i nie miały błędów przy formatowaniu. Weryfikacja również przebiegła pomyślnie. Dodatkowo używanie karty turbo sporadycznie przyprawiało Amigę o samoczynne restarty. Skontaktowałem się z poprzednim właścicielem karty. Po raz kolejny zapewnił mnie, że u niego nie było żadnych problemów. Zgrywanie dyskietek bez użycia karty turbo szło pozytywnie. Gry wczytywały się, a system pracował stabilnie. Postanowiłem na własną rękę zabawić się w detektywa. Mając do dyspozycji Internet, czystą dyskietkę, Amigę 1200 z dyskami systemowymi rozwiązałem problem na dobre!

Poszlaka pierwsza - podejrzenia padają na kartę, gdyż tylko podczas jej obecności w Amidze zaczynają się problemy. Sprawdziłem kartę, nie grzała się za bardzo. Dodatkowo 68030 pobiera na tyle mało energii w stosunku do wydajniejszych modeli, że odrzuciłem hipotezę o zbyt słabym zasilaczu. Przeczyściłem tylko środkiem chemicznym złącze kart turbo na płycie głównej Amigi oraz zdemontowałem i zamontowałem ponownie kości pamięci na karcie. Niestety moje starania były bezowocne. Zastanawiającym był fakt przekłamywania zawartości dyskietek. Chciałem w jakiś sposób to sprawdzić. Wykluczyłem błędy spowodowane uszkodzeniem taśmy stacji dysków oraz samej stacji, gdyż przecież problem nie istniał, gdy karta turbo była odłączona. Ze strony karty zostają tylko: styk karty i płyty głównej Amigi, problemy z procesorem 030 lub problemy z modułem pamięci, zimne luty, przerwane ścieżki...

Na pierwszy ogień poszły kości pamięci. Potrzebowałem narzędzia, które potrafi wniknąć w plik i coś mi o nim więcej powiedzieć. Żmudne przeglądanie bajt po bajcie w hex edytorze FileMastera odpadało. Odpaliłem zatem jakiś znaleziony na dyskach po poprzednim właścicielu program typu memtest. Był szybki i błyskawicznie potraktował mnie przyjaznym komunikatem, że problemów z pamięcią nie znaleziono. Niespokojny postanowiłem użyć własnej metody sprawdzania zawartości plików - szybkiej, automatycznej i dającej jednoznaczną odpowiedź - angażującej nie tylko pamięć RAM, ale i procesor. Mowa o wyznaczaniu wartości CRC32 dla danego pliku.

CRC32 Jeśli plik na dyskietce i plik skopiowany do pamięci RAM będą miały taką samą wartość CRC32, oznacza to, że podczas transmisji danych z dyskietki do pamięci (lub w samej pamięci) nie występuje przekłamywanie danych. Algorytm można samodzielnie odszukać w sieci (dla dociekliwych). Nam wystarczy wiedzieć, że wynikiem jego działania jest zwrócenie liczby w systemie szesnastkowym z przedziału od 00 00 00 00 - FF FF FF FF oraz fakt, że modyfikacja (lub przekłamanie) chociażby jednego bajtu w pliku zwróci inną wartość CRC32. O ile na PC przydatnym narzędziem okazuje się być Total Commander, o tyle niestety system operacyjny Amigi nie posiada zainstalowanego domyślnie oprogramowania zdolnego do wyznaczania sum kontrolnych CRC32. Z pomocą przychodzi Aminet lub ambitniejsze rozwiązanie - napisanie własnego oprogramowania. Chciałem ambitnie podejść do sprawy i samodzielnie skompilować kod źródłowy, a następnie wykorzystać go na Amidze. Dzięki takiemu podejściu zawsze pozostaje mi możliwość wprowadzania zmian w kodzie i to jest to! Narzędzia długo nie musiałem szukać - sprawdziłem forum "Programowanie" na stronie PPA.PL i okazało się, że jego bywalcy polecają darmowy pakiet programistyczny o wszystko mówiącej nazwie AmiDevCPP. Jego główną zaletą jest jego powszechna dostępność, cena (0 zł!) i możliwość kompilacji kodu na różne platformy amigowe oraz systemy operacyjne, w tym głównie nas interesującą Amigę klasyczną z AmigaOS 3.x. Dodatkowo nie trzeba się martwić wymaganiami tego zintegrowanego środowiska (IDE), gdyż nie instalujemy go na Amidze, a na swoim PC! Na wyjściu dostajemy kod wykonywalny możliwy do uruchomienia na A1200. Warto wiedzieć, że programy skompilowane pod AmiDevCPP wymagają do uruchomienia biblioteki o nazwie ixemul.library. Jej wersje dostępne są na Aminecie.

Teraz pora na upolowanie w Internecie kodu źródłowego do wyznaczania sum kontrolnych CRC32. Google, po zadaniu zapytania, "CRC32" wyrzuca trochę stron. Pierwsza z nich to Wikipedia. Na niej skrótowo mamy opisaną definicję i krótko zasadę działania. Druga natomiast to ta strona. Właśnie to jest to! Bardziej szczegółowy opis oraz kod źródłowy mnie zadowolił.

CRC32 Kolejnym krokiem było wejście na stronę AmiDevCPP i pobranie instalatora (plik: AmiDevCpp_graceful_Bulldozer_v098_Setup.exe). Ważył ponad 160 MB, ale na łączu 8 Mb cały proces przebiegł szybko i sprawnie. Zainstalowałem oprogramowanie i uruchomiłem środowisko ze skrótu na pulpicie, który przed momentem się tam znalazł. Z menu "File" wybrałem pozycję "New", a następnie "Project". Następnie zainteresowałem się zakładką nr 3 - "Amiga_m68k" (projekt dla Amigi klasycznej) i ustawiłem typ projektu na "Hello World" (C Project). Pozostawiłem domyślną nazwę pliku na Project1 oraz kliknąłem w przycisk OK. Środowisko IDE zaproponowało mi zapisanie projektu. Tak też uczyniłem, umieszczając plik "Project1.dev" w folderze "Projekty" na dysku "C:". W oknie edycji kodu ujrzałem przykładowy program napisany w języku C. Jak nietrudno się domyślić, jego zadanie polega na wyświetleniu w Shellu napisu "Hello Amiga_m68k World!" oraz w nowej linii "Press ENTER to continue...". Jednak nie on jest naszym celem. Usunąłem cały kod źródłowy z okna edycji i wkleiłem "tak jak leciało" ten znaleziony na stronie 4programmers.net. Z menu "Execute" wybrałem pozycję "Rebuild All". Ponownie pokazał się monit z zapytaniem, gdzie zapisać plik. Wskazywał na folder "Projekty", więc tylko potwierdziłem przyciskiem "Save". Kompilator trochę pomruczał dyskiem i stworzył w folderze "Projekty" plik o nazwie "Project1.exe". Tak, na to właśnie czekałem! To nic innego jak gotowy do użycia na Amidze program stworzony w wiadomym celu. Zmieniłem mu nazwę na "CRC32.exe" - tak o wiele lepiej to wygląda.

Teraz przyszła kolej na dostarczenie pliku do Amigi. Wybrałem najprostszy sposób. Wyjąłem z szafki nową dyskietkę 1.44". Poszukałem taśmy izolacyjnej i starannie zakleiłem jej lewy górny róg (okienko) zarówno z przodu, jak i z tyłu dyskietki. Włożyłem dyskietkę do stacji PC z uruchomionym Windowsem XP. Uruchomiłem konsolę i wydałem polecenie:

format /N:9 /T:80

CRC32 Zatwierdziłem operację klawiszem enter. Sztuczka ta pozwala na sformatowanie dyskietki 1.44" jako dyskietki 720 kB widzianej przez Amigę! Następnie skopiowałem na nią plik "CRC32.exe" oraz plik biblioteki "ixemul.library". Plik pozyskałem rozpakowując archiwum z Aminetu. WinRAR którego posiadam na PC spokojnie radzi sobie z plikami w formacie LHA. W rozpakowanym archiwum znajdują się różne wersje biblioteki dla procesorów od 020 do 060 oraz z obsługą koprocesora. Ja wybrałem wersję ixemul-020.library.

Uruchomiłem Amigę i system AmigaOS 3.1 z dysku pod nazwą Workbench. Z menu "Workbench" wybrałem pozycję "Execute command". W okienku, które się pojawiło wpisałem "mount PC0:" i nacisnąłem przycisk "Execute". Włożyłem dyskietkę z PC. Workbench zobaczył dyskietkę. Wszedłem na jej zawartość i z menu "Window" wybrałem pozycję "Show", a następnie "All files". No i są! Amiga zobaczyła pliki zapisane przy pomocy PC. Plik CRC32.exe skopiowałem do katalogu "C" Workbencha a "ixemul" do "Libs". Dodatkowo zmieniłem im nazwy: bibliotekę przemianowałem na "ixemul.library" a "CRC32.exe" na "CRC32". Oto chwila prawdy...

Z menu "Workbench" wybrałem pozycję "Execute command". W okienku, które się pojawiło wpisałem "new cli" i nacisnąłem przycisk "Execute". W oknie konsoli wpisałem "CRC32" i wcisnąłem ENTER. Program przywitał mnie komunikatem:

CRC32 [file...]

Udało się! To działa! Program czeka na podanie nazwy pliku. Wpisałem zatem w konsoli:

CRC32 C:CRC32

Jako wynik otrzymałem komunikat:

CRC-32 (C:CRC32) = 5a691d69

Oznacza to, że program coś wyliczył i wyświetlił wynik na ekranie. To coś, to właśnie wartość sumy kontrolnej obliczonej za pomocą algorytmu CRC-32 dla pliku wykonywalnego tego programu, który znajduje się w katalogu C Amigi. Aby przekonać się, czy ta wartość jest prawidłowa, należy uruchomić program Total Commander na PC, wskazać plik "Project1.exe" z folderu "Projekty" i z menu "Plik" wybrać pozycję "Utwórz sumy kontrolne CRC" oraz potwierdzić przyciskiem "OK". W folderze projekty zostanie utworzony plik "Project1.sfv". Klikając na ten plik dwukrotnie lewym klawiszem myszy system Windows zaproponuje program, którym ma otwierać pliki z rozszerzeniem svf. Wybrałem systemowy notatnik jako program domyślny i zaznaczyłem checkboxa, aby za każdym razem "XP-ek" otwierał te pliki właśnie w notatniku. Po otwarciu tego pliku w notatniku ujrzałem napis:

Project1.exe 5a691d69

CRC32 Oba kody są identyczne. Oznacza to, że program na Amidze działa poprawnie! Ze względu na samodzielną kompilację kodu czytelnikowi może wyjść odmienna wartość sumy kontrolnej. Dzieje się tak dlatego, że mogą wystąpić różnice w wersji AmiDevCPP, której używał autor niniejszego artykułu, a dostępną obecnie i używaną przez czytelnika. Najważniejsze, aby wartość uzyskana za pomocą Total Commandera była identyczna z CRC32 używanym na Amidze.

Pełny radości, iż udało mi się samodzielnie uzyskać nowe, potężne narzędzie testów, przystąpiłem do dzieła. Wyczyściłem zawartość spreparowanej uprzednio dyskietki i zgrałem na nią dysk1.dms z PC. Zawierał on kopię moich dokumentów z Amigi. Za pomocą Total Commandera sprawdziłem wartość kodu CRC32 dla pliku na dyskietce. Następnie włożyłem dyskietkę do Amigi i w shellu wydałem polecenie:

CRC32 PC0:dysk1.dms

Amiga na chwilę zamarła, po czym wypluła wartość odpowiadającą tej z PC. Pomyślałem - "no ładnie, wszystko idzie zgodnie z planem". Przerzuciłem więc wspomniany plik do RAM Disku. Ponownie wydałem polecenie

CRC32 RAM:dysk1.dms

Ku mojemu zaskoczeniu wartość kodu zmieniła się! "Tu cię mam" - pomyślałem. Usunąłem plik z RAM Disku. Sprawdziłem jeszcze raz na dyskietce - wyszło pozytywnie. Przekopiowałem ponownie do RAM. Wykonałem test i otrzymałem błędną wartość. Następnie przekopiowałem plik ponownie, nie usuwając poprzedniego, a zmieniając jedynie jego nazwę na dysk2.dms. Wykonałem test. Otrzymałem pozytywny wynik! Tym razem się udało, a poprzednim razem nie? To jednoznaczny dowód na to, że pewien obszar pamięci Fast nie pracuje tak, jak powinien i dochodzi do przekłamywania danych. Plik dysk2.dms nie został uszkodzony, ponieważ kolejna część pamięci jest już sprawna i w niej nie dochodzi do przekłamań. Powtórzyłem cały test jeszcze raz otrzymując identyczne efekty. To już nie dzieje się losowo ani przypadkowo. Za każdym razem rezultat jest taki sam. Udało się znaleźć winowajcę.

Dla pewności zakupiłem na aukcji internetowej inną kostkę pamięci. Gdy dotarła zamontowałem i wykonałem testy. Tym razem ich rezultat był odmienny. Dostawałem zawsze poprawną wartość zarówno w pierwszym, jak i drugim przypadku. System przestał się restartować, komunikaty "Guru" przepadły. Od tej chwili jestem szczęśliwym posiadaczem A1200 z kartą turbo.

Opisaną metodą można sprawdzać poprawne działanie nie tylko pamięci RAM, ale i odczytu plików z kart CF przez port PCMCIA, interfejsy FastATA, 4xEIDE, dane na płytach DVD/CD, transfer plików z HTTP/FTP na dysk za pomocą karty sieciowej LAN/WIFI, działanie pendrive na USB itp. To jej przewaga nad programami typu memtest. W następnym artykule postaram się opisać jak przystosować kod źródłowy CRC32, aby potrafił nie tylko wyświetlać wartość sumy kontrolnej, ale również automatycznie dokonywał porównania plików wyświetlając komunikat "true" lub "false" i generował rezultat do pliku "*.svf" który następnie sprawdzi Total Commander (istotne przy przenoszeniu i weryfikacji poprawności danych z Amigi na PC).

Co to jest CRC?

CRC to skrót od angielskiego "cyclic redundancy check" (cykliczny kod nadmiarowy). Jest to matematyczna suma kontrolna pozwalająca zweryfikować poprawność i spójność danych, na przykład po przeniesieniu ich na nośniku danych na inny komputer. Wartość CRC jest resztą z binarnego dzielenia ciągu danych przez dzielnik, zwany generatorem lub wielomianem CRC. Najczęściej stosuje się wielomiany o długości 17 lub 33 bitów, dające odpowiednio wyniki 16- (CRC-16) i 32-bitowe (CRC-32).

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

    
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