DOS2DOS

From Atariki

(Różnice między wersjami)
Jump to: navigation, search
Wersja z dnia 16:25, 17 gru 2010
KMK (Dyskusja | wkład)
(Operacje plikowe)
← Previous diff
Wersja z dnia 16:28, 17 gru 2010
KMK (Dyskusja | wkład)
(Operacje plikowe)
Next diff →
Linia 92: Linia 92:
Nie każda operacja wymaga wykonania wszystkich czterech faz, spora część zadowala się pierwszymi dwiema, a nieliczne nawet tylko pierwszą. Nie każda operacja wymaga wykonania wszystkich czterech faz, spora część zadowala się pierwszymi dwiema, a nieliczne nawet tylko pierwszą.
-Rozpisanie całości na tego typu fazy podyktowane jest ograniczeniami narzuconymi przez protokół SIO, który np. zasadniczo nie przewiduje przesyłania kodów błędów; SIO przesyła tylko tzw. potwierdzenia (negatywne lub pozytywne), co jest po pierwsze niewystarczające, a po drugie powoduje kłopoty, gdy sterownik SIO podejmie "samowolną" próbę powtórzenia zadanej operacji (co robi zawsze, gdy nadejdzie negatywne potwierdzenie). Dlatego serwer plików powinien wszystko potwierdzać pozytywnie, zapisywać kod błędu do bloku statusu i liczyć na to, że program-klient odczyta go w następnym kroku. Negatywne potwierdzenie powinno nastąpić, gdy komenda inicjująca jest nieprawidłowa, tzn. bajty DAUX1/2 wykazują niewłaściwy (zbyt duży) rozmiar bloku parametrów lub nieznany numer wersji protokołu.+Rozpisanie całości na tego typu fazy podyktowane jest ograniczeniami narzuconymi przez protokół SIO, który np. zasadniczo nie przewiduje przesyłania kodów błędów; SIO przesyła tylko tzw. potwierdzenia (negatywne lub pozytywne), co jest po pierwsze niewystarczające, a po drugie powoduje kłopoty, gdy sterownik SIO podejmie "samowolną" próbę powtórzenia zadanej operacji (co robi zawsze, gdy nadejdzie negatywne potwierdzenie).
 + 
 +Dlatego serwer plików powinien wszystko potwierdzać pozytywnie, zapisywać kod błędu do bloku statusu i liczyć na to, że program-klient odczyta go w następnym kroku. Negatywne potwierdzenie powinno nastąpić tylko wtedy, gdy komenda inicjująca jest nieprawidłowa, tzn. bajty DAUX1/2 wykazują niewłaściwy (zbyt duży) rozmiar bloku parametrów lub nieznany numer wersji protokołu.
=== Tabela funkcji === === Tabela funkcji ===

Wersja z dnia 16:28, 17 gru 2010

Protokół komunikacji ośmiobitowego Atari z pamięciami masowymi, które obsługują własny system plików, np. z innym komputerem wyposażonym w pamięci masowe i działającym pod kontrolą "obcego" systemu operacyjnego. Protokół DOS2DOS został w 2010 roku opracowany przez KMK i zaimplementowany dla SpartaDOS X 4.43 (jako sterownik PCLink) oraz SIO2BSD.

Spis treści

Założenia

Dotychczas komunikacja Atari z pamięciami masowymi wygląda w ten sposób, że urządzenie peryferyjne rozpoznaje zestaw bardzo prostych komend, które udostępniają pamięć masową w jej stanie "surowym", tzn. można odczytać albo zapisać pojedyncze sektory i to jest właściwie wszystko. Zadaniem zorganizowania sektorów w system plików zajmuje się komputer Atari, a konkretnie DOS.

Ten system ma swoje zalety, ale kompletnie nie nadaje się do wygodnej wymiany plików pomiędzy różnymi komputerami. Np. przesłanie pliku z twardego dysku Atari na peceta oznacza na ogół nagranie go na obraz dyskietki (ATR), a następnie wyciągnięcie go stamtąd przy użyciu lokalnego oprogramowania. Przesłanie w ten sposób jednego-dwóch plików nie stanowi problemu, ale jeśli plików jest np. 1300, procedura zaczyna być uciążliwa.

Protokół DOS2DOS ma za zadanie dać Atari dostęp do systemu plików urządzenia zewnętrznego bez konieczności implementowania całej obsługi tegoż systemu plików po stronie Atari. Innymi słowy, takie urządzenie zewnętrzne z własnym dyskiem ("peceta") traktuje się jako czarną skrzynkę, która jest serwerem plików. Konkretny typ systemu plików (EXT2, FAT, NTFS, UFS) jest dla Atari obojętny, gdyż całą jego obsługę bierze na siebie serwer i jego system operacyjny. Od strony Atari potrzebny jest program-klient (w idealnym przypadku: nakładka na DOS) wysyłający do serwera polecenia odnoszące się do znajdującej się na serwerze struktury plików (typu "otwórz plik o nazwie tej a tej") i odbierający wyniki zadanych operacji.

Schemat ogólny

Protokół bazuje na protokole SIO. Wszystkie operacje plikowe realizuje się przy użyciu kombinacji trzech rozkazów SIO:

  • $50 (P, jak parameters) - zapis - zainicjowanie operacji i nadanie parametrów
  • $52 (R, jak results) - zapis lub odczyt - realizacja operacji, nadanie dodatkowych danych, jeśli są potrzebne, odbiór wyników
  • $53 (S, jak status) - odczyt - negocjacja parametrów i kontrola stanu

Kluczowe znaczenie mają bajty DAUX1/2 bloku DCB:

  • DAUX1 - wielkość bloku parametrów, jaki ma być przesłany rozkazem P (przy pozostałych rozkazach ta wartość jest ignorowana). 0 oznacza 256 bajtów.
  • DAUX2 - bity 7-4: numer wersji protokołu (obecnie 0), bity 3-0: numer urządzenia.

Numer urządzenia przesyłany jest w DAUX2 po to, żeby można było komunikować się z wieloma różnymi urządzeniami plikowymi (mogą to być np. różne katalogi na serwerze plików) zajmując przy tym tylko jeden identyfikator urządzenia SIO. W bieżącej implementacji ten identyfikator to $6F (DDEVIC=$61, DUNIT=$0F). Protokół pozwala serwerowi plików go zmienić, jeśli zachodzi taka potrzeba (użytkownik sobie tego życzy).

Opcjonalnie serwer plików może rozpoznawać komendę $3F (?), SEND HIGH SPEED INDEX, jeśli komunikacja jest prowadzona przez złącze szeregowe i istnieje potrzeba przyspieszenia transmisji.

Blok parametrów

Blok parametrów przesyłany przy inicjowaniu operacji ma zmienną wielkość (wskazaną w DAUX1), gdyż różne operacje wymagają różnej ilości parametrów (np. "open" wymaga podania nazwy pliku itp., a "read" - nie).

W języku C blok ten jest zdefiniowany następująco:

struct
{
     unsigned char fno;           /* numer funkcji */
     unsigned char handle;        /* uchwyt pliku */
     unsigned char f1,f2,f3;      /* bajty pomocnicze */
     unsigned char f4,f5,f5;
     unsigned char fmode;         /* tryb otwarcia pliku */
     unsigned char fatr1;         /* maska atrybutów wyszukiwanych */
     unsigned char fatr2;         /* maska atrybutów nadawanych */
     unsigned char name[12];      /* maska pliku w formacie NNNNNNNNXXX zakończona zerem */
     unsigned char names[12];     /* alternatywna maska pliku w formacie jak powyżej */
     unsigned char path[65];      /* ścieżka dostępu zakończona zerem */
} parbuf;

Tryb otwarcia pliku (fmode) to:

  • $x4 - odczyt
  • $x8 - zapis
  • $x9 - dopisywanie
  • $xc - wymiana danych (zapis/odczyt)

W starszym półbajcie liczy się tylko bit 0 ($1x), jeśli jest ustawiony, operacja dotyczy otwarcia katalogu jako pliku (tzw. bezpośredni dostęp do katalogu). W przeciwnym wypadku operacja dotyczy pliku.

Maska atrybutów wyszukiwanych (fatr1) wybiera atrybuty, jakie ma mieć plik, żeby serwer plików go znalazł. Poszczególne bity są zdefiniowane następująco:

# define RA_PROTECT     0x01      /* tylko zabezpieczone */
# define RA_HIDDEN      0x02      /* tylko ukryte */
# define RA_ARCHIVED    0x04      /* tylko z ustawionym atrybutem A */
# define RA_SUBDIR      0x08      /* tylko katalogi */
# define RA_NO_PROTECT  0x10      /* tylko niezabezpieczone */
# define RA_NO_HIDDEN   0x20      /* tylko nieukryte */
# define RA_NO_ARCHIVED 0x40      /* tylko ze skasowanym atrybutem A */
# define RA_NO_SUBDIR   0x80      /* tylko zwykłe pliki */

Maska $00 wybiera wszystkie pliki. Maska atrybutów nadawanych zdefiniowana jest podobnie:

# define SA_PROTECT     0x01      /* zabezpiecz */
# define SA_HIDE        0x02      /* ukryj */
# define SA_ARCHIVE     0x04      /* oznacz jako zarchiwizowany */
# define SA_UNPROTECT   0x10      /* odbezpiecz */
# define SA_UNHIDE      0x20      /* ujawnij */
# define SA_UNARCHIVE   0x40      /* oznacz jako niezarchiwizowany */

Operacje plikowe

Każda z operacji plikowych wymaga przesłania do serwera plików sekwencji komend SIO. Sterownik po stronie Atari gwarantuje przesłanie ich we właściwej kolejności. Podstawowa sekwencja wygląda następująco:

  1. Inicjowanie operacji: rozkaz P zapisujący blok parametrów.
  2. Status: rozkaz S, pozwala przejąć od serwera korektę parametrów (głównie wielkości bufora), lub przerwać procedurę w przypadku niepowodzenia i odczytać kod błędu.
  3. Realizacja: rozkaz R nadający lub odbierający właściwy blok danych.
  4. Status: rozkaz S, odczytanie końcowego statusu operacji.

Nie każda operacja wymaga wykonania wszystkich czterech faz, spora część zadowala się pierwszymi dwiema, a nieliczne nawet tylko pierwszą.

Rozpisanie całości na tego typu fazy podyktowane jest ograniczeniami narzuconymi przez protokół SIO, który np. zasadniczo nie przewiduje przesyłania kodów błędów; SIO przesyła tylko tzw. potwierdzenia (negatywne lub pozytywne), co jest po pierwsze niewystarczające, a po drugie powoduje kłopoty, gdy sterownik SIO podejmie "samowolną" próbę powtórzenia zadanej operacji (co robi zawsze, gdy nadejdzie negatywne potwierdzenie).

Dlatego serwer plików powinien wszystko potwierdzać pozytywnie, zapisywać kod błędu do bloku statusu i liczyć na to, że program-klient odczyta go w następnym kroku. Negatywne potwierdzenie powinno nastąpić tylko wtedy, gdy komenda inicjująca jest nieprawidłowa, tzn. bajty DAUX1/2 wykazują niewłaściwy (zbyt duży) rozmiar bloku parametrów lub nieznany numer wersji protokołu.

Tabela funkcji

Zdefiniowanych jest tu 20 funkcji realizujących różne operacje na systemie plików. W rzeczywistości są to wewnętrzne funkcje kernela SpartaDOS X 4.43.

KodNazwaOpis
$00 (0)FREAD

$01 (1)FWRITE
$02 (2)FSEEK
$03 (3)FTELL
$04 (4)FILELENG
$05 (5)-Funkcja zarezerwowana.
$06 (6)FNEXT
$07 (7)FCLOSE
$08 (8)INIT
$09 (9)FOPEN
$0a (10)FFIRST
$0b (11)RENAME
$0c (12)REMOVE
$0d (13)CHMOD
$0e (14)MKDIR
$0f (15)RMDIR
$10 (16)CHDIR
$11 (17)GETCWD
$12 (18)BOOT
$13 (19)GETDFREE

Ten artykuł to tylko zalążek. Możesz pomóc rozwojowi Atariki poprzez rozszerzenie go o więcej informacji.

Personal tools