Format AtariDOS 2

From Atariki

Jump to: navigation, search

Format dyskietki używany przez DOS 2.0s i DOS 2.0d przeznaczony dla stacji 810 i 815. Format ten jest bardzo podobny do wcześniejszego formatu DOS-u 1.0.

Spis treści

Cechy ogólne

  • Dopuszczalne wielkości sektorów: 128 i 256 bajtów
  • Maksymalna pojemność filesystemu: 944 sektory (233,23 kB)
  • Maksymalna wielkość pliku: 253 kB
  • Maksymalna liczba plików na dysku: 64
  • Struktura katalogowa: jednopoziomowa
  • Maksymalna liczba plików w katalogu: 64
  • Wielkość wpisu w katalogu: 16 bajtów
  • Nazwa pliku: 8+3
  • Metoda linkowania plików: 3-bajtowy link w sektorze danych
  • Metoda alokacji sektorów: mapa bitowa

Struktura ogólna

Obsługiwana jest wyłącznie gęstość pojedyncza i podwójna (SD i DD) przy czym DOS 2.0s zna tyko tę pierwszą. Jednostką alokacji jest pojedynczy sektor fizyczny o wielkości 128 lub 256 bajtów. Sektor nr 360 ($168) jest zajęty na VTOC, w sektorach 361-368 ($0169-$0170) znajduje się katalog dyskietki. W sektorach 1-3 jest program ładujący DOS, a sektor ostatni jest niewykorzystany. Początkowa pojemność dyskietki to 707 wolnych sektorów z ogólnej liczby 720.

VTOC

Pierwszy bajt VTOC zajmuje numer wersji formatu dyskietki, jest to $02. Dwa dalsze bajty to zapisana w konwencji młodszy/starszy początkowa liczba wolnych sektorów dyskietki, czyli maksymalna liczba sektorów możliwych do wykorzystania na pliki ($02C3 = 707). Dwa kolejne bajty to bieżąca liczba wolnych sektorów.

Bajty 5-9 VTOC są nieużywane. Od bajtu 10 do 99 rozciąga się mapa bitowa dyskietki. Każdy bajt opisuje stan ośmiu kolejnych sektorów, przy czym bit ustawiony oznacza sektor wolny, a bit skasowany - sektor zajęty. Bity przypisywane są od lewej do prawej sektorom o rosnących numerach, a więc jeśli bit 7 bajtu opisuje stan sektora numer 'n', to bit 6 odpowiada za sektor 'n+1', bit 5 za 'n+2' itd.

Pierwszy bajt mapy opisuje stan sektorów o numerach od 0 do 7 (pomimo że sektor 0 nie istnieje). Na pustej dyskietce jego wartość to $0F, co oznacza, że z grupy sektorów 0-7 cztery pierwsze (0-3) są zajęte, a reszta (4-7) wolna. Ostatni sektor dyskietki ma przypisany bit 7 bajtu nr 100 VTOC i jest oznaczony jako zajęty.

Struktura VTOC, wyjąwszy znacznik formatu w pierwszym bajcie, jest identyczna jak w DOS 1.0.

Katalog

Katalog zajmuje osiem sektorów o numerach od 361 do 368 ($0169-$0170). Pojedynczy wpis ma 16 bajtów długości, jego strukturę przedstawia tabelka:

OffsetOpis
$00

Bajt statusu:

  • bit 7 = 1 - plik skasowany; pozostałe bity mają wtedy wartość 0
  • bit 6 = 1 - plik istnieje; stany bitów 6 i 7 są zawsze przeciwne
  • bit 5 = 1 - plik jest zabezpieczony przed zapisem lub skasowaniem
  • bit 4 - niewykorzystany
  • bit 3 - niewykorzystany
  • bit 2 - niewykorzystany
  • bit 1 = 1 - plik jest utworzony przez DOS 2.0 (DOS 1.0 w przeciwnym wypadku)
  • bit 0 = 1 - plik jest otwarty do zapisu

Ogólnie status $42 oznacza plik istniejący, $62 plik zabezpieczony przed zapisem, a $80 plik skasowany.

$01-$02

Wielkość pliku w sektorach.

$03-$04

Numer pierwszego sektora zajętego przez plik.

$05-$0C

Nazwa pliku dopełniona spacjami.

$0D-$0F

Rozszerzenie nazwy pliku dopełnione spacjami.

Struktura katalogu jest bardzo podobna do tej, którą mamy w DOS 1.0. Jedyną liczącą się różnicą jest to, że DOS 2.0 ustawia zakładanym przez siebie plikom bit 1 statusu, co oznacza "plik założony przez DOS 2.0". Ma to znaczenie przy wymianie plików pomiędzy DOS 1.0 a DOS 2.0 - od biedy mogą one współistnieć na jednej dyskietce, aczkolwiek dostęp do plików DOS 1.0 spod DOS 2.0 może być kłopotliwy (patrz niżej).

W podwójnej gęstości pod DOS 2.0d wpisy katalogowe zajmują tylko pierwszą połówkę każdego sektora katalogu, reszta natomiast pozostaje pusta (filesystem i tak ogranicza maksymalną liczbę plików na dysku do 64).

Mapowanie plików

Ciągłość plików oraz dokładne dane o ich długości (katalog zawiera tylko wielkość pliku w sektorach) zapewnia "link" umieszczony w trzech ostatnich bajtach każdego sektora danych. Wynika z tego, że w każdym sektorze dostępne jest tylko 125 (w SD) lub 253 (w DD) bajty na dane pliku, trzy pozostałe natomiast zajmuje DOS. Informacja w nich zawarta rozmieszczona jest niezgodnie z granicami bajtów:

+---------------+---------------+---------------+
|       0       |       1       |       2       |
+---------------+---------------+---------------+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+---------------+---------------+
| nr pliku  |  następny sektor  |  wypełnienie  |
+-----------+-------------------+---------------+
  • Numer pliku to numer wpisu w katalogu dyskietki, który należy do pliku. Jest nań przeznaczone sześć bitów, czyli na dyskietce mogą być nie więcej niż 64 pliki. Pole to służy do kontrolowania, czy ciągłość plików na dyskietce nie uległa zakłóceniu - jeśli ten numer się nie zgadza z numerem bieżąco odczytywanego pliku, DOS zgłasza błąd nr 164.
  • Dziesięć następnych bitów to numer następnego sektora pliku; w ostatnim sektorze pliku jest on równy zero. Kolejność bajtów jest odwrotna od ogólnie przyjętej (tj. bajt nr 0 zawiera "najstarsze" bity wartości).

Wielkość tego pola ogranicza system plików do 1024 sektorów. Co więcej, ponieważ jedyna informacja na temat rozmieszczenia pliku znajduje się w przypisanych doń sektorach, rozmieszczenie sektorów pliku na dyskietce nigdy nie jest znane bez odczytania całości pliku aż do końca - co jest konieczne nawet przy jego kasowaniu. Z kolei fakt, że wskaźnik jest skierowany tylko w jedną stronę, tj. na następny sektor, powoduje, iż znalezienie sektora poprzedniego również wymaga odczytania pliku od początku; o funkcji seek() i swobodnym dostępie do danych pliku można więc przy takim filesystemie od razu zapomnieć

  • Wypełnienie: ilość bajtów danych w sektorze. Pełny sektor danych ma tu wartość $7D (125) w SD i $FD (253) w DD. Liczba ta ma znaczenie tylko w ostatnim sektorze pliku, gdzie pozwala znaleźć koniec danych.

Znaczenie bitów ostatniego bajtu linku zostało zmienione w stosunku do formatu DOS 1.0 - DOS 2.0 nie zna "znacznika wypełnienia", a co za tym idzie mogą wystąpić problemy ze znalezieniem końca pliku zapisanego przez DOS 1.0. W szczególności na końcu takich zbiorów mogą odczytywać się nadmiarowe "śmieci".

Zobacz też

Personal tools