DCM
From Atariki
| Wersja z dnia 17:34, 16 lut 2005 Tebe (Dyskusja | wkład) ← Previous diff |
Aktualna wersja 0xF (Dyskusja | wkład) (→Znane błędy i anomalie - literówka) |
||
| Linia 1: | Linia 1: | ||
| - | [[Disk Communicator]] | + | Format obrazu dyskietki wygenerowanego przez program [[Disk Communicator]]. |
| + | |||
| + | Wersja formatu - 3.2, rewizja 1.0, luty 1998. | ||
| + | |||
| + | ==Założenia ogólne== | ||
| + | Archiwum Disk Communicatora (zwanego dalej również Diskcommem) odzwierciedla zawartość dyskietki używanej przez ośmiobitowe | ||
| + | komputery Atari. W pliku archiwum przechowywane są informacje dotyczące formatu (gęstości) | ||
| + | oraz zawartość dyskietki. W celu zmniejszenia wielkości pliku dane poddawane są kompresji. Dla większych zbiorów danych istnieje możliwość podziału na mniejsze pliki, co z kolei pozwala na przechowanie ich na dyskietkach. | ||
| + | |||
| + | Dane na dyskietce dane są zapisane w sektorach. Sektory są ponumerowane od numeru 1. Dostępne są różne gęstości dyskietek. Najpopularniejsze to standardowe dyskietki, zapisane w gęstości pojedynczej (720 sektorów po 128 bajtów), rozszerzonej (1040 sektorów po 128 bajtów), bądź podwójnej (720 sektorów po 256 bajtów). Występują również inne formaty, ale gęstość pojedyncza lub rozszerzona używana jest najczęściej (przynajmniej na zachodzie Europy - ''przyp tłum.''.), ponieważ są wspierane przez stację [[1050]]. Inne formaty wymagają stacji [[XF551]], [[815]] lub urządzeń dedykowanych, takich jak Percom, [[Indus GT]], Trak, [[Black Box]] z kontrolerem dyskietek, [[Multi I/O|MIO]] z HDI itd. | ||
| + | |||
| + | Diskcomm zawsze użyje 1040 sektorów dla dyskietek w rozszerzonej gęstości, tak więc ten typ formatu jest zdefiniowany "na sztywno". Natomiast dla pojedynczej i podwójnej gęstości maksymalna ilośc sektorów może być ustawiana pomędzy 1 a 9999. Trzy pierwsze sektory każdej atarowskiej dyskietki mają rozmiar 128 bajtów, nawet w gęstości podwójnej. Diskcomm zachowuje te sektory jako 256-bajtowe, gdzie pozostałe 128 bajtów jest zerami. | ||
| + | |||
| + | Sektory dyskietki są przechowywane w archiwum w sekwencyjnie i są skompresowane. | ||
| + | Podczas tworzenia archiwum Diskcomm bada zawartość każdego sektora i w zależności od niej | ||
| + | stosuje odpowiedni algorytm kompresji. Sektory zawierające same zera traktowane są jako | ||
| + | puste i nie są umieszczane w archiwum. Ustawiana jest jedynie flaga w informacji opisującej | ||
| + | poprzedni niepusty sektor. Wskazuje ona na następny sektor zawierający dane i w ten sposób | ||
| + | sektory puste są "przeskakiwane". Program zakłada, że dyskietka, na którą zostanie | ||
| + | wypakowane archiwum, zostanie przedtem sformatowana (wypełniona zerami), dlatego nie ma potrzeby trzymania pustych sektorów w archiwum. | ||
| + | |||
| + | Dla sektorów zawierających dane zawartość sektora jest porównywana z zawartością sektora | ||
| + | poprzedzającego go (ostatniego również zawierającego dane). Puste sektory nie mają wpływu | ||
| + | na to porównanie, ponieważ i tak zostają pominięte. Jak wspomniano wcześniej, odpowiednia | ||
| + | flaga wskazuje następny sektor zawierający danet. Jeżeli według tej flagi następny sektor | ||
| + | rzeczywiście zawiera dane, wtedy numer danego sektora zostaje dołączony do bufora archiwum | ||
| + | (w formacie młodszy/starszy bajt). Potem następuje próba kompresji tego sektora. | ||
| + | Zastosowane mogą tu być cztery różne algorytmy kompresji. Każdy z nich jest kolejno | ||
| + | przeprowadzany na sektorze i jeżeli kompresja się powiedze, dane skompresowane dołączane są | ||
| + | do bufora archiwum wraz z informacją o metodzie ich kompresji. Starsze wersje Diskcomma używały jeszcze piątego algorytmu, został on jednak zarzucony na rzecz | ||
| + | pozostałych czterech, które są użyte w ostatniej dostępnej wersji Disk Communicatora. Mogą | ||
| + | się jednak trafiać starsze archiwa, gdzie ów piąty algorytm jest użyty. Jeżeli dane z | ||
| + | sektora nie mogą zostać skompresowane przez żaden z czterech algorytmów, zostają one | ||
| + | zachowane w postaci nieskompresowanej. | ||
| + | |||
| + | Proces kompresji sektorów postępuje aż dostępna pamięć się zapełni lub kiedy nie będzie już | ||
| + | więcej sektorów do skompresowania. Ze wględu na ograniczenia pamięci, bufor archiwum może | ||
| + | pomieścić tylko do 24 kB danych, tak że przed próbą dołączenia danych do bufora już pełnego | ||
| + | jest on najpierw zgrywany na dysk (a następnie czyszczony). System mający do dyspozycji | ||
| + | więcej niż 64 kB pamięci, może utworzyć większą ilość takich buforów (i następnie ich użyć). | ||
| + | |||
| + | Zapełnienie każdego z nich przedstawione jest jako kolejny etap (pass) kompresji dysku. | ||
| + | Jest on jest niezdefiniowaną liczbą skompresowanych sektorów i jest uważany za kompletny | ||
| + | kiedy w buforze zostanie zgromadzine $5F02 (dziesiętnie: 24322) lub więcej bajtów. | ||
| + | Następnie zostaje dołączona informacja o końcu tego etapu. Długość etapu nie może wynieść | ||
| + | więcej niż $6002 (dziesiętnie: 24578) bajtów. Każdy z etapów rozpoczyna dwubajtowy | ||
| + | nagłówek. Pierwszy bajt może być równy $FA lub $F9. Jeżeli archiwum jest podzielone na | ||
| + | kilka plików zawiera on wartość $F9, w wypadku jednoplikowego archiwum znajduje się tam | ||
| + | $FA. Drugi bajt nagłówka natomiast zawiera aż trzy informacje. Format oryginalnej dyskietki jest wskazywany przez bit 5 i 6. Wartość bitowa 00 jest użyta dla gęstości pojedynczej, 01 - dla rozszerzonej, 10 - dla podwójnej, 11 jest wartością niezdefiniowaną. Bity od 0 do 4 użyte są do oznaczenia ilości etapów. Każdy z etapów jest numerowany kolejno, poczynając od 1, także (używając pięciu bitów) maksymalna ich liczba sięga 31. Tak więc maksymalna wielkość archiwum to około 744 kB (~24 kB x 31), chyba że numer etapu będzie mógł z powrotem wskazać zero. Bit 7 drugiego bajtu natomiast jest ustawiany kiedy aktualny etap jest etapem ostatnim. | ||
| + | |||
| + | Skoro kompresja rozpoczyna się zanim użytkownik zostanie zapytany co dalej robić, pytanie o ewentualny podział archiwum na mniejsze pliki pojawia się tylko wtedy, kiedy są przynajmniej 2 etapy. W wypadku, kiedy jest tylko jeden, pytanie to nie występuje, a archiwum jest tworzone z nagłówkiem typu $FA. Pierwszy sektor w obrębie etapu jest zawsze poprzedzony numerem tego sektora. | ||
| + | |||
| + | ==Opis formatu== | ||
| + | wszystkie podane niżej wartości zapisane są w systemie heksadecymalnym | ||
| + | |||
| + | <pre> | ||
| + | <Archiwum Diskcomm> = {etap} | ||
| + | <etap> = <typ archiwum> <informacja o etapie> <numer sektora> {dane sektora} <koniec etapu> | ||
| + | <informacja o etapie> = <flaga ostatniego etapu> + <typ dyskietki> + <numer etapu> | ||
| + | <dane sektora> = <typ zawartości> [dane skompresowane] [numer sektora] | ||
| + | <typ zawartości> = <flaga sekwencyjna> + <typ kompresji> | ||
| + | <typ archiwum> = F9 | FA | ||
| + | <flaga ostaniego etapu> = 00 | 80 | ||
| + | <typ dyskietki> = 00 | 20 | 40 | ||
| + | <koniec etapu> = 45 | ||
| + | <flaga sekwencyjna> = 00 | 80 | ||
| + | <typ kompresji> = 41 | 42 | 43 | 44 | 46 | 47 | ||
| + | <numer sektora> = 0001 - 270F | ||
| + | <number etapu> = 01 - 1F | ||
| + | <dane skompresowane> = zawartość sektora, zobacz niżej | ||
| + | </pre> | ||
| + | |||
| + | ==Dokładny opis formatu== | ||
| + | *archiwum Disk Communicatora - składa się z jednego lub więcej etapów. W przypadku, gdy archiwum jest rozbite na wiele plików, każdy z tych etapów jest zapisany w osobnym pliku | ||
| + | *etap - Składa się kolejno z: typu archiwum, informacji o etapie, sektora startowego, jednego lub więcej pakietów z danymi sektorów oraz kodu końca etapu | ||
| + | *typ archiwum - wskazuje czy jest to archiwum wieloplikowe ($F9) czy nie ($FA) | ||
| + | *dane sektora - pakiet danych sektora składa się z jednego bajtu wskazującego typ zawartości danych sektora. Bezpośrednio po nim znajduje się blok skompresowanych danych. Długość jego zależy od typu kompresji i może wynieść od zera do długości sektora na dysku (czyli maksymalnie 128 lub 256 bajtów). Najstarszy bit bajtu symbolizującego typ zawartości wskazuje czy za danymi skompresowanymi pojawi się numer sektora czy nie. Jeżeli jest skasowany to numer sektora pojawi się za danymi, jeżeli ustawiony - nie pojawi się on tam | ||
| + | *flaga sekwencyjna - wskazuje ona czy pakiet sektora zawiera jego numer czy nie. Jeżeli ma wartość 80, numer sektora znajduje się za jego danymi a następny sektor jest kolejnym sektorem archiwum | ||
| + | *typ zawartości - najstarszy bit jest flagą sekwencyjną. Pozostałe młodsze bity wskazują typ kompresji | ||
| + | *numer sektora - bez znaku, a więc zawsze dodatni. Składa się z dwóch bajtów. Pierwszy jest młodszym elementem ich ogólnej liczby, drugi - starszym. Normalnie zawiera się w domkniętym przedziale od 1 do 9999 dziesiętnie | ||
| + | *numer etapu - kolejny numer dowiązany do każdego z etapów. Normalnie zawiera się w domkniętym przedziale od 1 do 31 dziesiętnie. Może się "przekręcić" do zera po przekroczeniu 31 | ||
| + | *koniec etapu - wartość $45 | ||
| + | *typ kompresji - jedna z następujących wartości: $41, $42, $43, $44, $46 lub $47. Znaczenie ich jest opisane niżej | ||
| + | |||
| + | ===Typ 41 - początek zmian=== | ||
| + | |||
| + | Kompresja jest względna w stosunku do poprzedniego sektora. Dane sektora zawierają tylko | ||
| + | jego początkową porcję. Ostatnia porcja nie jest zmieniona. Pierwszy bajt danych sektora | ||
| + | wskazuje od jakiego offsetu zacząć modyfikację sektora. Kolejne bajty są użyte do | ||
| + | modyfikacji początkowej porcji sektora. Modyfikacja ta ma miejsce zaczynając od bajtu z | ||
| + | początkowym offsetem w stronę początku sektora, czyli pierwszego bajtu w tym sektorze | ||
| + | (offset 0). Sugeruje to, że bajty danych są zapisywane w sektorze w odwrotnej kolejności. | ||
| + | |||
| + | ===Typ 42 - 128-bajtowy DOSowy sektor=== | ||
| + | |||
| + | Jest to przestarzały typ kompresji, używany we wcześniejszych wersjach Disk Communicatora. | ||
| + | Miały one wsparcie jedynie dla pojedynczej gęstości, gdzie sektor miał zawsze długość 128 | ||
| + | bajtów. Wszystkie wersje Diskcomma przy dekodowaniu archiwów wspierają tę metodę. | ||
| + | Nie jest zalecane natomiast tworzenie nowych archiwów za pomocą starszych wersji programu. | ||
| + | Dane sektora zawierają się w 5 bajtach. Pierwszy bajt użyty jest do zainicjowania | ||
| + | pierwszych 124 bajtów sektora. Pozostałe cztery są zapisane w ostanich czterech bajtach | ||
| + | sektora. | ||
| + | |||
| + | ===Typ 43 - sektor skompresowany=== | ||
| + | |||
| + | Dane sektora zawierają fragmenty ciągu. Zmieniają się one pomiędzy nieskompresowanymi a | ||
| + | skompresowanymi, zaczynając od nieskompresowanego fragmentu.. Każdy z tych fragmentów | ||
| + | rozpoczyna się od bajtu wskazującego offset wskazujący koniec danych w sektorze. Kiedy | ||
| + | pozycja końcowa jest osiągnięta, osiągnięty jest również koniec fragmentu ciągu a bajt | ||
| + | znajdujący się na tej pozycji jest równocześnie początkiem kolejnego fragmentu. Pozycja | ||
| + | startowa pierwszego fragmentu ciągu ma offset zerowy. Nieskompresowany fragment zawiera tyle | ||
| + | bajtów, ile jest potrzebne na wypełnienie sektora, natomiast nie zawiera końcowego offsetu. | ||
| + | |||
| + | W przypadku nieskompresowanych fragmentów, gdy początkowy offset jest równy końcowemu, nie | ||
| + | ma więcej danych, efektem jest ciąg zerowy. Jest to używane wtedy, gdy mamy dwie porcje | ||
| + | danych w obrębie sektora, który można skompresować, bez innych danych pomiędzy tymi | ||
| + | porcjami. Stąd obecność nieskompresowanego fragmentu ciągu oraz użycie ciągu zerowego. | ||
| + | Skompresowane fragmenty ciągu mają zawsze długość dwóch bajtów. Pierwszy z tych wskazuje na | ||
| + | końcowy offset, natomiast drugi stanowi znaki wypełnienia. Część sektora począwszy od | ||
| + | startowego offsetu w stronę końcowego (ale już bez niego) jest wypełniana właśnie tym | ||
| + | znakiem. Po skompresowanym fragmencie następuje kolejny nieskompresowany. | ||
| + | |||
| + | Dla dyskietek w podwójnej gęstości, końcowy offset ostatniego fragmentu ciągu jest równy | ||
| + | 256. Ponieważ tylko jeden bajt symbolizuje offset końcowy, wówczas znajduje się tam zero. | ||
| + | Jednakże zero jest offsetem używanym dla pierwszego nieskompresowanego ciągu, w celu | ||
| + | oznaczenia, że jest on ciągiem zerowym. Tak więc koniec skompresowanego sektora tego typu | ||
| + | jest osiągnięty, kiedy wszystkie bajty jego zostaną przetworzone. Może to nastąpić na końcu | ||
| + | nieskompresowanego fragmentu ciągu. W takim przypadku po nieskompresowanym fragmencie nie | ||
| + | wystąpi fragment skompresowany. Podobnie po skompresowanym fragmencie ciągu (również wtedy | ||
| + | kolejny fragment nie będzie w postaci skompresowanej). | ||
| + | |||
| + | ===Typ 44 - koniec zmian=== | ||
| + | |||
| + | Kompresja ta jest względna wobec poprzedniego sektora. Dane sektora zawierają tylko | ||
| + | fragment końcowy. Fragment początkowy nie jest tu zmieniany. Pierwszy bajt danych sektora | ||
| + | wskazuje od jakiego miejsca należy zacząć modyfikować sektor. Pozostałe bajty są używane do | ||
| + | zmiany końcowego fragmentu sektora. Modyfikacja ta rozpoczyna się od bajtu wskazywanego | ||
| + | przez początkowy offset aż do ostatniego bajtu w sektorze, włącznie z nim. | ||
| + | |||
| + | ===Typ 45 - koniec etapu=== | ||
| + | |||
| + | Ten typ kompresji wskazuje na koniec etapu, nie jest więc rzeczywistym typem kompresji. Dla | ||
| + | tego typu nie ma żadnych danych sektora. Dla wieloplikowego archiwum oznacza on koniec | ||
| + | danego pliku. Archiwum jest kontynuowane w następnym pliku, chyba że dany etap jest etapem | ||
| + | ostatnim. Dla archiwów jednoplikowych wskazuje on, że po danym etapie nastąpi kolejny, pod | ||
| + | warunkiem, że dany nie jest etapem ostatnim. Kolejny etap rozpoczyna się nagłowkiem, po | ||
| + | którym następuje numer sektora. | ||
| + | |||
| + | ===Typ 46 - to samo co poprzednio=== | ||
| + | |||
| + | Ten typ kompresji oznacza, że zawartość danego sektora, jest identyczna z zawartością | ||
| + | poprzedniego, niepustego sektora. Dla tego typu również nie ma danych sektora. | ||
| + | |||
| + | ===Typ 47 - nieskompresowany sektor=== | ||
| + | |||
| + | Dane sektora zawierają liczbę bajtów potrzebnych do wypełnienia całego sektora, czyli 128 | ||
| + | lub 256. W sektorze tego typu nie jest zastosowana żadna metoda kompresji. | ||
| + | |||
| + | ===Poprzedni sektor=== | ||
| + | |||
| + | Bufor trzymający dane poprzedniego niepustego sektora jest inicjowany na początku etapu w | ||
| + | przypadku, gdy archiwum jest wieloplikowe. Dla jednoplikowych archiwów bufor ten czysczony | ||
| + | jest tylko na początku pierszego etapu. | ||
| + | |||
| + | ==Znane błędy i anomalie== | ||
| + | |||
| + | Specyfikacja pliku może wywołać niekiedy pewne anomalie. Jeżeli ostatni sektor w etapie | ||
| + | zawiera ustawioną flagę, że musi nastąpić po nim numer sektora, numer ten nie ma znaczenia, | ||
| + | ponieważ kolejny etap rozpoczyna się zawsze numerem sektora. Diskcomm może nie mieć | ||
| + | dostępnego kolejnego sektora. Zatem nie zawsze może on stwierdzić czy następny sektor jest | ||
| + | pusty, czy nie. Skoro numer sektora musi musi być dołączony przy ustawieniu tej flagi, | ||
| + | podawany jest fałszywy numer. Użyta jest do tego wartość $0045. Jest to również prawdziwe w | ||
| + | przypadku ostatniego etapu. Podana wartość jest zapisana w kolejności młodszy/starszy bajt. | ||
| + | Diskcomm przetwarza sektory w porcjach po 18 sektorów bądź po 9 sektorów, w przypadku | ||
| + | dyskietki zapisanej w podwójnej gęstości. Porcje te mogą zawierać puste sektory. Po | ||
| + | ostatnim sektorze w porcji zawsze następuje numer sektora, ponieważ Diskcomm nie czyta z | ||
| + | wyprzedzeniem by stwierdzić zawartośc kolejnego sektora. Nie jest to jednak wymogiem. Przy | ||
| + | tworzeniu archiwum, Diskcomm czasem to robi, ale tylko wtedy, kiedy kolejny sektor nie jest | ||
| + | pusty. | ||
| + | |||
| + | Wygląda na to, że Diskcomm ma nieco problemów z niektórymi archiwami. Sektory w podwójnej | ||
| + | gęstości mają długość 256 bajtów. Jeżeli bufor zawiera $5EFF bajtów, sektor nie może być | ||
| + | skompresowany a musi być jeszcze dołączony numer sektora, musimy dodać 259 bajtów do bufora. | ||
| + | Żeby zaznaczyć koniec etapu, musimy dołożyć jeszcze jeden bajt o wartości $45 lub $45 $00 | ||
| + | $45. Może to dodać do trzech dodatkowych bajtów. Długość etapu wtedy będzie wynosić $6003 | ||
| + | bajty, co z kolei przekracza jego dopuszczalną długość ($6002 bajty). Podczas odczytu też | ||
| + | jest problem. Diskcomm nie zachowa dwóch pierwszych bajtów, ponieważ są one czytane i | ||
| + | przetwarzane jako pierwsze. Następnie próbuje odczytać kolejnych $6000 bajtów. Ale w obrębie | ||
| + | ich musi być zawarty kod końca etapu. Jednak gdy ten się nie pojawi, Diskcomm nie będzie w | ||
| + | stanie przetworzyć pliku. Problem ten może wystąpić tylko w przypadku dyskietek zapisanych | ||
| + | w podwójnej gęstości i przy wyjątkowo niesprzyjających okolicznościach. | ||
| + | |||
| + | Kiedy etap zawiera dokładnie $6002 bajty, Diskcomm zakończy pracę po nim. Dlatego etapy | ||
| + | muszą być krótsze niż $6002 bajty. Może to wystąpić tylko przy archiwach dyskietek w | ||
| + | podwójnej gęstości. | ||
| + | |||
| + | Z nieznanych powodów etapy powyżej numeru 31 mają numer zmniejszony o 1. Zapisuje się | ||
| + | tylko pięć młodszych bitów. | ||
| + | |||
| + | Dla wieloplikowych archiwów, wybrany znak w nazwie pliku jest zwiększany dla każdego etapu. | ||
| + | Może to wywołać użycie niewłaściwego znaku w nazwie, w zależności od ograniczeń narzucanych | ||
| + | przez [[DOS]]a. | ||
| + | |||
| + | ==Dekompresja DCM== | ||
| + | Plik DCM może zdekompresować do postaci ATR np. emulator [[atari800]]. | ||
| + | |||
| + | |||
| + | [[Kategoria:Atari 8-bit]] | ||
| + | [[Kategoria:Formaty plików]] | ||
| + | [[Kategoria:Obrazy dyskowe 8bit]] | ||
Aktualna wersja
Format obrazu dyskietki wygenerowanego przez program Disk Communicator.
Wersja formatu - 3.2, rewizja 1.0, luty 1998.
Spis treści |
Założenia ogólne
Archiwum Disk Communicatora (zwanego dalej również Diskcommem) odzwierciedla zawartość dyskietki używanej przez ośmiobitowe komputery Atari. W pliku archiwum przechowywane są informacje dotyczące formatu (gęstości) oraz zawartość dyskietki. W celu zmniejszenia wielkości pliku dane poddawane są kompresji. Dla większych zbiorów danych istnieje możliwość podziału na mniejsze pliki, co z kolei pozwala na przechowanie ich na dyskietkach.
Dane na dyskietce dane są zapisane w sektorach. Sektory są ponumerowane od numeru 1. Dostępne są różne gęstości dyskietek. Najpopularniejsze to standardowe dyskietki, zapisane w gęstości pojedynczej (720 sektorów po 128 bajtów), rozszerzonej (1040 sektorów po 128 bajtów), bądź podwójnej (720 sektorów po 256 bajtów). Występują również inne formaty, ale gęstość pojedyncza lub rozszerzona używana jest najczęściej (przynajmniej na zachodzie Europy - przyp tłum..), ponieważ są wspierane przez stację 1050. Inne formaty wymagają stacji XF551, 815 lub urządzeń dedykowanych, takich jak Percom, Indus GT, Trak, Black Box z kontrolerem dyskietek, MIO z HDI itd.
Diskcomm zawsze użyje 1040 sektorów dla dyskietek w rozszerzonej gęstości, tak więc ten typ formatu jest zdefiniowany "na sztywno". Natomiast dla pojedynczej i podwójnej gęstości maksymalna ilośc sektorów może być ustawiana pomędzy 1 a 9999. Trzy pierwsze sektory każdej atarowskiej dyskietki mają rozmiar 128 bajtów, nawet w gęstości podwójnej. Diskcomm zachowuje te sektory jako 256-bajtowe, gdzie pozostałe 128 bajtów jest zerami.
Sektory dyskietki są przechowywane w archiwum w sekwencyjnie i są skompresowane. Podczas tworzenia archiwum Diskcomm bada zawartość każdego sektora i w zależności od niej stosuje odpowiedni algorytm kompresji. Sektory zawierające same zera traktowane są jako puste i nie są umieszczane w archiwum. Ustawiana jest jedynie flaga w informacji opisującej poprzedni niepusty sektor. Wskazuje ona na następny sektor zawierający dane i w ten sposób sektory puste są "przeskakiwane". Program zakłada, że dyskietka, na którą zostanie wypakowane archiwum, zostanie przedtem sformatowana (wypełniona zerami), dlatego nie ma potrzeby trzymania pustych sektorów w archiwum.
Dla sektorów zawierających dane zawartość sektora jest porównywana z zawartością sektora poprzedzającego go (ostatniego również zawierającego dane). Puste sektory nie mają wpływu na to porównanie, ponieważ i tak zostają pominięte. Jak wspomniano wcześniej, odpowiednia flaga wskazuje następny sektor zawierający danet. Jeżeli według tej flagi następny sektor rzeczywiście zawiera dane, wtedy numer danego sektora zostaje dołączony do bufora archiwum (w formacie młodszy/starszy bajt). Potem następuje próba kompresji tego sektora. Zastosowane mogą tu być cztery różne algorytmy kompresji. Każdy z nich jest kolejno przeprowadzany na sektorze i jeżeli kompresja się powiedze, dane skompresowane dołączane są do bufora archiwum wraz z informacją o metodzie ich kompresji. Starsze wersje Diskcomma używały jeszcze piątego algorytmu, został on jednak zarzucony na rzecz pozostałych czterech, które są użyte w ostatniej dostępnej wersji Disk Communicatora. Mogą się jednak trafiać starsze archiwa, gdzie ów piąty algorytm jest użyty. Jeżeli dane z sektora nie mogą zostać skompresowane przez żaden z czterech algorytmów, zostają one zachowane w postaci nieskompresowanej.
Proces kompresji sektorów postępuje aż dostępna pamięć się zapełni lub kiedy nie będzie już więcej sektorów do skompresowania. Ze wględu na ograniczenia pamięci, bufor archiwum może pomieścić tylko do 24 kB danych, tak że przed próbą dołączenia danych do bufora już pełnego jest on najpierw zgrywany na dysk (a następnie czyszczony). System mający do dyspozycji więcej niż 64 kB pamięci, może utworzyć większą ilość takich buforów (i następnie ich użyć).
Zapełnienie każdego z nich przedstawione jest jako kolejny etap (pass) kompresji dysku. Jest on jest niezdefiniowaną liczbą skompresowanych sektorów i jest uważany za kompletny kiedy w buforze zostanie zgromadzine $5F02 (dziesiętnie: 24322) lub więcej bajtów. Następnie zostaje dołączona informacja o końcu tego etapu. Długość etapu nie może wynieść więcej niż $6002 (dziesiętnie: 24578) bajtów. Każdy z etapów rozpoczyna dwubajtowy nagłówek. Pierwszy bajt może być równy $FA lub $F9. Jeżeli archiwum jest podzielone na kilka plików zawiera on wartość $F9, w wypadku jednoplikowego archiwum znajduje się tam $FA. Drugi bajt nagłówka natomiast zawiera aż trzy informacje. Format oryginalnej dyskietki jest wskazywany przez bit 5 i 6. Wartość bitowa 00 jest użyta dla gęstości pojedynczej, 01 - dla rozszerzonej, 10 - dla podwójnej, 11 jest wartością niezdefiniowaną. Bity od 0 do 4 użyte są do oznaczenia ilości etapów. Każdy z etapów jest numerowany kolejno, poczynając od 1, także (używając pięciu bitów) maksymalna ich liczba sięga 31. Tak więc maksymalna wielkość archiwum to około 744 kB (~24 kB x 31), chyba że numer etapu będzie mógł z powrotem wskazać zero. Bit 7 drugiego bajtu natomiast jest ustawiany kiedy aktualny etap jest etapem ostatnim.
Skoro kompresja rozpoczyna się zanim użytkownik zostanie zapytany co dalej robić, pytanie o ewentualny podział archiwum na mniejsze pliki pojawia się tylko wtedy, kiedy są przynajmniej 2 etapy. W wypadku, kiedy jest tylko jeden, pytanie to nie występuje, a archiwum jest tworzone z nagłówkiem typu $FA. Pierwszy sektor w obrębie etapu jest zawsze poprzedzony numerem tego sektora.
Opis formatu
wszystkie podane niżej wartości zapisane są w systemie heksadecymalnym
<Archiwum Diskcomm> = {etap}
<etap> = <typ archiwum> <informacja o etapie> <numer sektora> {dane sektora} <koniec etapu>
<informacja o etapie> = <flaga ostatniego etapu> + <typ dyskietki> + <numer etapu>
<dane sektora> = <typ zawartości> [dane skompresowane] [numer sektora]
<typ zawartości> = <flaga sekwencyjna> + <typ kompresji>
<typ archiwum> = F9 | FA
<flaga ostaniego etapu> = 00 | 80
<typ dyskietki> = 00 | 20 | 40
<koniec etapu> = 45
<flaga sekwencyjna> = 00 | 80
<typ kompresji> = 41 | 42 | 43 | 44 | 46 | 47
<numer sektora> = 0001 - 270F
<number etapu> = 01 - 1F
<dane skompresowane> = zawartość sektora, zobacz niżej
Dokładny opis formatu
- archiwum Disk Communicatora - składa się z jednego lub więcej etapów. W przypadku, gdy archiwum jest rozbite na wiele plików, każdy z tych etapów jest zapisany w osobnym pliku
- etap - Składa się kolejno z: typu archiwum, informacji o etapie, sektora startowego, jednego lub więcej pakietów z danymi sektorów oraz kodu końca etapu
- typ archiwum - wskazuje czy jest to archiwum wieloplikowe ($F9) czy nie ($FA)
- dane sektora - pakiet danych sektora składa się z jednego bajtu wskazującego typ zawartości danych sektora. Bezpośrednio po nim znajduje się blok skompresowanych danych. Długość jego zależy od typu kompresji i może wynieść od zera do długości sektora na dysku (czyli maksymalnie 128 lub 256 bajtów). Najstarszy bit bajtu symbolizującego typ zawartości wskazuje czy za danymi skompresowanymi pojawi się numer sektora czy nie. Jeżeli jest skasowany to numer sektora pojawi się za danymi, jeżeli ustawiony - nie pojawi się on tam
- flaga sekwencyjna - wskazuje ona czy pakiet sektora zawiera jego numer czy nie. Jeżeli ma wartość 80, numer sektora znajduje się za jego danymi a następny sektor jest kolejnym sektorem archiwum
- typ zawartości - najstarszy bit jest flagą sekwencyjną. Pozostałe młodsze bity wskazują typ kompresji
- numer sektora - bez znaku, a więc zawsze dodatni. Składa się z dwóch bajtów. Pierwszy jest młodszym elementem ich ogólnej liczby, drugi - starszym. Normalnie zawiera się w domkniętym przedziale od 1 do 9999 dziesiętnie
- numer etapu - kolejny numer dowiązany do każdego z etapów. Normalnie zawiera się w domkniętym przedziale od 1 do 31 dziesiętnie. Może się "przekręcić" do zera po przekroczeniu 31
- koniec etapu - wartość $45
- typ kompresji - jedna z następujących wartości: $41, $42, $43, $44, $46 lub $47. Znaczenie ich jest opisane niżej
Typ 41 - początek zmian
Kompresja jest względna w stosunku do poprzedniego sektora. Dane sektora zawierają tylko jego początkową porcję. Ostatnia porcja nie jest zmieniona. Pierwszy bajt danych sektora wskazuje od jakiego offsetu zacząć modyfikację sektora. Kolejne bajty są użyte do modyfikacji początkowej porcji sektora. Modyfikacja ta ma miejsce zaczynając od bajtu z początkowym offsetem w stronę początku sektora, czyli pierwszego bajtu w tym sektorze (offset 0). Sugeruje to, że bajty danych są zapisywane w sektorze w odwrotnej kolejności.
Typ 42 - 128-bajtowy DOSowy sektor
Jest to przestarzały typ kompresji, używany we wcześniejszych wersjach Disk Communicatora. Miały one wsparcie jedynie dla pojedynczej gęstości, gdzie sektor miał zawsze długość 128 bajtów. Wszystkie wersje Diskcomma przy dekodowaniu archiwów wspierają tę metodę. Nie jest zalecane natomiast tworzenie nowych archiwów za pomocą starszych wersji programu. Dane sektora zawierają się w 5 bajtach. Pierwszy bajt użyty jest do zainicjowania pierwszych 124 bajtów sektora. Pozostałe cztery są zapisane w ostanich czterech bajtach sektora.
Typ 43 - sektor skompresowany
Dane sektora zawierają fragmenty ciągu. Zmieniają się one pomiędzy nieskompresowanymi a skompresowanymi, zaczynając od nieskompresowanego fragmentu.. Każdy z tych fragmentów rozpoczyna się od bajtu wskazującego offset wskazujący koniec danych w sektorze. Kiedy pozycja końcowa jest osiągnięta, osiągnięty jest również koniec fragmentu ciągu a bajt znajdujący się na tej pozycji jest równocześnie początkiem kolejnego fragmentu. Pozycja startowa pierwszego fragmentu ciągu ma offset zerowy. Nieskompresowany fragment zawiera tyle bajtów, ile jest potrzebne na wypełnienie sektora, natomiast nie zawiera końcowego offsetu.
W przypadku nieskompresowanych fragmentów, gdy początkowy offset jest równy końcowemu, nie ma więcej danych, efektem jest ciąg zerowy. Jest to używane wtedy, gdy mamy dwie porcje danych w obrębie sektora, który można skompresować, bez innych danych pomiędzy tymi porcjami. Stąd obecność nieskompresowanego fragmentu ciągu oraz użycie ciągu zerowego. Skompresowane fragmenty ciągu mają zawsze długość dwóch bajtów. Pierwszy z tych wskazuje na końcowy offset, natomiast drugi stanowi znaki wypełnienia. Część sektora począwszy od startowego offsetu w stronę końcowego (ale już bez niego) jest wypełniana właśnie tym znakiem. Po skompresowanym fragmencie następuje kolejny nieskompresowany.
Dla dyskietek w podwójnej gęstości, końcowy offset ostatniego fragmentu ciągu jest równy 256. Ponieważ tylko jeden bajt symbolizuje offset końcowy, wówczas znajduje się tam zero. Jednakże zero jest offsetem używanym dla pierwszego nieskompresowanego ciągu, w celu oznaczenia, że jest on ciągiem zerowym. Tak więc koniec skompresowanego sektora tego typu jest osiągnięty, kiedy wszystkie bajty jego zostaną przetworzone. Może to nastąpić na końcu nieskompresowanego fragmentu ciągu. W takim przypadku po nieskompresowanym fragmencie nie wystąpi fragment skompresowany. Podobnie po skompresowanym fragmencie ciągu (również wtedy kolejny fragment nie będzie w postaci skompresowanej).
Typ 44 - koniec zmian
Kompresja ta jest względna wobec poprzedniego sektora. Dane sektora zawierają tylko fragment końcowy. Fragment początkowy nie jest tu zmieniany. Pierwszy bajt danych sektora wskazuje od jakiego miejsca należy zacząć modyfikować sektor. Pozostałe bajty są używane do zmiany końcowego fragmentu sektora. Modyfikacja ta rozpoczyna się od bajtu wskazywanego przez początkowy offset aż do ostatniego bajtu w sektorze, włącznie z nim.
Typ 45 - koniec etapu
Ten typ kompresji wskazuje na koniec etapu, nie jest więc rzeczywistym typem kompresji. Dla tego typu nie ma żadnych danych sektora. Dla wieloplikowego archiwum oznacza on koniec danego pliku. Archiwum jest kontynuowane w następnym pliku, chyba że dany etap jest etapem ostatnim. Dla archiwów jednoplikowych wskazuje on, że po danym etapie nastąpi kolejny, pod warunkiem, że dany nie jest etapem ostatnim. Kolejny etap rozpoczyna się nagłowkiem, po którym następuje numer sektora.
Typ 46 - to samo co poprzednio
Ten typ kompresji oznacza, że zawartość danego sektora, jest identyczna z zawartością poprzedniego, niepustego sektora. Dla tego typu również nie ma danych sektora.
Typ 47 - nieskompresowany sektor
Dane sektora zawierają liczbę bajtów potrzebnych do wypełnienia całego sektora, czyli 128 lub 256. W sektorze tego typu nie jest zastosowana żadna metoda kompresji.
Poprzedni sektor
Bufor trzymający dane poprzedniego niepustego sektora jest inicjowany na początku etapu w przypadku, gdy archiwum jest wieloplikowe. Dla jednoplikowych archiwów bufor ten czysczony jest tylko na początku pierszego etapu.
Znane błędy i anomalie
Specyfikacja pliku może wywołać niekiedy pewne anomalie. Jeżeli ostatni sektor w etapie zawiera ustawioną flagę, że musi nastąpić po nim numer sektora, numer ten nie ma znaczenia, ponieważ kolejny etap rozpoczyna się zawsze numerem sektora. Diskcomm może nie mieć dostępnego kolejnego sektora. Zatem nie zawsze może on stwierdzić czy następny sektor jest pusty, czy nie. Skoro numer sektora musi musi być dołączony przy ustawieniu tej flagi, podawany jest fałszywy numer. Użyta jest do tego wartość $0045. Jest to również prawdziwe w przypadku ostatniego etapu. Podana wartość jest zapisana w kolejności młodszy/starszy bajt. Diskcomm przetwarza sektory w porcjach po 18 sektorów bądź po 9 sektorów, w przypadku dyskietki zapisanej w podwójnej gęstości. Porcje te mogą zawierać puste sektory. Po ostatnim sektorze w porcji zawsze następuje numer sektora, ponieważ Diskcomm nie czyta z wyprzedzeniem by stwierdzić zawartośc kolejnego sektora. Nie jest to jednak wymogiem. Przy tworzeniu archiwum, Diskcomm czasem to robi, ale tylko wtedy, kiedy kolejny sektor nie jest pusty.
Wygląda na to, że Diskcomm ma nieco problemów z niektórymi archiwami. Sektory w podwójnej gęstości mają długość 256 bajtów. Jeżeli bufor zawiera $5EFF bajtów, sektor nie może być skompresowany a musi być jeszcze dołączony numer sektora, musimy dodać 259 bajtów do bufora. Żeby zaznaczyć koniec etapu, musimy dołożyć jeszcze jeden bajt o wartości $45 lub $45 $00 $45. Może to dodać do trzech dodatkowych bajtów. Długość etapu wtedy będzie wynosić $6003 bajty, co z kolei przekracza jego dopuszczalną długość ($6002 bajty). Podczas odczytu też jest problem. Diskcomm nie zachowa dwóch pierwszych bajtów, ponieważ są one czytane i przetwarzane jako pierwsze. Następnie próbuje odczytać kolejnych $6000 bajtów. Ale w obrębie ich musi być zawarty kod końca etapu. Jednak gdy ten się nie pojawi, Diskcomm nie będzie w stanie przetworzyć pliku. Problem ten może wystąpić tylko w przypadku dyskietek zapisanych w podwójnej gęstości i przy wyjątkowo niesprzyjających okolicznościach.
Kiedy etap zawiera dokładnie $6002 bajty, Diskcomm zakończy pracę po nim. Dlatego etapy muszą być krótsze niż $6002 bajty. Może to wystąpić tylko przy archiwach dyskietek w podwójnej gęstości.
Z nieznanych powodów etapy powyżej numeru 31 mają numer zmniejszony o 1. Zapisuje się tylko pięć młodszych bitów.
Dla wieloplikowych archiwów, wybrany znak w nazwie pliku jest zwiększany dla każdego etapu. Może to wywołać użycie niewłaściwego znaku w nazwie, w zależności od ograniczeń narzucanych przez DOSa.
Dekompresja DCM
Plik DCM może zdekompresować do postaci ATR np. emulator atari800.
