Le sujet des "nibbles" est le sujet le plus déconcertant pour les débutants alors même qu'il est relativement simple à comprendre. Il faut cependant bien dire que ce ne sont pas les magazines qui ont simplifié la compréhension et l'utilisation indifférenciée de nibbles, bytes ou octets n'a pas participé à l'édification des foules.

Mais alors qu'est-ce qu'un nibble ?
Normalement un nibble est un demi octet soit 4 bits. Hélas par abus de langage, dans le cas de l'APPLE II et du DISK II il s'agit en fait de rien d'autre qu'un octet écrit sur la disquette ... (donc si on a 8 bits, maintenant c'est un octet ? eh bien non c'est quand même un nibble ! Pour assurer la confusion il n'y a pas mieux non? ) Mais attention si on parle d'octet à la place de nibble, ce n'est pas n'importe quel octet !

En effet il y a des contraintes bien spécifiques au lecteur de disquette (le système de détection de la carte contrôleur en fait) qui font qu'il n'est pas possible d'écrire l'ensemble de la page des valeurs possibles d'un octet de donnée, à savoir de $00 à $FF.

Nous avons vu précédemment dans la rubrique "les types d'enregistrement" qu'APPLE utilise le GCR et qu'il doit y avoir suffisamment d'inversions de champs magnétiques pour pouvoir assurer le self-clocking. En nous obligeant à avoir systématiquement un 1 une fois sur deux et en utilisant les bits intérmédiaires comme seuls porteurs de signification, c'est à dire par l'utilisation d'un masque de type 1010.1010 ($AA) nous remplissons cette condition et SEULES les positions 0 intermédiaires du dit masque sont utilisées soit pour des 1 soit pour des 0 ce qui permet une utilisation des valeurs signifiantes de 0000 à 1111 ($0 à $F) ... ce qui est précisement un demi-octet : le NIBBLE ! (CQFD).

On notera que les 1 du masque 1x1x.1x1x jouent alors ni plus ni moins le rôle de bits d'horloge sans pour autant qu'ils soient distinguables des bits de données. Ces 1 ont d'ailleurs été présentés dans la littérature technique comme étant de réels bits d'horloge pour permettre une compréhension plus aisée de la self-synchronisation.

La table des valeurs qu'il est alors possible d'écrire sur la disquette (les NIBBLES donc !) est la suivante :



Cette table correspond à ce que l'on appelle le CODAGE 4.4 détaillé plus loin en rubrique "codage des données"



Mais WOZNIAK à fait mieux !

Il n'est pas difficile de constater que la disquette est très vite remplie, Wozniak s'est aperçu qu'il y avait tout de même bien plus de 16 valeurs qui ont le bit 7 à 1 et n'ont pas deux 0 contigus, il a donc eu l'idée d'utiliser l'ensemble de ces valeurs qui respecteraient ainsi le self-clocking sans une modification inconsidérée du matériel. Ces valeurs sont alors aisées à utiliser au moyen d'un système de codage et d'une table de translation.

Rappelons donc les contraintes spécifiques pour les valeurs de ces "nouveaux" nibbles.

CONTRAINTE NUMERO 1 Un NIBBLE DOIT OBLIGATOIREMENT AVOIR LE BIT 7 à 1

L'explication de cette contrainte générale pour TOUS les formats APPLE trouve sa justification dans la rubrique "synchronisation".

De simple fait d'avoir le bit 7 à 1, l'ensemble des valeurs de $00 à $7F est éliminé !

Vous allez dire que c'est bien amusant car il va bien falloir trouver un moyen de les écrire ces valeurs... eh bien oui, c'est même l'objet du codage des données, dont la finalité est de transformer les octets de données en nibbles. Comme vous vous en doutez, si vous voulez écrire 256 octets variant de $00 à $FF il faudra écrire plus de 256 nibbles sur le disque pour pouvoir les retrouver.

CONTRAINTE NUMERO 2

CAS DU DOS 3.2 :

          Un NIBBLE NE PEUT PAS AVOIR DEUX 0 DE SUITE

Voici la liste des nibbles valides pour le DOS 3.2. On constate qu'il y en a 34 dont 2 sont reservés pour les marqueurs de champ... il en reste donc 32 utilisables pour réaliser un codage : c'est mieux que les 16 du codage 4.4 qui précède!



CAS DU DOS 3.3 :

En réalisant une légère modification du matériel et du logiciel il est possible d'étendre au maximum les possibilités d'enregistrement en modulation de fréquence sur une disquette.

          Un NIBBLE NE PEUT PAS AVOIR PLUS D'UNE PAIRE DE 0
          Un NIBBLE DOIT AVOIR AU MOINS UNE PAIRE DE 1 sur les bits b0 à b6
Concernant cette seconde règle, il semble que ce soit pour éviter le risque de rencontrer aléatoirement dans la zone des donnés des séquences qui donneraient la suite $D5 $AA. De ce fait vous constaterez que les nibbles :
$95 $A5 $A9 $CA $D2 $D4 sont éliminés mais pourraient être légitiment utilisés.

Examinons donc la liste des nibbles valides pour le DOS 3.3



Subtilement vous remarquez que le premier nibble valide est $96, si vous avez utilisé un éditeur de piste pour regarder ce qu'on y trouve vous avez certainement vu de longues zones avec ces $96 et vous vous êtes demandé "pourquoi cette valeur?" eh bien première réponse c'est parce qu'il s'agit d'un nibble valide... et surtout, seconde raison, c'est parce qu'on lui associe la valeur de l'octet de données $00 et qu'en formattant une disquette votre buffer étant normalement rempli de $00 le codage vous donne $96 comme valeur devant être écrite sur la disquette... habile transition pour parler maintenant de la table de transalation !
La table de translation
La table des nibbles valides s'appelle la table de translation. Sa construction est une petite merveille de programmation dans le code de la PROM du contrôleur du lecteur de disquette.

Son utilisation est astucieuse, il faut prendre bien garde à l'alignement du début de la table en mémoire car cela peut rendre totalement impossible un décodage.

La valeur codée sert d'index > LDA TABLE,index > A contient le NIBBLE à écrire

Comment ça marche en DOS 3.2?
Il va sans dire que dans le cas du DOS 3.2 le calcul est un peut différent car il n'y a que 32 nibbles valides (soit $20 en hexadecimal et avec 0 comptant également la valeur maximale d'index est de $1F ) les octets sont donc découpés sous la forme 000x.xxxx et, sachant qu'un buffer de 256 octets est composé 256 * 8 soit 2048 bits,
cela vous donnera 2048 / 5 = 409 octets + un reste de 3 bits

Vous devrez donc en fait écrire 410 éléments (nibbles) sur la disquette pour stocker les 256 octets de données qui sont en mémoire. Le schéma global est alors :



Comment ça marche en DOS 3.3?
En fait vous notez que vous avez 64 nibbles valides pouvant être écrits sur la disquette soit en hexadécimal $40 nibbles. Votre problème est que vous devez être capable écrire les 256 valeurs possibles d'un octet soit $00 à $FF... ce qui est donc impossible par bijection (en clair un nibble ne peut pas correspondre directement à un octet de donnée car il n'y en a pas assez).

La solution est donc le codage ! cela consiste en DOS 3.3 à découper vos octets de données et à les mettre sous la forme 00xx.xxxx de façon à ne jamais avoir une valeur supérieure à 0011.1111 soit $3F qui est par magie précisement le nombre maximal pour l'index d'une table de nibbles qui en comporte précisement $40... (avant de râler, merci de ne pas oublier que l'index 0 compte.)
(l'explication technique détaillée des codages possibles se trouve dans la partie codage des données

Revenons à notre DOS 3.3, sachant qu'un buffer de données est de 256 octets et que l'on admet qu'un secteur de disquette doit contenir 256 octets de données :
vous avez 256 * 8 = 2048 bits à organiser...
pour en faire des tranches de 6 bits (les fameux x de 00xx.xxxx)
ce qui vous donne 2048 / 6 = 341 octets + un reste de 2 bits

Vous devrez donc en fait écrire 342 éléments (nibbles) sur la disquette pour stocker les 256 octets de données qui sont en mémoire. Et voici le schéma global, analogue à celui du DOS 3.2 :



HACKING CORNER
LE NIBBLE COUNT

Il s'agit d'un système de protection consistant à compter le nombre de nibbles sur une piste, soit toute la piste soit sur une zone particulière. Ce type de protection impose souvent un paramétrage du programme de copie car il faut pouvoir conserver la longueur de la piste copiée le plus proche possible de celle qui est lue.
LE MELANGE DES NIBBLES

Il s'agit d'une protection qui consiste à changer de place deux ou plusieurs nibbles. Les tables qui sont données plus haut sont les tables standard en ce sens qu'elles comportent les nibbles valides dans l'ordre croissant. Ainsi en DOS 3.3 le codage de $00 donne $96 mais si vous inversez dans votre table de nibbles le $96 avec le $EB ou n'importe quel autre nibble d'ailleurs, il est impossible à un DOS normal de décoder les secteurs ... ou plus exactement il décodera n'importe comment, ce qui revient au même.

Bien évidement notre DOS modifié doit avoir les tables de nibbles modifiées de façon parfaitement identiques pour la lecture et pour l'écriture... et les routines de lecture/écriture sont elles mêmes modifiées.