La presse commence à parler d’une retraite repoussée à 66 ans, mais 62 pour les métiers pénibles. Qu’il en soit ainsi. J’ai dépassé l’âge de référence. Il est temps de prendre ma retraite !
Imaginez la difficulté du métier de rédac’chef, la pénibilité de ce travail (qui plus est non rémunéré Mr.President). A chaque échéance, le stress de la date de sortie du mag est là. Faute d’articles, il me faut prendre ma machine à écrire (celle là même avec laquelle j’ai écrit mes premières pages pour MPM Magazine ; certes j’ai changé le ruban, un peu comme les stylos de ma MCP40 sur leur barillet), le Larousse et autres dictionnaires des synonymes pour réaliser des articles mode 3000 m steeple sous la main, me voilà parti pour écrire les pages qui permettront d’avoir un mag reprenant plus ou moins l’actualité de notre machine préférée. Vous n’imaginez pas non plus les contorsions de la main nécessaires pour réaliser quelques malheureux croquis qui ponctueront les articles et donneront un peu de couleur et d’espace aux pages du mag.
Le temps est venu. Les prochains magazines resteront à l’état de feuillet au fond d’un classeur. Fini ce stress, ces heures passées à collecter des idées, à mettre de coté des news pour les partager un peu plus tard. Finie la pression permanente du Comité d’Administration pour que sorte le magazine, et les remarques à propos de telle ou telle coquille, date erronée, ou pire d’une faute d’orthographe. Place au temps libre. Et il va m’en falloir pour rattraper ce temps. L’âge aidant j’ai plus de difficultés à apprendre et je vais devoir redoubler d’efforts entre deux remontants pris sur la plage sur une des plateformes protégées du vent glacial du nord (sans doute une des plus belles réalisations de la ville ces dernières années). Heureusement, le Printemps arrive et avec lui les beaux jours pour profiter de mes micros 8 bits sur la terrasse de mon jardin.
Peut être vous croiserais-je sur un de mes rares passages sur les réseaux sociaux . Ceux là même qui ont d’abord tué les forums, puis les mags et fanzines car c’est tellement plus simple de faire un post de trois lignes, un instantané qui sera introuvable passé la première lecture. Et bon courage à tous les créateurs, la cible de tous ces nouveaux outils (Grok, Google AI, CoPilot, OpenAI, Canva, …). Longue vie à vous.
Prompt : “A bon entendeur. Salut. “
NDLR : Du coup, il y a une offre d’emploi de Redac’chef pour le CEO si quelqu’un veut s’atteler à la tache pour le CEO-MAG et l’OricMag mort-né.
Dans le CEO-Mag 368, Didier se faisait l’écho des tests de Rax sur le mode LORES 1, très rarement utilisé. Au passage, il apportait l’explication sur la différence entre les caractères semi-graphiques sur Oric-1, et sur Atmos: sur Oric-1, ils sont définis sur une matrice de 8×8 pixels, alors que l’Oric n’en affiche que 6×8. Ils ont donc un aspect bizarre, décentré, et Didier en concluait “on oubliera vite ce jeu de caractère dans le cadre d’une utilisation sur Oric-1”.
Bien qu’ayant globalement été oublié tout court, j’ai eu à coeur de remettre le mode LORES 1 à égalité entre l’Oric-1 et l’Atmos ! Voici donc un modeste programme bricolé rapidement, 38 octets ayant pour but de corriger, après le boot de l’Oric-1, les caractères LORES pour les rendre identiques à ceux de l’Atmos. Cette routine redéfinit simplement les caractères LORES en les décalant d’un bit vers la gauche. Elle est relogeable où l’on veut en RAM. Elle ne modifiera qu’une fois les caractères: s’il ont déjà été corrigés, la lancer ne produira plus d’effet. Elle peut donc sans risque être lancée au début d’un programme. La redéfinition de caractères résistera à HIRES/TEXT, mais pas à un reset à chaud: il faudra alors lancer à nouveau la routine.
Voici le code:
AD 08 B9 LDA $B908 Let's control if we already seem to have the right values C9 38 CMP #$38 by testing one F0 1E BEQ exit If so, exit! A2 00 LDX #$00 else get ready to change a whole page
loopB9: BD 00 B9 LDA $B900,X Load a byte from page $B9 F0 06 BEQ nextB9 If $00, nothing to do, skip to next 6A ROR else shift once to the right 29 3F AND #$3F then set the two left bytes to 0 ($3F=00111111) 9D 00 B9 STA B900,X and replace the value in RAM nextB9: CA DEX Next byte D0 F2 BNE loopB9 As long as X is not zeroed again, loop
loopBA: BD 00 BA LDA $BA00,X X already at 0 here. Load a byte from page $BA F0 06 BEQ nextBA If $00, nothing to do, skip to next 6A ROR else shift once to the right 29 3F AND #$3F then set the two left bytes to 0 ($3F=00111111) 9D 00 BA STA BA00,X and replace the value in RAM nextBA: CA DEX Next byte D0 F2 BNE loopBA As long as X is not zeroed again, loop
exit: 60 RTS
(merci à ISS qui a relu mon code et supprimé deux octets inutiles !)
J’ai redécouvert après coup que Mike Brown donnait déjà exactement cette solution, dans une discussion que nous avions eue en 2019 alors que je m’étonnais de la différence d’aspect du mode LORES 1 entre l’Oric-1 et l’Atmos. Cf. https://forum.defence-force.org/viewtopic.php?t=1981 Vous trouverez ci-joint le fichier TAP de LoresFix 1.0, implémenté au bas de la page 1 et qui se lance automatiquement.
In English: The goal of Lores Fix is to correct the alternate LORES characters definition, which is wrong on ROM 1.0. What’s wrong? Well, ROM 1.0 sets those chars on a 8×8 pixels matrix, while Orics actually only display 6×8 pixels on screen. So the chars are not correctly centered. This was corrected in ROM 1.1. So, Lores Fix simply shifts in RAM the default LORES characters by 1 bit to the right, having them centered again. You can run it as much as you want, the chars won’t shift again if they are at the right value 😉
Mise à jour 05/09/2024 : Grâce aux remarques et idées d’ISS et Sodiumlightbaby sur Defence-Force, nous sommes arrivés à une version bien plus compacte du code, que voici (seulement 16 octets !) :
AE 18 B9 LDX $B918 Test if we have a ROM 1.0: value FF in $B918 (3F on ROM 1.1, 7F once shifted on ROM 1.0) E8 INX increment by 1 to get 00 if we had FF, thus get ready to change a whole page D0 09 BNE exit if result was different from 00, it's not a ROM 1.0 or it was already fixed, so exit!
loop: 5E 00 B9 LSR $B900,X shift bytes from page $B9 5E 00 BA LSR $BA00,X shift bytes from page $BA CA DEX Next byte D0 F7 BNE loop As long as X is not zeroed again, loop
exit: 60 RTS
Cependant, je me suis rendu compte que lancer ce code sur Oric-1 provoque de gros problèmes quand on essaie de rentrer un programme Basic ensuite. Diantre, que se passe-t-il ? Est-ce que cela pourrait avoir un lien avec le HIMEM qui n’est pas placé au boot de l’Oric-1 ? Qu’est-ce qui pourrait donc gêner le système, de voir modifiées les octets de B900 à BAFF ? En réalité, deux choses se cumulaient: – sur ROM 1.0, le chargement d’un bloc mémoire plante le pointeur “fin de basic” en page 0, octets 9C-9D. Ce pointeur de fin prend la valeur de la fin du bloc mémoire ! – d’autre part, j’avais stocké la routine en $100 (pile), ce qui semble être une mauvaise idée quand on reste sur l’interpréteur et qu’on joue avec le basic: la routine est écrasée. BFE0-BFFF semble plus indiqué !
Le mieux pour une utilisation sur Oric-1 dans un programme Basic, semble donc être une implémentation à l’intérieur du Basic, par exemple (en appelant la routine par CALL#BFE0):
La conversion d’images au format HIRES remonte au tout début de l’Oric. Les premières techniques utilisées étaient très artisanales, pas du tout automatisées et cantonnées aux images noir et blanc. Les niveaux de gris étaient obtenus par mélange de pixels noirs et blanc. Malgré tout de belles images ont fait l’admiration de tout un chacun. Peu à peu, des programmes plus performants sont apparus.
Plusieurs techniques ont été utilisées :
1) En mode TEXT, l’animation est basée soit sur l’affichage d’un ou plusieurs caractères pré-redéfinis, soit sur l’affichage fixe d’un ou plusieurs caractères, mais dont la redéfinition est modifiée ” au vol “. Dans le cas d’un seul caractère, l’animation est très rapide (voir par exemple Metromov de Simon G., CEO-mag n°132, 133 et 134). Evidemment, la vitesse diminue avec le nombre de caractères et/ou de redéfinitions, même lorsqu’on programme en langage machine.
2) En mode HIRES, l’animation est basée, sur l’affichage d’une série d’images (portions d’écran ou écrans entiers). La première difficulté est de disposer d’une série d’images. Sauf si vous êtes un artiste, le plus simple est de partir d’images existantes, de les réduire au format 240×200 pixels puis de convertir ces images au format HIRES. Par exemple, Dominique P. (voir les CEO-mags n° 178, 179, 181 et 182) a utilisé des Gif animés qu’il a convertis à l’aide de PictConv de Mickaël P. Toutefois la RAM de l’Oric ne peut contenir que quelques images, même si ce ne sont que des portions d’écran et même si on les compresse/décompresse. Pour gérer un nombre un peu plus élevé d’images, on est donc amené à charger des fichiers à partir d’une disquette et ceci est forcément lent. Quoi qu’on fasse, la durée totale de l’animation est donc inévitablement limitée.
3) Toujours en mode HIRES, quelques programmeurs de génie ont réalisé des miracles à base de scrolling et de sprites. Si ce n’est déjà fait, admirez par exemple le fameux ” Doggy ” d’Eric Chahi & Rémi Grouzelle édité par Loriciels. Il serait intéressant d’en faire le ” reverse engineering “, si le cœur vous en dit…
B) L’origine de mes images
Dans les années 80, j’ai emprunté à ma nièce un petit carnet d’une douzaine de pages, intitulé “Lola rennt” (Lola court). C’était un truc pour les gosses, sans nom d’auteur, ni copyright. En faisant défiler les pages, on pouvait voir courir la joggeuse Lola. J’avais photographié les images de ce petit fascicule, dans l’idée de faire courir Lola sur mon Oric.
Les années ont passé, le répertoire “Lola rennt” a survécu à tous les plantages de mes ordinateurs successifs mais j’ai enfin pu réaliser ce projet vieux de 40 ans. Hélas j’ai mis plus de temps que prévu pour finaliser ce projet et j’ai loupé l’anniversaire des 40 ans de l’Oric-1. Pas grave, ce sera pour les 40 ans de l’Atmos.
Mes ambitions étant très modestes et ayant eu la paresse de développer une nouvelle technique, je me suis placé dans la lignée des animations produites par Simon G. dans les années 90. C’était aussi l’occasion de rendre hommage à Simon car son procédé est remarquablement efficace, en dépit de sa simplicité.
C’était aussi l’occasion de voir ce qu’il est possible de faire avec PictConv de Mickaël P. et Img2oric de Sam Hocevar. Le programme résultant, “Cours Lola, cours…” n’est donc pas novateur, mais purement sentimental.
C) Le travail effectué
La phase préliminaire a consisté, comme de bien entendu, à numériser mes photos argentiques, à les recadrer correctement, à les réduire au format 240×200 pixels et à les sauver au format BMP. Rien de bien compliqué.
J’ai ensuite mouliné ces images avec PictConv en testant les différents paramètres disponibles.
Ce sont les combinaisons -f0 (sortie monochrome), -o1 (output tape format sans loader) et -d0 (sans tramage) ou -d1 (tramage alternatif) qui ont donné les meilleurs résultats, compte tenu des caractéristiques de mes images. Le paramètre -f6 (couleur, méthode de Sam Hocevar) a donné des résultats très intéressants. Mais pour rendre hommage à Sam, j’ai préféré utiliser directement son programme Img2oric.
D) Les résultats
Trois disquettes sont issues de ce travail :
Lola-P0.dsk (exploitant PictConv avec les paramètres -f0 -o1 et -d0)
Lola-P1.dsk (exploitant PictConv avec les paramètres -f0 -o1 et -d1)
Lola-SH.dsk (exploitant Img2oric de Sam Hocevar)
Elles sont jointes à cet article et si cela vous tente, vous pourrez regarder Lola courir (chaque animation dure environ 20 s). Soyez indulgents, c’est de l’animation sur Oric…
Les disquettes de Lola sont utilisables sur Oric-1 et sur Atmos physiques, ainsi qu’avec Euphoric ou Oricutron. Notez, comme Simon l’avait signalé, qu’à partir d’un disque dur (c’est-à-dire avec un émulateur) l’animation est plus rapide (environ 2 fois) qu’à partir un lecteur de disquette (Oric réel). De plus avec un émulateur, il est possible d’augmenter un peu la fréquence. Mais l’animation devient illisible au-delà de 4 Mhz.
Enfin, la conversion des BMP a engendré quelques petits défauts, notamment des “effets de bord” (la conversion est imparfaite à proximité du bord de l’image). J’ai donc été amené à développer EDIHRS (pour EDIteur d’écrans HiReS), un programme qui permet d’effectuer de petites corrections. Attention, ce n’est pas Photoshop ou Gimp : Les possibilités sont très limitées. Ce programme fera prochainement l’objet d’un autre article.
PS. Le thriller “Cours, Lola, cours” réalisé par Tom Tykwer en 1998 est très postérieur au fascicule “Lola run” que j’ai utilisé. Je ne sais pas si ces deux Lola ont la même origine. Si vous avez des infos, faites m’en profiter.
Utilitaire Sedoric pour récupérer des fichiers après un DEL
Catastrophe : Tout votre travail est perdu à cause d’un DEL malencontreux ! Et vous étiez tellement dans l’action que, bien sûr, vous n’avez pas sauvegardé depuis un bon moment. Le piège principal (mais pas que) est dû à la commande DEL”*.*” pour laquelle il faut confirmer par Y ou N si chacun des fichiers est à supprimer ou pas. Une erreur est vite arrivée…
Pas de panique rien n’est perdu, mais de grâce n’écrivez plus rien sur cette disquette ! Et si possible, protégez-là en écriture, faites-en une copie et opérez sur la copie.
Petit historique
L’envie de faire cet utilitaire m’est venue en 1995, en écrivant l’annexe n° 9 : “Que se passe-t-il lors d’un DEL ?”, à la page 511 de “Sedoric 3.0 à nu”. Et depuis lors, ce projet n’a pas bougé de ma liste “Tout doux” ! Au fil du temps, quelques Oriciens se sont adressés à moi pour récupérer leur travail effacé par erreur, ce qui a renforcé ma motivation. Mais c’est le corona qui m’a fait passer à l’acte…
Quelques précisions
Le programme UNDEL est écrit en Basic 1.1 et utilise plusieurs instructions Sedoric sans équivalent dans les autres DOS. Par conséquent, il ne tournera que sur un système équipé d’une Rom 1.1 et sous Sedoric. Il s’agit typiquement d’une configuration Atmos + Microdisc + Sedoric. UNDEL fonctionne avec tout système émulant cette configuration (Euphoric et Oricutron testés). Il est inutile de l’essayer avec un Oric-1 ou avec un Telestrat sous Hyper-Basic. Les instructions Sedoric PMAP, SMAP, CRESEC, FRESEC, etc. sont incontournables et si vous voulez vous en passer, il faut réécrire leur équivalent en code machine.
Base technique du problème
Que se passe-t-il lorsqu’on écrit un fichier avec SAVE*, ESAVE ou COPY* ? :
Dans l’ordre : Un descripteur est créé, un ou plusieurs secteurs du fichier proprement dit sont enregistrés à la suite, les 2 secteurs de bitmap sont ajustés (plusieurs secteurs sont marqués occupés, le nombre de fichiers présents sur la disquette est incrémenté, le nombre de secteurs libres est réduit) enfin une entrée est ajoutée au directory et l’offset de la prochaine entrée libre est ajusté. Il est à noter que le descripteur est toujours écrit sur le 1e secteur libre à partir du début de la bitmap. Le ou les secteurs du programme proprement dit sont écrits, dans l’ordre, sur les secteurs libres suivants, qui ne sont pas forcément contigus lorsque la disquette a déjà subi plusieurs écritures / suppressions.
Que se passe-t-il si on supprime un fichier avec DEL, DELBAK ou DESTROY ? :
Lorsqu’il efface un fichier, SEDORIC ne modifie en fait que les secteurs de bitmap et de directory.
L’entrée du directory est remplacée par des #00 et l’offset de la prochaine entrée libre est réajusté. Les 2 secteurs de bitmap sont actualisés (plusieurs secteurs sont libérés, le nombre de fichiers présents sur la disquette est réduit, le nombre de secteurs libres est augmenté). MAIS ni le secteur de descripteur, ni le ou les secteurs du fichier proprement dit ne sont modifiés.
Ils restent intacts et sont seulement marqués “libres” dans la bitmap. Il n’y a donc aucun problème tant qu’un nouveau fichier n’est pas écrit dans ces secteurs libérés (et ce sera malheureusement en priorité sur ceux-là). Comme vous pouvez l’imaginer, il est techniquement possible de récupérer le fichier supprimé en restaurant l’entrée de directory, les secteurs de bitmap, quelques liens, etc.
Et lorsque plusieurs fichiers ont été supprimés ? :
Pas de problème tant qu’aucune écriture n’est opérée sur la disquette. Il faut relancer UNDEL plusieurs fois, jusqu’à ce qu’il ne trouve plus rien. Pour mes tests, j’ai effacé une disquette 80 pistes de 17 secteurs, double face qui était bourrée de fichiers de toutes sortes avec un DEL”*.*” et j’ai pu tout récupérer avec UNDEL !
Et si malheureusement une écriture a été faite ?
Là, il est plus hasardeux de restaurer spécifiquement le fichier qui vous intéresse. Mais ce n’est pas forcément perdu si celui-ci est mappé assez loin dans la bitmap. La localisation des fichiers dans la bitmap n’a rien à voir avec l’ordre des suppressions. En outre, après plusieurs écritures / suppressions, les fichiers sont fragmentés et la disquette est truffée de résidus. Ceci implique un algorithme de restauration assez complexe. Mais le miracle est possible !
Le programme UNDEL pour Sedoric
Sedoric a subi quelques modifications au fil du temps (par exemple ajout d’un 2e secteur de bitmap pour passer aux disquettes 3.5″, ajout d’un système de sous-directory, etc.). Dans un premier temps, je me suis concentré sur la version 3.0 de Sedoric, parce que c’est celle que je connais le mieux pour l’avoir dépiautée en détail. Mais quelques vérifications à postériori montrent que UNDEL marche avec les disquettes de toutes les versions de Sedoric. Il est même possible de récupérer des fichiers (simples ou mergés) de disquettes Stratsed car la structure de celles-ci est très proche de celle des disquettes Sedoric.
Structure d’un fichier Sedoric
Du plus simple, qui est un fichier “ordinaire” occupant moins de 123 secteurs, au plus compliqué, formés de plusieurs fichiers mergés, il est possible de dresser le schéma général suivant :
Un fichier “ordinaire” est composé comme suit :
-Le descripteur principal (obligatoire) du fichier, qui liste le ou les secteurs qu’il faut charger pour mettre le fichier en place dans la Ram. Si nécessaire, un lien vers un éventuel descripteur secondaire est renseigné.
-Le ou les secteurs du fichier proprement dit, listés dans ce descripteur principal.
-Un descripteur secondaire, s’il reste des secteurs à lister dont les coordonnées n’ont pas pu être insérées dans le ou les descripteurs précédents, faute de place.
-Après ce descripteur secondaire, se trouvent les secteurs listés dans ce descripteur.
-Si cela ne suffit pas, un autre descripteur secondaire est ajouté, etc.
-Chaque descripteur est relié au suivant par un lien. Le lien du dernier descripteur du fichier est mis à zéro pour indiquer qu’il n’y a plus rien après.
-Chacun de tous ces éléments (descripteurs et secteurs du fichier proprement dit) est écrit sur le prochain secteur libre. Après plusieurs écritures / suppressions, la disquette est parsemée de “trous” (secteurs libres isolés). Mais les divers morceaux d’un fichier sont toujours écrits dans le bon ordre, même s’ils ne sont pas forcément contigus. -Les informations propres à un fichier sont données dans l’entête de son descripteur principal. Ce sont : Le type de fichier, les adresses de début, de fin et d’exécution, le nombre total de secteurs à charger pour mettre l’ensemble de ce fichier en place. Cet entête est suivi par la liste (ou le début de la liste) des secteurs à charger. Les descripteurs secondaires ne comportent que le lien vers le descripteur suivant et la suite de la liste des secteurs à charger.
Les fichiers “mergés” sont formés comme suit :
Plusieurs fichiers “ordinaires” peuvent être rassemblés sous un même nom, on dit alors qu’ils sont “mergés”, ce qui est impropre car “merged” signifie “fusionnés”. Or les fichiers restent intacts et sont seulement juxtaposés. Ils sont mis à la queue-leu-leu, sans être modifiés, sauf les liens entre les différents descripteurs qui sont chaînés : Le dernier lien de chaque fichier “ordinaire” (normalement mis à zéro) est remplacé par l’adresse du descripteur principal du fichier mergé suivant. Et ainsi de suite, jusqu’au dernier descripteur dont le lien est bien sûr maintenu à zéro. Aucune autre modification n’est effectuée. La taille globale de l’ensemble ne figure qu’au niveau de l’entrée de directory correspondant à cet ensemble de fichiers mergés. Seul le nom du premier fichier est retenu et figure dans cette entrée. Les secteurs de ces différents fichiers, sont écrits à la queue-le-leu et dans le bon ordre, mais ne sont pas forcément contigus.
Et un peu plus de détails sur ce qui se passe lors d’un DEL
L’information cruciale est qu’après un DEL, le ou les “blocs” (descripteur + secteurs à charger) restent en place sans la moindre modification. Seuls la bitmap et le directory sont affectés : Toute trace de l’existence du ou des fichiers est complétement effacée. De plus, l’ordre des entrées est remanié pour récupérer de la place, mais pas toujours complètement remanié, car il reste des trous. Je n’entre pas dans l’explication de ce phénomène, sans intérêt pour le propos d’aujourd’hui.
Alors quel est le bilan de la situation ?
1) Dans la bitmap, tous les secteurs correspondant au fichier supprimé (descripteurs et secteurs) ont été marqués libres (réutilisables), bien que les secteurs en question soient toujours en place. Il faut noter que les fichiers effacés ne sont pas récupérables dans l’ordre de leur effacement, mais dans l’ordre de leur représentation dans la bitmap. La prochaine écriture sur la disquette va écraser en priorité les secteurs libérés qui figurent à partir du début de la bitmap et ce ne sont pas forcément ceux libérés par le dernier DEL. Donc, avec un peu de chance, il est PEUT-ETRE encore possible de récupérer le fichier qui vous intéresse, même si une écriture a eu lieu après le DEL. Dans la bitmap encore, le nombre de secteurs libres est bien sûr augmenté du nombre de secteurs libérés, tandis que le nombre de fichiers est décrémenté. Le nombre de secteurs de directory peut éventuellement avoir été réduit. Heureusement, toutes ces informations sont récupérables.
2) Dans le directory, l’entrée correspondant au fichier supprimé a tout simplement été effacée, créant ainsi une entrée libre. Comme déjà indiqué, les entrées restantes ont éventuellement et partiellement été réorganisées pour gagner de la place. Une entrée supprimée, cela veut dire que les informations suivantes ont disparu :
-Le nom et l’extension du fichier.
-Les coordonnées piste et secteur du descripteur principal du fichier.
-Le nombre total de secteurs occupés par le fichier (ou les fichiers s’il s’agit de fichiers mergés). -L’attribut de protection du fichier.
Stratégie utilisée par UNDEL
Phase 1 : Retrouver le premier descripteur du fichier
Coup de chance, le premier secteur libre de la disquette est forcément un descripteur principal. Si ce n’est pas le cas, soit aucun DEL n’a été effectué, soit une écriture est intervenue après le dernier DEL. On a ça par exemple lorsqu’un fichier est écrit et ne surcharge que partiellement un fichier précédemment détruit et si celui-ci était plus gros. Il reste des secteurs “libres” qui ont toutes les chances de ne pas être un descripteur. UNDEL sait gérer cette situation de manière appropriée. A l’issue de cette phase, ce premier descripteur est restauré, ainsi que les secteurs qui y sont listés. Mais le descripteur principal trouvé est-il bien celui du fichier que nous voudrions récupérer ? Si plusieurs DEL ont été effectués et que le descripteur qui nous importe ne correspond pas au premier secteur libre, il faudra recommencer l’opération de sauvetage plusieurs fois, jusqu’à ce que le bon soit trouvé et restauré.
Phase 2 : Examiner le lien vers le descripteur suivant
Si ce lien est nul, il n’y a aucun descripteur suivant, notamment pas de descripteur de fichier mergé. Il ne reste plus qu’à finaliser l’entrée de directory et la bitmap (voir plus bas “Phase 4”). Au contraire, si ce lien n’est pas nul, il indique la localisation piste/secteur du descripteur suivant, qui peut être soit un descripteur secondaire du même fichier, soit le descripteur principal d’un fichier mergé. Comment départager ces 2 hypothèses ?
Phase 3 : Examiner s’il reste des secteurs à charger pour le fichier en cours
Le descripteur principal nous a indiqué le nombre total de secteur à charger pour mettre en place le fichier en cours. Sachant qu’un descripteur principal peut lister les coordonnées de 122 secteurs et un descripteur secondaire celle de 127 secteurs, il est facile de calculer s’il reste des secteurs qui ne sont pas encore listés. Si c’est le cas, le descripteur trouvé est un descripteur secondaire. Sinon le descripteur trouvé est le descripteur principal d’un fichier mergé. En résumé, il n’y a que 3 possibilités : Soit c’est fini, soit il y a encore un descripteur secondaire, soit il y encore un descripteur principal de fichier mergé. Le programme rebouclera au niveau voulu selon le cas. Le descripteur trouvé est restauré, ainsi que les secteurs qui y sont listés. Après plusieurs éventuelles réitérations et quelle que soit sa complexité, le fichier proprement dit est entièrement restauré. Il ne reste plus qu’à finaliser l’entrée de directory et la bitmap.
Phase 4 : Créer une entrée de directory pour ce fichier
Lorsque le dernier descripteur du fichier ainsi que les secteurs correspondants ont été restaurés, il faut créer une entrée dans le directory. Partant du 1er secteur de directory (le secteur 4 de la piste 20) on recherche la première entrée libre. S’il n’y en a pas, on passe au secteur de directory suivant, etc. Si on atteint le dernier secteur de directory sans avoir trouvé d’entrée libre, il faudra créer un nouveau secteur de Directory dont la première entrée sera l’entrée libre voulue. On écrit alors dans l’entrée libre les informations suivantes :
-Le nom et l’extension du fichier. Par défaut ce sera SANSNOM.COM, ce qui impliquera de renommer le fichier avant de relancer UNDEL pour en restaurer un autre.
-Les coordonnées piste et secteur du descripteur principal du fichier. Ces données ont été trouvées lors de la phase 1.
-Le nombre total de secteurs occupés par le fichier. C’est la somme du nombre de secteurs à charger pour mettre en place le fichier (simple ou mergé) et du nombre total de descripteurs.
-L’attribut de protection du fichier. Par défaut, il sera positionné sur PROT (qui ne gêne pas si on veut renommer le fichier !). Finalement l’adresse de la prochaine entrée libre est mise à jour (ou à zéro si on vient d’écrire sur la dernière entrée libre du secteur de directory).
Phase 5 : Finaliser la bitmap
La bitmap proprement dite (représentation des secteurs en fonction de leur occupation / disponibilité) a été mise à jour au fur et à mesure de l’avancée des phases précédentes. Reste à finaliser l’entête ou plutôt les deux entêtes, car la bitmap occupe deux secteurs. Les données à mettre à jour se réduisent à :
-Le nombre de fichiers (ancienne valeur plus un)
-Le nombre de secteurs de directory (peut éventuellement avoir été augmenté). Le nombre de secteurs libres a été mis à jour au fur et à mesure des phases précédentes et il n’y a pas à s’en occuper.
Phase 6 : Renommer le fichier restauré
La récupération du fichier est terminée. L’affichage des caractéristiques de ce fichier (type de fichier, adresses de début, de fin, d’exécution et nombre de secteurs occupés) vous permettra de comprendre de quel fichier il s’agit et de le renommer correctement. S’il ne s’agit pas du fichier que vous vouliez ou si vous en avez plusieurs à récupérer, il suffit de relancer UNDEL (après avoir renommé SANSNOM.COM).
Et si une écriture a eu lieu après le ou les DEL ?
Je pensais au départ que l’absence d’écriture après la suppression était un impératif absolu. Mais comme je l’ai déjà indiqué, les fichiers effacés ne sont pas récupérable dans l’ordre de leur effacement, mais dans l’ordre de leur représentation dans la bitmap. D’autre part, les écritures se font à partir du début de la bitmap. Il est donc possible de récupérer un fichier effacé, s’il n’est pas en tête de bitmap. Après la suppression de plusieurs fichiers, il est possible qu’il existe encore plusieurs fichiers récupérables, même s’il y a eu écrasement de l’un d’entre eux après une écriture malheureuse ! Après avoir reçu un avertissement d’échec, vous avez la possibilité de demander à UNDEL de rechercher s’il n’existe pas encore quelque chose à restaurer sur la disquette. Les nombreux essais, que j’ai effectués, montrent que ça marche assez bien.
Conclusion
Que ce soit avec un Atmos réel ou avec un émulateur (Euphoric et Oricutron ont été testés), vous pouvez sans crainte récupérer tous les fichiers effacés par erreur. Et même après une écriture, il reste une chance que tout ne soit pas perdu. Le programme UNDEL est solide et je suis sûr qu’il vous donnera entière satisfaction. Bien que je n’aie jamais rencontré de problème au cours de mes très nombreux essais avec Sedoric 3.0, je vous conseille quand même de protéger votre disquette originale et de travailler sur une copie, on ne sait jamais ! Le zip qui accompagne cet article contient non seulement les fichiers Undel.dsk et Undel.tap, mais aussi des fichiers .txt très commentés, au cas où vous voudriez retoucher le programme…
