DCM
From Atariki
| Wersja z dnia 02:39, 9 gru 2005 KMK (Dyskusja | wkład) (przeniesienie opisu formatu) ← Previous diff |
Aktualna wersja 0xF (Dyskusja | wkład) (→Znane błędy i anomalie - literówka) |
||
| Linia 1: | Linia 1: | ||
| Format obrazu dyskietki wygenerowanego przez program [[Disk Communicator]]. | Format obrazu dyskietki wygenerowanego przez program [[Disk Communicator]]. | ||
| - | <pre> | + | Wersja formatu - 3.2, rewizja 1.0, luty 1998. |
| - | Diskcomm file format version 3.2, revision 1.0, February 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. | ||
| - | Diskcomm archives represent the contents of diskettes used for the | + | 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. |
| - | Classic Atari computers. Various pieces of information related to the | + | |
| - | format and the contents of the diskette are stored in the archive | + | |
| - | file. To reduce the storage space requirements, compression | + | |
| - | algorithms are applied to the data. For some large archive files, it | + | |
| - | may be necessary to split the archive into multiple files, in order to | + | |
| - | be able to store the archive on diskettes. | + | |
| - | On an Atari disk, data is organized in sectors. These sectors are | + | 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. |
| - | numbered starting from 1. There are various disk sizes. The most | + | |
| - | common ones are the standard diskettes. Common diskette formats are | + | |
| - | the single density diskette, which holds 720 sectors of 128 bytes, the | + | |
| - | enhanced density diskette, which holds 1040 sectors of 128 bytes, and | + | |
| - | the double density diskette, which holds 720 sectors of 256 bytes. | + | |
| - | There are various other formats, but the single density and the | + | |
| - | enhanced density are used most, since these are supported by the 1050 | + | |
| - | disk drive. Other formats require a XF551, 815, or some third party | + | |
| - | disk drive, like the Percom, Indus GT, Trak, Black Box with floppy | + | |
| - | board, MIO, and the HDI, to name just a few. Diskcomm will always use | + | |
| - | 1040 sectors for enhanced density diskettes, so for this type of | + | |
| - | format, the number of sectors processed is defined by the format. For | + | |
| - | single density and double density disks, the maximum number of sectors | + | |
| - | can be modified between 1 and 9999. By definition, the first three | + | |
| - | sectors of any Atari disk contain 128 bytes, since this is considered | + | |
| - | the boot area. So the first three sectors of double density disks | + | |
| - | will also contain only 128 bytes of data. Diskcomm still stores these | + | |
| - | sectors as sectors of 256 bytes within the archive, and the remaining | + | |
| - | 128 bytes will simply contain zeroes. | + | |
| - | The sectors of a disk are stored in the archive sequentially. Sectors | + | Sektory dyskietki są przechowywane w archiwum w sekwencyjnie i są skompresowane. |
| - | of data within a Diskcomm archive are compressed. While creating the | + | Podczas tworzenia archiwum Diskcomm bada zawartość każdego sektora i w zależności od niej |
| - | archive, Diskcomm examines the contents of each sector that is | + | stosuje odpowiedni algorytm kompresji. Sektory zawierające same zera traktowane są jako |
| - | processed. Based on these contents, one of several compression | + | puste i nie są umieszczane w archiwum. Ustawiana jest jedynie flaga w informacji opisującej |
| - | algorithms is used to reduce the amount of storage required for | + | poprzedni niepusty sektor. Wskazuje ona na następny sektor zawierający dane i w ten sposób |
| - | representing the contents of this sector. Sectors that contain | + | sektory puste są "przeskakiwane". Program zakłada, że dyskietka, na którą zostanie |
| - | nothing but zeroes are considered empty sectors. Empty sectors are | + | wypakowane archiwum, zostanie przedtem sformatowana (wypełniona zerami), dlatego nie ma potrzeby trzymania pustych sektorów w archiwum. |
| - | not stored in the archive. A flag will be set in the information | + | |
| - | stored for the preceding non-empty sector, to indicate this. This | + | |
| - | preceding sector will be followed by the sector number of the next | + | |
| - | sector that contains data. It is assumed that the diskette will be | + | |
| - | formatted before writing the archive back to a diskette, and thus that | + | |
| - | initially all sectors on the output disk will contain zeroes. | + | |
| - | Therefore, there is no need to store empty sectors in the archive. To | + | |
| - | be able to skip these sectors when writing the archive back to disk, | + | |
| - | the sector number included in the archive is used to skip these empty | + | |
| - | sectors. | + | |
| - | For sectors that contain data, the contents of the sector are compared | + | Dla sektorów zawierających dane zawartość sektora jest porównywana z zawartością sektora |
| - | to the contents of the last preceding sector containing data. Empty | + | poprzedzającego go (ostatniego również zawierającego dane). Puste sektory nie mają wpływu |
| - | sectors have no influence on this comparison, since they are skipped. | + | na to porównanie, ponieważ i tak zostają pominięte. Jak wspomniano wcześniej, odpowiednia |
| - | Like noted before, there is a flag that indicates that a sector number | + | flaga wskazuje następny sektor zawierający danet. Jeżeli według tej flagi następny sektor |
| - | follows the sector data. If this flag indicates that a sector number | + | rzeczywiście zawiera dane, wtedy numer danego sektora zostaje dołączony do bufora archiwum |
| - | follows the sector data, the number of the current sector is appended | + | (w formacie młodszy/starszy bajt). Potem następuje próba kompresji tego sektora. |
| - | to the archive buffer, in the 6502 low/high byte format. Then an | + | Zastosowane mogą tu być cztery różne algorytmy kompresji. Każdy z nich jest kolejno |
| - | attempt is made to compress the current sector. There are four | + | przeprowadzany na sektorze i jeżeli kompresja się powiedze, dane skompresowane dołączane są |
| - | different compression algorithms that can be applied. Each of them is | + | 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 |
| - | applied to the sector in turn, and if the result is successful, the | + | pozostałych czterech, które są użyte w ostatniej dostępnej wersji Disk Communicatora. Mogą |
| - | resulting compressed data is appended to the archive buffer, with the | + | się jednak trafiać starsze archiwa, gdzie ów piąty algorytm jest użyty. Jeżeli dane z |
| - | type of compression pre-pended. Older versions of Diskcomm used a | + | sektora nie mogą zostać skompresowane przez żaden z czterech algorytmów, zostają one |
| - | fifth algorithm. This is now obsoleted by one of the remaining four | + | zachowane w postaci nieskompresowanej. |
| - | algorithms, so this old algorithm is no longer applied when an archive | + | |
| - | is being created. However, some very old archive may still contain a | + | |
| - | sector that was compressed by this algorithm. If the sector data | + | |
| - | cannot be compressed by one of the four algorithms, the data is stored | + | |
| - | uncompressed. | + | |
| - | Compression of sectors continues until memory runs out, or until there | + | Proces kompresji sektorów postępuje aż dostępna pamięć się zapełni lub kiedy nie będzie już |
| - | are no more sectors left to process. Due to memory limitations, there | + | więcej sektorów do skompresowania. Ze wględu na ograniczenia pamięci, bufor archiwum może |
| - | is a maximum of just over 24K of data that can be stored in the | + | pomieścić tylko do 24 kB danych, tak że przed próbą dołączenia danych do bufora już pełnego |
| - | archive buffer. When appending the compressed data to the buffer | + | jest on najpierw zgrywany na dysk (a następnie czyszczony). System mający do dyspozycji |
| - | causes the buffer to contain about 24K of compressed data, the buffer | + | więcej niż 64 kB pamięci, może utworzyć większą ilość takich buforów (i następnie ich użyć). |
| - | is full, and it is flushed to disk. A system that has more than 64K | + | |
| - | of memory can hold multiple buffers before the data is actually | + | Zapełnienie każdego z nich przedstawione jest jako kolejny etap (pass) kompresji dysku. |
| - | flushed to disk. Each buffer load is considered to be a pass in the | + | Jest on jest niezdefiniowaną liczbą skompresowanych sektorów i jest uważany za kompletny |
| - | compression of the disk. A pass is an undefined number of compressed | + | kiedy w buforze zostanie zgromadzine $5F02 (dziesiętnie: 24322) lub więcej bajtów. |
| - | sectors, that is considered complete when hex 5F02 ( dec 24322 ) bytes | + | Następnie zostaje dołączona informacja o końcu tego etapu. Długość etapu nie może wynieść |
| - | of data or more has been accumulated. The end of pass information is | + | więcej niż $6002 (dziesiętnie: 24578) bajtów. Każdy z etapów rozpoczyna dwubajtowy |
| - | then appended to the pass. A pass must be no larger than hex 6002 | + | nagłówek. Pierwszy bajt może być równy $FA lub $F9. Jeżeli archiwum jest podzielone na |
| - | bytes. Each pass starts with the header, which consists of two bytes. | + | kilka plików zawiera on wartość $F9, w wypadku jednoplikowego archiwum znajduje się tam |
| - | The first byte is either hex FA or hex F9. When the archive is split | + | $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. |
| - | up into multiple files, this byte will contain hex F9, otherwise it | + | |
| - | will contain hex FA. The second byte of the header combines three | + | |
| - | pieces of information. The format of the original disk is indicated | + | |
| - | in bit 5 and bit 6 of the second byte. Bit value 00 is used for | + | |
| - | single density disks, bit value 01 is used for enhanced density disks, | + | |
| - | and bit value 10 is used for double density disks. Bit value 11 is | + | |
| - | undefined. Bits 0 to 4 are used to indicate the pass number. Each | + | |
| - | pass is numbered sequentially, starting at 1. since there are 5 bits | + | |
| - | available for this, the highest possible pass number is 31. | + | |
| - | Therefore, the largest archive will be no larger than 31 times 24K, | + | |
| - | unless the pass count is allowed to roll over to zero. The high order | + | |
| - | bit of the second byte (bit 7) is set when this pass is the last pass. | + | |
| - | Since compression is started before asking what the user wants to do, | + | |
| - | the question of dividing the archive into smaller files is only | + | |
| - | presented to the user if there is more than one pass. If all data can | + | |
| - | be stored in one pass, this question is not presented, and an archive | + | |
| - | with header type hex FA is created. The first sector within a pass | + | |
| - | will always be preceded by its sector number. | + | |
| - | Format description, values are in hex: | + | 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. |
| - | <Diskcomm archive> = {pass} | + | ==Opis formatu== |
| - | <pass> = <archive type> <pass information> <sector number> {sector | + | wszystkie podane niżej wartości zapisane są w systemie heksadecymalnym |
| - | data} <end of pass> | + | |
| - | <pass information> = <last pass flag> + <diskette type> + <pass | + | |
| - | number> | + | |
| - | <sector data> = <content type> [compressed data] [sector number] | + | |
| - | <content type> = <sequential flag> + <compression type> | + | |
| - | <archive type> = F9 | FA | + | |
| - | <last pass flag> = 00 | 80 | + | |
| - | <diskette type> = 00 | 20 | 40 | + | |
| - | <end of pass> = 45 | + | |
| - | <sequential flag> = 00 | 80 | + | |
| - | <compression type> = 41 | 42 | 43 | 44 | 46 | 47 | + | |
| - | <sector number> = 0001 - 270F | + | |
| - | <pass number> = 01 - 1F | + | |
| - | <compressed data> = Sector contents, see below. | + | |
| - | Format description in plain English. | + | <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> | ||
| - | Diskcomm archive: A Diskcomm archive consists of one or more passes. | + | ==Dokładny opis formatu== |
| - | When an archive is split into multiple files, each pass is stored in a | + | *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 |
| - | separate file. | + | *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 |
| - | Pass: A pass consists of an archive type code, followed by pass | + | *typ archiwum - wskazuje czy jest to archiwum wieloplikowe ($F9) czy nie ($FA) |
| - | information, followed by the starting sector number, followed by one | + | *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 |
| - | or more sector data packets, followed by the end of pass code. | + | *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 |
| - | Archive type: The archive type indicates whether this is a multi file | + | *typ zawartości - najstarszy bit jest flagą sekwencyjną. Pozostałe młodsze bity wskazują typ kompresji |
| - | archive (F9) or not (FA). | + | *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 |
| - | Sector data: A sector data packet consists of one byte that indicates | + | *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 |
| - | the content type for the sector data packet. After the content type, | + | *koniec etapu - wartość $45 |
| - | the compressed data for the sector follows. The contents of this | + | *typ kompresji - jedna z następujących wartości: $41, $42, $43, $44, $46 lub $47. Znaczenie ich jest opisane niżej |
| - | depends on the type of compression, and it can contain any number of | + | |
| - | bytes, from zero up to the length of the sector for the type of disk, | + | |
| - | either 128 or 256 bytes. The high order bit of the content type is | + | |
| - | used to indicate whether or not a sector number will follow the | + | |
| - | compressed data. If this bit is zero, a sector number will follow the | + | |
| - | data. If this bit is one, there will not be a sector number following | + | |
| - | the compressed data. | + | |
| - | Sequential flag: This flag indicates whether or not the sector packet | + | |
| - | contains a sector number. If this flag has the value 00, a sector | + | |
| - | number will follow the sector data. If it has the value 80, there | + | |
| - | will not be a sector number following the sector data, and the next | + | |
| - | sector is the next sequential sector. | + | |
| - | Content type: The high order bit of this byte is the sequential flag. | + | |
| - | The remaining low order bits are the compression type. | + | |
| - | Sector number: An unsigned sector number, which is two bytes. The | + | |
| - | first byte is the low order portion of the number, the second byte is | + | |
| - | the high order portion of the number. Normally ranging from 1 to 9999 | + | |
| - | decimal. | + | |
| - | Pass number: A sequence number assigned to each pass. Normally | + | |
| - | ranging from 1 to 31 decimal. This might roll over to zero after 31. | + | |
| - | End of pass: The value hex 45. | + | |
| - | Compression type: One of the following hex values: 41, 42, 43, 44, 46 | + | |
| - | or 47. The meaning of these values is described below. | + | |
| - | Type 41, modify begin. | + | ===Typ 41 - początek zmian=== |
| - | The compression is relative to the previous sector. The sector data | + | Kompresja jest względna w stosunku do poprzedniego sektora. Dane sektora zawierają tylko |
| - | contains only the beginning portion. The last portion is not changed. | + | jego początkową porcję. Ostatnia porcja nie jest zmieniona. Pierwszy bajt danych sektora |
| - | The first byte of the sector data specifies at what offset to start | + | wskazuje od jakiego offsetu zacząć modyfikację sektora. Kolejne bajty są użyte do |
| - | modifying the sector. The remaining bytes of the sector data are used | + | modyfikacji początkowej porcji sektora. Modyfikacja ta ma miejsce zaczynając od bajtu z |
| - | to modify the beginning portion of the sector. This modification | + | początkowym offsetem w stronę początku sektora, czyli pierwszego bajtu w tym sektorze |
| - | takes place starting at the byte at the start offset, working towards | + | (offset 0). Sugeruje to, że bajty danych są zapisywane w sektorze w odwrotnej kolejności. |
| - | the beginning of the sector, up to and including the byte at offset | + | |
| - | zero, the first byte of the sector. This implies that the data bytes | + | |
| - | are stored in a reverse order in the sector data. | + | |
| - | Type 42, 128 byte DOS sector. | + | ===Typ 42 - 128-bajtowy DOSowy sektor=== |
| - | This is an obsolete compression type, that was used by early versions | + | Jest to przestarzały typ kompresji, używany we wcześniejszych wersjach Disk Communicatora. |
| - | of Diskcomm. Earlier versions of Diskcomm supported only single | + | Miały one wsparcie jedynie dla pojedynczej gęstości, gdzie sektor miał zawsze długość 128 |
| - | density diskettes, so this type of sector always represents 128 bytes. | + | bajtów. Wszystkie wersje Diskcomma przy dekodowaniu archiwów wspierają tę metodę. |
| - | Programs that decode archives should be aware of this. Using it for | + | Nie jest zalecane natomiast tworzenie nowych archiwów za pomocą starszych wersji programu. |
| - | creating new archives is not recommended. The sector data contains | + | Dane sektora zawierają się w 5 bajtach. Pierwszy bajt użyty jest do zainicjowania |
| - | five bytes. The first byte of the sector data is used to initialize | + | pierwszych 124 bajtów sektora. Pozostałe cztery są zapisane w ostanich czterech bajtach |
| - | the first 124 bytes of the sector. The remaining four bytes are | + | sektora. |
| - | stored in the last four bytes of the sector. | + | |
| - | Type 43, compressed sector. | + | ===Typ 43 - sektor skompresowany=== |
| - | The sector data contains substrings. These substrings alternate | + | Dane sektora zawierają fragmenty ciągu. Zmieniają się one pomiędzy nieskompresowanymi a |
| - | between uncompressed and compressed, starting with an uncompressed | + | skompresowanymi, zaczynając od nieskompresowanego fragmentu.. Każdy z tych fragmentów |
| - | substring. Each of these substrings starts with a byte that specifies | + | rozpoczyna się od bajtu wskazującego offset wskazujący koniec danych w sektorze. Kiedy |
| - | the ending offset of the resulting data in the sector. When this | + | pozycja końcowa jest osiągnięta, osiągnięty jest również koniec fragmentu ciągu a bajt |
| - | ending offset position is reached, the end of the substring is | + | znajdujący się na tej pozycji jest równocześnie początkiem kolejnego fragmentu. Pozycja |
| - | reached, and the byte at this ending offset is the starting position | + | startowa pierwszego fragmentu ciągu ma offset zerowy. Nieskompresowany fragment zawiera tyle |
| - | for the next substring. The starting position for the first substring | + | bajtów, ile jest potrzebne na wypełnienie sektora, natomiast nie zawiera końcowego offsetu. |
| - | is at offset zero. An uncompressed substring will contain as many | + | |
| - | bytes as are needed to fill the sector from the start position up to, | + | |
| - | but not including the end offset. For uncompressed substrings, if the | + | |
| - | starting position offset is equal to the ending offset, there is no | + | |
| - | further data, so in effect, this is a null string. This is used when | + | |
| - | there are two portions of data within the sector that can be | + | |
| - | compressed, without other data in between these portions. The | + | |
| - | uncompressed substring must be present, therefore a null string must | + | |
| - | be used in this case. Compressed substrings are always two bytes in | + | |
| - | length. The compressed substring starts with a byte that indicates | + | |
| - | the ending offset. The second byte contains the fill character. The | + | |
| - | portion of the sector starting at the start offset, up to, but not | + | |
| - | including the ending offset, is set to the value of this fill | + | |
| - | character. After the compressed substring, another uncompressed | + | |
| - | substring follows. | + | |
| - | For double density disks, the ending offset for the last substring is | + | W przypadku nieskompresowanych fragmentów, gdy początkowy offset jest równy końcowemu, nie |
| - | 256. Since there is only one byte to represent the ending offset, | + | ma więcej danych, efektem jest ciąg zerowy. Jest to używane wtedy, gdy mamy dwie porcje |
| - | this is stored as zero. However, zero is an offset that can be used | + | danych w obrębie sektora, który można skompresować, bez innych danych pomiędzy tymi |
| - | for the first uncompressed string, to indicate that the first | + | porcjami. Stąd obecność nieskompresowanego fragmentu ciągu oraz użycie ciągu zerowego. |
| - | uncompressed string is a null string. The end of this type of | + | Skompresowane fragmenty ciągu mają zawsze długość dwóch bajtów. Pierwszy z tych wskazuje na |
| - | compressed sector is reached when all bytes in the sector have been | + | końcowy offset, natomiast drugi stanowi znaki wypełnienia. Część sektora począwszy od |
| - | processed. This can occur at the end of an uncompressed substring. | + | startowego offsetu w stronę końcowego (ale już bez niego) jest wypełniana właśnie tym |
| - | In this case, there will not be a compressed substring following the | + | znakiem. Po skompresowanym fragmencie następuje kolejny nieskompresowany. |
| - | uncompressed string. Likewise, if it occurs at the end of a | + | |
| - | compressed substring, there will not be an uncompressed string | + | |
| - | following it. | + | |
| - | Type 44, modify end. | + | 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). | ||
| - | The compression is relative to the previous sector. The sector data | + | ===Typ 44 - koniec zmian=== |
| - | contains only the ending portion. The beginning portion is not | + | |
| - | changed. The first byte of the sector data specifies at what offset | + | |
| - | to start modifying the sector. The remaining bytes of the sector data | + | |
| - | are used to modify the ending portion of the sector. This | + | |
| - | modification takes place starting at the byte at the start offset, up | + | |
| - | to, and including the last byte of the sector. | + | |
| - | Type 45, end of pass. | + | 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. | ||
| - | This compression type indicates the end of a pass, so it is not a real | + | ===Typ 45 - koniec etapu=== |
| - | compression type. There is no sector data for this type. For a multi | + | |
| - | file archive, this indicates the end of the file. The archive is | + | |
| - | continued in the next file, unless this pass was the last pass. For | + | |
| - | single file archives, this indicates that the next pass follows within | + | |
| - | this file, unless this was the last pass. The next pass starts with a | + | |
| - | header again, followed by a sector number. | + | |
| - | Type 46, same as before. | + | 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. | ||
| - | This compression type indicates that the data for this sector is | + | ===Typ 46 - to samo co poprzednio=== |
| - | identical to the data of the previous non-zero sector. There is no | + | |
| - | sector data for this type. | + | |
| - | Type 47, uncompressed sector. | + | 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. | ||
| - | The sector data contains the number of bytes required to fill an | + | ===Typ 47 - nieskompresowany sektor=== |
| - | entire sector, either 128 or 256 bytes. No compression of any kind is | + | |
| - | performed on this sector type. | + | |
| - | Previous sector. | + | 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. | ||
| - | The buffer that holds the contents of the previous non-zero sector is | + | ===Poprzedni sektor=== |
| - | initialized at the start of a pass if the archive is a multi file | + | |
| - | archive. For single file archives, this buffer is cleared at the | + | |
| - | start of the first pass only. | + | |
| - | Known bugs and anomalies. | + | 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. | ||
| - | This specification induces some anomalies. When the last sector in a | + | ==Znane błędy i anomalie== |
| - | pass has the flag set that indicates that a sector number must follow | + | |
| - | it, this sector number has no meaning, since the next pass will always | + | |
| - | start out with a sector number. Diskcomm might not have the next | + | |
| - | sector available. Therefore, it cannot always determine whether or | + | |
| - | not it is an empty sector. Since a sector number must be included | + | |
| - | once we set this flag, a fake sector number is appended. The value | + | |
| - | hex 0045 is used for this. This is also true for the last pass. Note | + | |
| - | that this is stored in the low/high byte order. | + | |
| - | Diskcomm processes sectors in chunks of 18 sectors, or chunks of 9 | + | Specyfikacja pliku może wywołać niekiedy pewne anomalie. Jeżeli ostatni sektor w etapie |
| - | sectors if the disk is double density. These chunks might include | + | zawiera ustawioną flagę, że musi nastąpić po nim numer sektora, numer ten nie ma znaczenia, |
| - | empty sectors. The last sector in these chunks will always be | + | ponieważ kolejny etap rozpoczyna się zawsze numerem sektora. Diskcomm może nie mieć |
| - | followed by a sector number, since Diskcomm does not read ahead to | + | dostępnego kolejnego sektora. Zatem nie zawsze może on stwierdzić czy następny sektor jest |
| - | determine the contents of the next sector. This is not a requirement. | + | pusty, czy nie. Skoro numer sektora musi musi być dołączony przy ustawieniu tej flagi, |
| - | On creating an archive, Diskcomm just happens to do this. So a sector | + | podawany jest fałszywy numer. Użyta jest do tego wartość $0045. Jest to również prawdziwe w |
| - | number might be included even if the next sector is non-zero. | + | 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. | ||
| - | It looks like Diskcomm has some slight problems. Double density | + | Wygląda na to, że Diskcomm ma nieco problemów z niektórymi archiwami. Sektory w podwójnej |
| - | sectors are 256 bytes long. If the buffer contains hex 5EFF bytes, | + | gęstości mają długość 256 bajtów. Jeżeli bufor zawiera $5EFF bajtów, sektor nie może być |
| - | and the sector cannot be compressed, and a sector number must be | + | skompresowany a musi być jeszcze dołączony numer sektora, musimy dodać 259 bajtów do bufora. |
| - | included, we must add 259 bytes to the buffer. To mark the end of | + | Żeby zaznaczyć koniec etapu, musimy dołożyć jeszcze jeden bajt o wartości $45 lub $45 $00 |
| - | pass, we have to add either one hex 45 byte, or hex 45 00 45. This | + | $45. Może to dodać do trzech dodatkowych bajtów. Długość etapu wtedy będzie wynosić $6003 |
| - | might add up to three extra bytes. The pass would be hex 6003 bytes | + | bajty, co z kolei przekracza jego dopuszczalną długość ($6002 bajty). Podczas odczytu też |
| - | long. This makes the pass longer than hex 6002 bytes. On reading, | + | jest problem. Diskcomm nie zachowa dwóch pierwszych bajtów, ponieważ są one czytane i |
| - | this is also a problem. Diskcomm will not store the first two bytes, | + | przetwarzane jako pierwsze. Następnie próbuje odczytać kolejnych $6000 bajtów. Ale w obrębie |
| - | since the two header bytes are read and processed first. Then it | + | ich musi być zawarty kod końca etapu. Jednak gdy ten się nie pojawi, Diskcomm nie będzie w |
| - | tries to read hex 6000 bytes. Within these hex 6000 bytes, the end of | + | stanie przetworzyć pliku. Problem ten może wystąpić tylko w przypadku dyskietek zapisanych |
| - | pass code must be included. This will be missing though, so Diskcomm | + | w podwójnej gęstości i przy wyjątkowo niesprzyjających okolicznościach. |
| - | will not be able to process the file. This problem only occurs with | + | |
| - | double density disks in the specified exceptional conditions. | + | |
| - | When a pass contains exactly hex 6002 bytes, Diskcomm will terminate | + | Kiedy etap zawiera dokładnie $6002 bajty, Diskcomm zakończy pracę po nim. Dlatego etapy |
| - | processing after this pass. Therefore, passes should be less than hex | + | muszą być krótsze niż $6002 bajty. Może to wystąpić tylko przy archiwach dyskietek w |
| - | 6002 in length. This can only occur with archives of double density | + | podwójnej gęstości. |
| - | disks. | + | |
| - | For unknown reasons, the passes above pass number 31 have their pass | + | Z nieznanych powodów etapy powyżej numeru 31 mają numer zmniejszony o 1. Zapisuje się |
| - | number reduced by one. Only the five low order bits are stored. | + | tylko pięć młodszych bitów. |
| - | For multi-file archives, a selected character of the filename is | + | Dla wieloplikowych archiwów, wybrany znak w nazwie pliku jest zwiększany dla każdego etapu. |
| - | incremented for each pass. This will eventually cause an invalid | + | Może to wywołać użycie niewłaściwego znaku w nazwie, w zależności od ograniczeń narzucanych |
| - | character to be used in the filename, depending on the restrictions | + | przez [[DOS]]a. |
| - | imposed by the DOS used. | + | |
| - | Send comments to: | + | ==Dekompresja DCM== |
| + | Plik DCM może zdekompresować do postaci ATR np. emulator [[atari800]]. | ||
| - | Ernest R. Schreurs | ||
| - | Kempenlandstraat 8 | ||
| - | 5211 VN Den Bosch | ||
| - | The Netherlands | ||
| - | ernest@wxs.nl | ||
| - | </pre> | ||
| - | {{stub}} | ||
| [[Kategoria:Atari 8-bit]] | [[Kategoria:Atari 8-bit]] | ||
| [[Kategoria:Formaty plików]] | [[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.
