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 - Installateur d'amorce
(Article écrit par Frédéric Mazué et extrait d'Amiga News Tech - février 1990)
|
|
Une disquette formatée sous AmigaDOS comporte 1760 secteurs d'une capacité de 512 octets chacun.
Sur ces 1760 secteurs, 1758 sont utilisés par AmigaDOS pour gérer les fichiers et 2 sont soit inutilisés,
soit contiennent le programme d'amorce (boot) et la disquette est dite auto-amorçable.
Le programme d'amorce, que l'on met en place sur la disquette grâce à la commande CLI "install" est ainsi
constitué :
- On trouve d'abord 4 octets qui ne sont rien d'autre que le mot "DOS", et qui permettent à l'ordinateur de
s'assurer que la disquette a bien été formatée par lui.
- On trouve ensuite 4 octets qui sont une somme de contrôle ("checksum" en anglais) et qui est la preuve
pour l'ordinateur qu'il s'agit bien d'une disquette auto-amorçable.
- Viennent 4 autres octets formant le long mot $00000370 : cette valeur est le numéro du bloc racine (ou bloc d'amorce,
"bootblock" en anglais), premier secteur du catalogue très particulier qu'AmigaDOS utilise.
- Enfin, on trouve le programme d'amorçage proprement dit, programme très court (mais néanmoins indispensable)
qui ne fait que rechercher l'adresse de base de la dos.library résidente en ROM.
Tout ceci est très loin d'utiliser entièrement les 1024 octets des 2 secteurs d'amorce, et il est ainsi
possible de venir y greffer un petit programme de son cru, histoire de personnaliser ses disquettes.
Il subsiste quand même un problème : vous avez écrit un joli programme sur votre assembleur préféré et vous
l'avez sauvegardé sous forme d'un fichier exécutable. Comment transférer ce programme dans les secteurs
d'amorce ? Réponse : il suffit d'utiliser notre programme du mois, BootInstall - sous réserve que cela soit possible.
Ça ne marche pas toujours
Tout d'abord, un programme susceptible d'être installé dans le bloc d'amorce doit être écrit entièrement
en code relatif au PC (Program Counter) car il doit être totalement indépendant de l'adresse de chargement.
En effet, on ne peut pas savoir avec exactitude où le programme d'amorce sera chargé dans la mémoire de
l'Amiga. De plus, ce programme ne sera pas corrigé selon son adresse de chargement comme le serait un fichier
exécutable "normal".
Je vous rassure, il n'est pas du tout difficile d'écrire un tel programme grâce au jeu d'instructions
très complet du 68000 ; il suffit seulement d'y penser.
Voir à ce sujet comment est écrit le programme d'exemple.
Voyons maintenant comment AmigaDOS se débrouille avec des fichiers exécutables. En effet, tous
les programmes pour Amiga ne sont pas écrits en code relatif, et plus encore, un programme en C
par exemple ne pourra jamais l'être. Et pour corser le problème, l'Amiga est une machine multitâche,
ce qui signifie que plusieurs programmes peuvent être chargés en même temps en mémoire, le seul
critère étant la place disponible et non l'adresse de chargement.
Toutes ces contraintes font que les fichiers sur Amiga sont eux aussi très particuliers.
Ils ne sont pas constitués d'un en-tête suivi du programme comme sur les vieux ordinateurs 8
bits, mais constitués d'une ou plusieurs sections/segments appelées "hunks". Le premier segment
d'un fichier est ainsi constitué :
- D'abord un long mot indiquant de quel type de fichier il s'agit. Pour un programme exécutable,
c'est la valeur $000003F3.
- Ensuite un mot long qui est un pointeur sur le nom éventuel du segment. S'il n'y a pas de nom,
ce mot long est nul.
- Puis un mot long dont la valeur correspond au nombre de segments constituant le fichier.
- Puis une série de mots longs dont chacun est le numéro du segment à charger. L'ordre de
ces mots longs définit donc pour le DOS l'ordre de chargement des segments.
- Enfin une série de mots longs dont chacun est la longueur des segments dans l'ordre précédemment
défini.
Comme ceci n'est pas clair, voici un exemple :
00003F3 00000000 00000003 00000000
00000002 00000001 00000009 000000AA
00000128 000003E9 00000009 xxxxxxxx
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
000003F2 yyyyyyyy vvvvv... ........
|
Nous avons ici un programme exécutable (000003F3) dont le premier segment n'a pas de nom (00000000)
et qui est composé de trois segments (00000003). Sera chargé d'abord le segment numéro 0
de longueur $09, puis le numéro 2 de longueur $AA, puis enfin le numéro 1 de longueur $128.
C'est pourtant simple !
A la suite de tout cela vient normalement le mot long $000003E9 qui indique au DOS qu'il
arrive sur les données du programme, la longueur est encore une fois indiquée, et l'on a enfin
les octets du programme (les mots longs xxxxxxxx de l'exemple ci-dessus).
A la suite des octets au programme et si celui-ci est écrit en code relatif, on trouve
l'identificateur $000003F2 qui signale la fin du segment. Sinon, on trouve une table de décalages
qui permettront au DOS de modifier les adresses absolues du programme, suivant l'adresse
du chargement. C'est par ce moyen qu'AmigaDOS parvient à faire tourner n'importe quel
programme n'importe où en mémoire.
On peut également trouver beaucoup d'autres choses, telle une table de débogage, mais
cela nous entraînerait trop loin.
Enfin, derrière le mot long $000003F2 (fin d'un segment), commence, par son identificateur,
le deuxième segment et ainsi de suite jusqu'à la fin du fichier. Sachant cela, voici comment
fonctionne l'installateur d'amorce : après appel par son nom depuis le CLI ou le Shell
(Workbench interdit), il demande le nom du programme à transférer dans le bloc d'amorce.
Celui-ci est chargé en mémoire, puis on vérifie qu'il s'agit bien d'un fichier exécutable,
qu'il est constitué d'un seul segment (il serait possible de traiter un fichier de plusieurs
segments, mais les complications sont grandes pour un intérêt petit). On vérifie aussi que
le programme n'est pas trop long (952 octets maxi) et qu'il est bien relogeable. Puis les
octets du programme sont extraits et accolés aux octets d'un programme analogue à l'amorce
standard.
Pour terminer, la somme de contrôle est calculée et cette plage d'octets est
écrite dans les secteur 0 et 1. C'est aussi simple que cela, malgré ce que peut laisser
penser la taille du listing...
Le listing 2 est un exemple de programme écrit en code relogeable (relatif au PC) s'intégrant parfaitement
à l'amorce. Il ne fait rien d'autre qu'afficher quelques bandes de couleurs à l'écran et d'attendre que
l'on clique sur le bouton gauche de la souris.
|
