quand on lit le fichier (après avoir récupérer les infos des blocs dans la directory) doit-on contrôler qu'on est bien sur la première entrée, puis la deuxième, etc ?! je ne sais pas si c'est le hasard, mais j'ai jamais trouvé le cas où c'est pas classé dans l'ordre dans le catalogue d'un dsk, mais je me dis que ça peut arriver.
Pour répondre à Megachur, les différentes entrées d'un même fichier sont forcément écrites dans le catalogue séquentiellement. On peut avoir de la fragmentation au niveau du catalogue, mais une entrée avec un numéro d'index supérieur à une autre entrée est forcément derrière. Je n'ai pas tenté le coup de faire une inversion avec un éditeur de secteurs pour voir ce qui se passe. Si le concepteur de l'Amsdos a prévu ce cas (peu probable s'il est parti du principe que l'écriture des entrées est séquentielle), tu vas avoir une erreur fichier, sinon, les datas dans le fichier seront inversées. Ca pourrait faire une jolie protection, ça .
C'est le même principe pour les blocs dans un fichier, ils sont forcément organisés de façon croissante.
Pour Breiztiger, c'est lors du formatage que l'entrelacement est déterminé. Après, l'Amsdos écrit les secteurs séquentiellement, donc toujours &C1 à &C4 piste 0 pour un catalogue en format DATA par exemple.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
@markerror : je me posais la question car il y a un numéro pour indiquer l'entrée dans le catalogue (en + du &80 qui indique que le fichier a d'autres blocs) !
Peut-être faut-il chercher comment c'est codé dans l'AMSDOS (je n'ai pas le dump de la rom sur place pour vérifier moi-même tout de suite) !?
à voir peut-être de tenter l'inversion sur un dsk et voir comment l'AMSDOS réagit : cela serait aussi une façon de vérifier s'il se préoccupe de cet octet ?!?
Inscription : 15 Oct 2007, 02:49 Message(s) : 405 Localisation : Les Sucres en Morceaux
Je viens de tester sur un SCR. Si je me contente d'invreser &00 et &01, on a un syntax error à la lecture (il doit lui manquer un header).
Si j'échange simplement de place les 2 entrées d'ordre dans le CAT, aucun problème, le fichier se charge sans problème.
Je pense qu'il est toujours prudent de faire une vérification de cet octet, car la logique duCAT est que les entrées peuvent être dans le désordre. D'ailleurs, DoM se permet de changer l'ordre des 64 entrées sitôt que tu changes un caractère sur un nom de fichier. Dans son cas, c'est un ordre alphabétique, donc compatible avec ton problème. Mais rien n'empêche de mettre ces fichiers dans le désordre. Pourquoi on n'aurait pas un super CAT'art intelligent grâce à une bidouille de ce type ? On n'a pas tout inventé encore.
D'ailleurs, à bien y regarder, c'était à 2 doigts d'arriver avec l'AE05. Pour bien cacher mes bidouilles, j'avais mélangé toutes les entrées de CAT...
mais à premier vue j'ai rien trouvé de commenté à ce sujet dans le desassembly, il va falloir pister cela plus précisément pour voir le code concerné dans l'AMSDOS !
bon sinon, comme je n'ai pas bcp de temps de ce matin pour cela :
si déjà on mets autre chose que 0 sur la première entrée et la deuxième d'un fichier de +17ko, l'amsdos répond "file not found" ! si on inverse les deux entrées, cela fonctionne. donc je pense qu'il faut effectivement prendre en compte ce numéro est lire les blocks dans l'ordre !!! ce qui paraît plus logique...
maintenant je pense aussi que ce cas de figure doit être rare sur nos dsks, sauf pour certains disques volontairement trafiqués ! ex j'ai vu par hasard ce jeu qui a les entrées inversées il me semble : chercher 'TAT1' dans le dump http://www.cpc-p0wer.com/HexaDump.php?fiche=3698&slot=7&rang=0
je laisse un spécialiste conclure avec le code amsdos vérifié !
Petits tests ce matin avec un fichier image 17ko sur une disquette formatée (donc un seul fichier) :
- inversion des index des deux entrées fichiers du catalogue : boum, syntax error. Ca semble assez logique car le premier secteur lu ne contient pas de header alors que le fichier est un binaire.
- décalage des index des deux entrées (0>1, 1>2) : fichier non trouvé.
- inversion des entrées des deux fichiers dans le catalogue : le fichier se charge sans problème. Si on fait un beau F7 avec Winape et que l'on recherche les blocs 02 03 04 05, on trouve en &A980 les entrées du catalogue correspondant au fichier, triées .
- inversion de deux blocs dans une même entrée catalogue : boum, syntax error.
Bref, si on peut un peu faire mumuse avec l'ordre des entrées catalogues, le reste est bien figé. Je suppose que la possibilité de ne pas avoir les entrées dans un ordre croissants pour un fichier est un héritage CPM (si ce système permet de gérer des fichiers en mode Append).
Inscription : 20 Août 2007, 18:21 Message(s) : 5103
Megachur a écrit :
j'ai regardé rapido ce matin la source de l'amsdos http://cpcrulez.fr/coding_menu-src.htm mais à premier vue j'ai rien trouvé de commenté à ce sujet dans le desassembly, il va falloir pister cela plus précisément pour voir le code concerné dans l'AMSDOS !
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 21 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
!
.
