L' Amiga supporta due diversi formati di codifica. Quello usato nella maggioranza dei casi e' il MFM (Modified Frequency Modulation). L' altro e' il
GCR (Group Coded Recording).
Ogni traccia contiene i BITs scritti sul disco come variazioni della magnetizzazione. Un cambio nella magnetizzazione corrisponde ad un BIT ad 1, una persistenza nella magnetizzazione a 0. La distanza tra due cambi (pulses) e' espressa come misura del tempo, di solito microsecondi (us). L'Amiga controlla le pulses ogni 2 us. Se non si e' verificata nessuna variazione, il BIT e' spento (0). Se la variazione e' incontrata il BIT e' acceso (1).
La scrittura dei dati in questo modo causa un problema. Il tempo delle modificazioni di magnetizzaione potrebbe non essere troppo lungo, o il controller del disco potrebbe non essere sincronizzato con i dati. Questi problemi potrebbero essere causati da una diversa velocita' del drive da quella con la quale i dati sono stati originalmente scritti.
Per risolvere questo problema e' necessario che i dati siano codificati in maniera tale da eliminare troppi BITs nulli (0) consecutivi. Il controller deve sapere quando leggere i dati dal disco. La soluzione consiste nel marchiare l'inizio dei dati con una combinazione di BITs che non puo' succedersi normalmente. Questa e' un' altra ragione per la quale i dati devono essere codificati. Una speciale combinazione di questo tipo si chiama Sync Mark.
L'Amiga supporta due differenti tipi di temporizzazione per la memorizzazione.
2us e' la comune del formato Amiga (MFM), e 4us e' usata per il formato GCR.
Questo e' il sistema standard usato dall'Amiga. Speciali "clock" bits sono inseriti tra ciascun BIT dei dati per assicurare che il controller non perda la sinconizzazione con i dati. Questo risolve il problema esposto prima evitando che si susseguano troppi BITs nulli. Il modo in cui i "clock bits" sono aggiunti e pittosto semplice. Se un data bit adiacente e' 1, un reset clock bits (0) e' inserito, se un data bit adiacente e' 0, un set clock bit (1) e' inserito.
Per esempio - codifichiamo il valore $78:
Byte: $78 Bits: %01111000
La codifica darebbe il seguente risultato:
Data bits: % 0 1 1 1 1 0 0 0^
Clock bits: % 1 0 0 0 0 0 1 1
Encoded: %1001010101001010
Per la sincronizzazione, sul disco e' cercata una particolare sync word. Questa word non puo' essere contenuta nell'area dei dati, altrimenti il controller sarebbe tratto in errore. Quindi deve essere costituita da una combinazione che non puo' essere riprodotta dalla codifica dei dati. Una sequenza di questo tipo consiste in una successione di "clock bits" nulli tra i bit dei dati nulli.
Normalmente un "clock bit" 1 e inserito tra due "data bit" 0. L' AmigaDos usa la seguente Sync Word $4489.
d d
$4489 = %0100010010001001
c
L'altro formato supportato dal controller dell' Amiga, e il GCR (Group Code
Recording). Questo formato occupa meno spazio sui dischi, ma ha anche uno svataggio: Il formato GCR codifica 4 data bits in 5 data bits. Dopo una codifica
GCR non ci sono piu' due bits nulli consecutivi, o piu' di 8 data bits a 1 consecutivi. Tutto cio' elimina i problemi casusati dalla successione di troppi bits nulli. Lo svantaggio e' rappresentato dal fatto che troppi 1 possono essere consecutivi. Il controller non puo' procedere troppo velocemente, cosi' la densita' di registrazione deve essere ridotta, rallentando la velocita' di registrazione della meta', ovvero passa da 2us a 4 us.
La seguente e' la tavola di codifica del formato GCR:
Hex. Dec. Binary GCR
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$0 0 0000 01010
$1 1 0001 01011
$2 2 0010 10010
$3 3 0011 10011
$4 4 0100 01110
$5 5 0101 01111
$6 6 0110 10110
$7 7 0111 10111
$8 8 1000 01001
$9 9 1001 11001
$A 10 1010 11010
$B 11 1011 11011
$C 12 1100 01101
$D 13 1101 11101
$E 14 1110 11110
$F 15 1111 10101
per esempio, $28 = %0010 1000 = 10010 01001 = 1001 0010 01
$9 $2 --
La sincronizzazione dei dati GCR e' differente come il resto. Essendo impossibile ottenere 8 bits (1) di seguito, si sfrutta questa limitazione: Il controller organizza 9 o piu' bits 1 in sequenza e li considera come un Sync
Mark.
La lettura comincia immediatamente dopo aver trovato un bit 0 dopo un Sync Mark. Il primo dato dopo una Sync Mark deve cominciare con un bit nullo. Se cio' non accade, il DATA sara' shiftato di un opportuno numero di bits.
La struttura dei dati potrebbe apparire cosi':
$FFFF ......FF55 .....Data
Sync Sync-End Data bits
Ogni traccia in formato Amiga contiene 11 settori ciascuno di 512 bytes. I dati sono memorizzati con la codifica MFM. Vi e' inoltre un informazione che precede ogni settore, il cui compito e' quello di informare il DOS di quale settore si sta leggendo.
Gli Headers e i settori sono cosi' organizzati:
MFM Data Information
$AAAA $00
$AAAA $00
$4489 - Sync Word (Normal AmigaDOS)
$4489 - Sync Word
$xxxx $FF *Format I.D. ($FF = AmigaDOS)
$xxxx
$yyyy $?? *Track Number
$yyyy
$zzzz $?? *Sector Number
$zzzz
$xxxx $?? *Number of sectors 'til gap.
$xxxx
$AAAA(32 words) *Unused area
$xxxx(16 words) *Block Checksum (long)
$yyyy(16 words) *Data Checksum (long)*Lo schema qui sopra riproduce l' header di un settore in AmigaDOS, che sara' seguito da:
$zzzz (1024 words) Sector data (512 bytes)
...e quindi il settore successivo...
$4489 - Sync Word
$4489 -
...etc...
Il Format Identification indica al sistema che la traccia letta e' in formato
AmigaDos (se F.I. = $FF). Un disco MS-DOS e' ache codificato nel formato MFM, ma usa un F.I. uguale a $FE per i sector header, e $FB per i dati, entrambi preceduti da 3 sync word $4489. Inoltre la struttura della traccia e' completamente differente.
Il Track Number contiene il numero della traccia appena letta.
Il Sector Number contiene il numero del settore letto.
Il byte successivo contiene il numero dei settori prima del gap, in tale numero e' incluso anche il settore corrente. Quindi, se il valore e' 1, il gap segue immediatamente il settore attualmente in lettura. Questo byte e' importante nel formato AmigaDos, poiche' il gap si puo' trovare in una differente posizione su ciascuna traccia, e per di piu' vi puo' essere un gap dopo ogni settore, nulla lo vieta.
I successivi 16 bytes non sono impiegati. Originariamente furono inseriti per contenere le informazioni necessarie per il recupero dei dati nel caso il settore fosse danneggiato, ma non sono mai stati utilizzati
I successivi 16 bytes contengono la Block Checksum e la Data Checksum. Queste sono usate dal DOS per trovare degli errori sul disco. Entrambi sono formate da dati codificati e memorizzate in formato MFM.
N.B. Alcune protezioni anticopia alterano le checksum, rendendo il dischetto illeggibile dal DOS, sebbene i dati sono ancora corretti.
Riassumendo, ogni settore e' costituito da 64 ($40) bytes di Header, e 1024 ($400) bytes di dati. Quindi in ogni blocco sono contenute 1088 ($440) bytes. Su ciascuna traccia sono contenuti 11 settori e un track gap (di circa 696 ($2B8) bytes). Tutto cio' rende una traccia lunga 12664 ($3178) bytes.
Il track gap e' un gruppo di dati che viene scritto sulla traccia insieme ai settori. Il gap non contiene informazioni significative. Mentre e' importantissimo in fase di scrittura dei dati per non sovrascrivere le informazioni che si sono appena scritte. Essendo la traccia circolare, un gap di sicurezza deve essere frapposto tra l' ultimo ed il primo settore. Un altro motivo per l'esistenza del gap e' il seguente: nella traccia potrebbe non esserci sufficiente spazio per la scrittura dell' ultimo settore, quindi esso eccederebbe distruggendo il primo settore. Il gap di solito e' lungo 696 ($2B8) bytes nel fomato Amiga,pero' cambia sensibilmente in funzione della velocita' del motore del drive. Normalmente il gap e' la prima cosa che viene scritta sulla traccia, e subito dopo tutti gli altri settori, tale oridine e' necessario affinche' l'ultimo settore si sovrapponga in parte al gap e non la primo settore distruggendo irrimediabilmente le informazioni in esso contenute. E con questo credo di aver concluso il discorso sulla codifica dei dati sul disco, prima di terminare facciamo il seguente calcolo:
12664 bytes x 160 traccie = 2026240 bytes = 1.9 Mbytes
Questa e' la quantita reale di informazioni contenute nel disco AmigaDos!