Magazine Pom's : la collection

Gestion de fichiers avec RWTS
Ce n'est un secret pour personne : le
005 de ]' Apple Il n'est pas des plus
rapides, notamment lorsqu'il lui faut
gérer des fichiers de données. Partant
de cette constatation, certains
ont conçu, réalisé et commercialisé
des systèmes DOS complets, destinés
à remplacer ou relayer le système
standard.
Cet article ne se propose pas de
vous donner un tel système (un numéro
spécial de Parn's n'y suffirait
pas, sans parler des heures de travail
que cela supposerait. ..). En fait, il
s'inscrit dans le prolongement des articles
déjà publiés sur le thème des
fichiers, poUf, illustrer cette fois une
méthode de gestion de table d'index
par programme assembleur et ]'accê$
"direct" aux disquettes par RwrS.
Le système s'applique à la gestion
d'un gros fichier de données (placé
dans le drive 2) qui se suffit à lui
même (fichier d'adresses pour mai-
6ng, par exemple), ou qui inter-agit
avec d'autres fichiers plus petits
(p0cé$ sur une disquette en drive 1),
gérés quant à eux par le DOS standam.
L'implantation en mmolre des routines,
tables et buffers est conçue pour
48K de mmoire centrale (la sectorisation
est celle du DOS 3.3).
La table d'index
Rappelons qu'un lment de la table
d'index se compose d'une cl, qui
identiBe chaque enregistrement du fi·
chier de données, et de l'adresse de
cet enregistrement sur la disquette.
L'adresse est code en deux octets,
mais nous y reviendrons plus en détail
ultérieurement.
La table est gérée par un programme
en assembleur et se prsente sous la
forme d'un tableau en mmoire centrale,
ou plus exactement d'une succession
de blocs de 256 octets chacun.
Pour simplifier les choses (qui
ne seront donc pas optimales ... ),
l'adresse de début du premier de ces
blocs doit être un multiple de 256.
Soit PO cette adresse en dcimal
(pour le BASIC), elle se compose en
hexadcimal d'un octet haut
(HB=P0/256) et d'un octet bas toujours
égal à O.
Si Le est la longueur de la cl, non
compris les deux octets de l'adresse-
Pom's n° 9
disquette, on peut mettre Ne clés
dans un bloc de 256 octets, avec
NC=INTI256ILC21.
Dans un bloc donn, l'octet bas de
l'adresse du premier caractère de la
dernIère clé que J'on peut y stocker
est OO=(NC-1)*(LC+2) ; l'octet
haut de cette adresse correspond à
HB pour le premier bloc, HB+ 1
pour le second ...
Dans les deux premiers octets avant
PO, on stocke le nombre d'éléments
qui se trouvent dans la table, soit
NZ= PEEKlPO-21.256+ PEEKlPO-ll
L'adresse du premier caractère de la
dernière clé de la table peut se calculer
de la façon suivante (HM=octet
haut et LM=octet bas) :
NB=nombre de blocs utilisés pour
stocker les NZ clés=INT{NZlNC)
• Si NZNC*NB :
HM=HB+NB
LM=((NZ -NB.NCI-II'ILC+ 21
• Si NZ=NC*NB :
HM=HB+NB-1
LM=OO
Pour la suite, baptisons AMAX=
HM*256+LM cette adresse.
Principe de recherche
dans la table
Une fois entre la cl recherchée (au
clavier, ou à partir d'un autre fichier),
on la stocke dans une zone de travail
commençant en $311. Ensuite, on la
compare à la dernière clé de chacun
des blocs utilisés, jusqu'à ce qu'on
trouve, si possible, celui dans lequel
elle pourrait se situer (le premier
pour lequel elle est inférieure ou
égale à la dernière cl stockée). On
explore alors ce bloc à partir de la
première clé qu'il contient, pour voir
si la clé recherchée s'y trouve. Dans
tous les cas, la routine mettra en $IF
le résultat de sa recherche (0 si la clé
n'existe pas et 1 dans le cas
contraire) et rangera dans $IC et
$10 l'adresse, virtuelle ou réelle, de
la c1 recherche dans la table.
Cette méthode suppose que les cls
soient classées dans l'ordre alphanumérique.
Ainsi, une autre partie de la
routine assure le décalage de la
table, en cas de création d'une nou·
velle dé dont l'adresse virtuelle est
inférieure ou égale à AMAX (en
d'autres tennes, lorsque la nouvelle
Gérard Michel
dé ne vient pas en extrême fin de la
table).
De même, en cas d'annulation d'une
dé qui ne serait pas la dernière de la
table, une troisième sous· routine as·
sure le décalage "vers le bas" et
l'krasement de la clé concernée.
Remarques pratiques
Le programme BASIC listé ci·après
donne un exemple d'utilisation pour
une table comportant 500 dés de 9
caractères. L'adresse PO est calculée
comme suit:
- NC=INTl256llll=23
- Il faut donc 22 blocs pour contenir
les 500 dés, soit 5632 octets, plus
deux pour stocker NZ, arrondissons à
5640 octets.
- Le dernier buffer de la gestion du
fichier (voir plus lOin) commençant à
35207, on a HB=INT({35207-5640)1
256)=115, et PO=115_256=29440.
L'Initialisation de cette table (avant
tout traitement) se fait donc par :
POKE 29438,0,POKE 29439,0,
BSAVE TABLE A2943B,L5640,Dl
(on la place sur la même disquette
que les programmes, en Dl J.
Le chargement de la table en mé·
moire à partir des programmes se
fera ensuite par BLOAD.
Le fait de disposer d'une table utilisable
sous fonne d'un tableau gérable
en assembleur présente de nombreux
avantages :
· BLOAD el BSAVE sont beaucoup
plus rapides que la lecture ou l'écri·
ture d'un Bchier TEXT dans lequel
seraient stockées les clés.
- En mémoire centrale, vous n'avez
plus à créer un tableau de variables
alphanumériques pour stocker les
clés. Vous économisez ainsi :
• 3 octets par élément de la table
(liés au traitement des tableaux
par BASIC)
• les problèmes de "garbage" liés à
la gestion d'un grand tableau dont
les valeurs changent souvent, lors
des décalages de la table notammenl
- Si votre programme est interrompu
(par RESET par exemple) vous pou·
vez toujours sauver votre table par
47