70 / 74

Description du format CTRaw

Le format CTRAW

Le format CTRAW est assez classiquement composés de chunk (¹).
Attention, les fichiers sont encodés en little endian (²).
Sur des machines Intel, il faut donc retourner les octets pour les avoir dans l'ordre.

(¹) Un chunk c'est un morceau : Comprendre, un morceau que l'on peut utiliser indépendamment. (souvent, il commence par un identifiant, comprend une longueur et des données supplémentaires)

(²) Little endian, c'est l'ordre des octets. Quand tu définis un entier sur 4 octets, tu peux les ordonner comme ceci :
octet poid faible en premier -> octets poid fort en dernier => little endiant (Le Z80 est little endian, comme les x86).
octet poid fort en premier -> octet poid faible en dernier => big endian (Les 68k/PPC sont big endian)
Exemple : 0x12345678 peut etre stocké :
En little endian : 78 56 34 12
En big endian : 12 34 56 78 

L'ordre des bits ne pose pas de problème.

Chaque chunk a un format identique : 

La longueur indique la taille totale. Les données en plus ont donc une longueur égale à la longueur de l'en-tête moins 12.

Les chunks utilisés pour le CT-RAW sont les suivants :

Détaillons maintenant ces chunks :

*** CAPS : 
Rien d'autre que id, la longueur et le CRC...


*** TRCK : 

La taille d'un chunk TRCK fait donc toujours 28 (12 + 16)
Le numéro de piste et de tête sert à savoir où l'on se trouve (indexé sur 0 à chaque fois)
L'ID permet de faire le lien avec les données contenues dans les chunks DATA.


*** DATA : 

Les données supplémentaires servent à stocket les informations de la piste à proprement parler.

A la suite de cela, deux chunks inclus de type PACK
- La densité (pour le moment, je n'en vois pas l'utilité... ?) - Taille = Taille des données de la zone "densité"
- Les données elles-même : Idem, la taille a été lue juste avant (Taille des données de la zone piste)

Je passerais sur la première zone de PACK : Pour le moment, aucune idée de son utilité.

La seconde zone de pack est codée comme ceci

* PREMIERE PISTE
Les données MFM en clair (pas de compression). La taille fait celle indiquée par le premier champs des tailles de révolution.


* PISTE SUIVANTES
C'est un peu plus encodé.
Pour chaque piste : On va lire, a chaque fois, les données jusqu'à atteindre la taille précisée dans la taille de la révolution.
Décodage :

• On lit le premier octet 
• Si son bit de poid fort est à 1, il s'agit d'une copie à partir de la révolution 0
• Sur cet octet, les bits 6-5-4 indique s'il s'agit d'un décalage.( et le nombre de bits de décalage)
• Les 4 bits restant * 256 + l'octet suivant indique la taille en octet a copier.
• Les deux octets suivants indiquent l'offset référence sur la révolution 0 (en octet)

A partir de là, on va donc recopier les bits depuis la révolution 0, vers la révolution en cours.
Le décalage indique le nombre de bits à "zapper" depuis la source (ça permet de faire de la copie de bit, en fait)

• Sinon, on a une zone de donnée "brute" (en MFM toujours). La taille : cet octet * 256 + le suivant . Il suffit de recopier cet octets vers notre position courante

Article rédigé par Lone