Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : Assembleur - Hide Dir-Cache
(Article écrit par Lionel Guillang et extrait d'Amiga News - décembre 1993)
|
|
Comment lire sous AmigaOS 2.0 les disquettes "cache" d'AmigaOS 3.0 ?
Quel possesseur d'Amiga antérieur au système 3.0 n'a jamais pesté contre un ami distrait ou ignorant
lui apportant des disquettes formatées avec un cache ? En effet, que ce soit en 1.3 ou en 2.0,
AmigaDOS vous dira, et répètera si vous insistez, qu'elles ne sont pas DOS... Gasp !
Pourquoi tant d'intolérance ? Heureusement, voici un tout petit utilitaire, mais ô combien précieux pour
résoudre ce problème douloureux.
Filesystems = imbroglio ?
Avant l'avènement du système 3.0, les choses étaient relativement simples puisque seuls deux systèmes de fichiers (filesystems)
existaient (je ne parle pas des émulations) : l'OFS ou ancien système de fichiers (standard jusqu'au système 1.3)
et le FFS ou système de fichiers rapide (apparu avec le système 1.3).
Là où ça s'est un peu compliqué (mais pas tant que ça, vous allez voir), c'est lorsque sont venus s'ajouter le cache
pour les répertoires et le mode international. Ce n'est pas si difficile que parce que, contrairement à l'OFS et
au FFS qui sont des systèmes de fichiers à part entière, le cache et le mode international ne sont, eux, que des
implémentations. En effet, la façon dont sont stockées les données sur une disquette est toujours rigoureusement la
même, avec ou sans cache, ce qui n'est pas le cas lorsqu'on passe de l'OFS au FFS.
Le cache de répertoires n'est donc pas un nouveau système de fichiers ; on comprend alors aisément qu'il
puisse être utilisé avec des disquettes OFS comme FFS. Il était utile de (re)préciser tout ça, parce que notre
utilitaire ne se préoccupera pas de savoir pour quel système de fichiers telle ou telle disquette a été
formatée ; seule la présence d'un cache le fera entrer en action.
Concrètement
Il est des moments où il faut savoir se pencher sur des réalités bassement matérielles ;
c'en est un ! Que se passe-t-il lorsqu'on insère une disquette dans un lecteur ?
Tout d'abord, c'est le bloc d'amorce (bootblock) qui est lu, parce qu'il contient, dans
ses quatre premiers octets, l'identificateur de format de la disquette ;
celui-ci est comparé aux identificateurs du (ou des) système(s) de fichiers dont le (les)
handler(s) est (sont) attaché(s) au lecteur (DF0: par exemple). S'il ne correspond à aucun
identificateur connu, la disquette est marquée NDOS (non-DOS) et aucun accès AmigaDOS dessus
ne sera possible.
C'est donc à ce moment-là qu'il faudra intervenir et donner à AmigaDOS ce qu'il attend,
c'est-à-dire un identificateur connu. La disquette sera alors reconnue et vous pourrez donc
y lire tout ce que vous désirez. Miraculeux ? Non, cela s'explique très simplement par le fait que
les données sont agencées sur la disquette de la même façon, avec ou sans cache ;
le système de fichiers approprié (OFS ou FFS) parviendra donc à ses fins si on lui, oserai-je le
dire, cache le cache.
Trop beau...
Les plus pessimistes d'entre vous l'avaient senti : il y a quelques petits inconvénients.
Le premier, c'est que si vous avez l'intention de réutiliser ultérieurement votre disquette
sous système 3.0, vous ne devez en aucun cas écrire dessus sous votre ancien système :
en effet, en cas d'écriture, le cache ne sera pas mis à jour (ce qui devrait pourtant être fait),
et la disquette deviendra de fait corrompue aux yeux du système 3.0, pouvant entraîner un
plantage total de la machine.
Le second, c'est qu'en cas d'insertion d'une disquette dont le format n'est pas connu. Il
n'y aura aucun moyen de savoir si elle a un cache ou non : en effet, le correctif
trompera toutes les tâches, y compris un éditeur de secteurs.
Le troisième inconvénient est, lui, vraiment mineur, mais il existe tout de même :
les secteurs utilisés par le cache ne seront pas restitués. Ceux-ci deviendront inutilisés mais
resteront alloués, d'où une perte (légère) au niveau de la capacité de la disquette.
Le programme
Le but de la manoeuvre, rappelons-le, est de donner à AmigaDOS l'identificateur de
format qui nous arrange, au moment où il lit le bloc d'amorce ; cela peut être réalisé
très simplement en modifiant le trackdisk, et plus précisément la fonction BeginIO().
Il n'y aura plus alors qu'à intercepter les accès en lecture au démarrage
et à masquer les bits signalant un éventuel cache (ainsi que le mode international).
L'identificateur, pour une disquette AmigaDOS, a l'allure suivante : "DOSx".
La chaîne "DOS" est constante, seul l'octet "x" varie. Le format est codé dans les trois premiers
bits :
bit 0 : 0=OFS, 1=FFS
bit 1 : 1=international
bit 2 : 1=cache
|
Il suffira donc de masquer les bits 1 et 2 pour leurrer AmigaDOS. Naturellement,
cela ne marchera que si le système de fichiers de base est reconnu (inutile d'essayer
avec une disquette cache FFS si votre Amiga ne reconnaît déjà pas le FFS simple).
Le correctif se déroule de la façon suivante : on reçoit l'adresse de la structure
IORequest dans a1 ; on peut alors facilement déterminer quel(s) secteur(s) est(sont)
adressé(s) et quel ordre est demandé, en examinant respectivement les champs IO_OFFSET
et IO_COMMAND ; on ne filtre que les accès au bloc de démarrage (IO_OFFSET nul) en lecture ;
le test sur IO_COMMAND est fait sur les 8 bits de poids faible, ce qui permet de prendre
aussi en compte les commandes étendues (voyez les docs spécialisées pour plus de détails).
Lorsqu'on est sûr de notre coup (lecture sur le bloc de démarrage), on appelle la
fonction BeginIO() normale qui va déclencher la lecture. C'est là que se trouve la
plus grosse difficulté, s'il en est, du programme : la fonction BeginIO() déclenche
des opérations asynchrones, ce qui signifie, dans notre cas, que la lecture a peu
de chance d'avoir été faite lorsqu'on récupère la main.
Il va donc falloir attendre
avant de pouvoir altérer le tampon mémoire de lecture, sans quoi ce sera un coup
d'épée dans l'eau. On vérifie tout de même que la lecture n'est pas encore accomplie en appelant la
fonction CheckIO() : si par un heureux hasard elle répond "TRUE", pas besoin d'attendre,
tout est déjà terminé ; dans le cas contraire, il faut attendre manuellement ;
je dis manuellement parce qu'on ne peut pas utiliser la fonction WaitIO() étant donné
qu'elle retire les structures IORequest des ports de réponse, et on ne le veut pas
(ceci est normalement effectué par la tâche qui a appelé BeginIO()). La solution
consiste à attendre avec WaitPort() que le message de réponse du trackdisk arrive et
ceci, c'est important, sans toucher à quoi que ce soit (pas de GetMsg() ni de ReplyMsg()),
la tâche qui a appelé BeginIO() trouvant ainsi les choses telles qu'elles sont habituellement.
Il reste alors à modifier le bloc d'amorce, ce qui ne pose aucun problème :
on vérifie d'abord que la lecture s'est bien passée (IO_ERROR), et que la disquette
est au format AmigaDOS (on ne va pas s'amuser par exemple à modifier
les disquettes MS-DOS). Enfin, on peut masquer les bits importuns,
mais ce n'est pas tout : si la disquette est installée, il faut encore recalculer la
somme de contrôle (sous réserve que le démarrage ait été complètement lu (deux
secteurs au moins)).
Le reste n'appelle aucune remarque particulière, si ce n'est que le correctif
restera actif tant qu'un redémarrage ne sera pas effectué. Il y a deux améliorations qui seraient
intéressantes : la première consisterait à ajouter une tâche qui neutraliserait le correctif
lorsqu'on presserait une touche, qu'on activerait un menu... La seconde, à signaler
l'insertion d'une disquette ayant un cache, avec une requête par exemple, de façon à
ce que l'utilisateur ne soit pas, lui aussi, leurré.
|
