CPC Rulez :: Consulter le sujet - Déterminer l'emplacement d'un fichier sur disquette

Je voudrais savoir svp: d'où vient le nombre hexa &14 ??

L'octet représente le nombre d'enregistrements (de paquets de 128 octets) contenus par cette entrée.

en pratique cela n'a strictement aucune espèce d'importance.

En fait, pour reprendre ton exemple, que la valeur de ton octet &0F soit 1,2,3 ou 4 au niveau du système et de ce qu'il va en faire, cela revient au même.

J'ai commencer à chiffrer des fichiers avec mots de passe, déjà je galère: penser à chiffrer aussi les .bak, effacer le buffer contenu dans le header et qui contient aussi de infos en clair du fichier... faut vraiment penser à tout! ^^

Je veux dire, un utilitaire qui permet de cartographier un disque, écrire des fragments de pistes vides et en récupérer des données effacées n'a nullement besoin de cela ?

Amstrad 100% n°17: "Si cet octet (&F) vaut &80, cela signifie que le descripteur de fichier n'est pas complet et qu'il faudra aller trouver l' entrée suivante du fichier pour récupérer la suite du programme."

Auteur :	sPOKE [ 13 Mars 2012, 18:15 ]
Sujet du message :	Déterminer l'emplacement d'un fichier sur disquette
Salut à tous, J'essaie de déterminer d'après les entrées de 32 octets que j'ai pour chaque fichier dans le catalogue piste 0, l'endroit où se trouvent mes fichiers. J'ai bien lu le tutoriel de Quasar http://quasar.cpcscene.com/doku.php?id=dossier:cat Tous les calculs sont justes dans son tuto, pas de soucis de compréhension. Sur ma disquette à moi, le fichier TOTO.BAS (entrée du catalogue, 2 lignes de 16 octets donc) - &14 comme valeur dans l'octet &0F - &05, &06, &07 comme valeurs pour les 3 premiers octets du début de la seconde ligne (17e,18e,19e de l'entrée donc) le fichier "toto.bas" se trouve en Piste 1, Secteur &C2 jusqu'à &C6 Il tient selon moi sur 3 blocs : C2-C3 , C4-C5, C6 La formule de Quasar : 3 * 8 = 24 = &18. Mais moi j'ai &14... et 20 n'est pas un multiple de 8 !! en faisant INT (((19)+1)/2) je trouve &05 c'est bon // (piste 1 9)+ 1 (car secteur C2=1) INT (((19)+3)/2) je trouve &06 c'est bon. INT (((19)+5)/2) je trouve &07 c'est bon. Je voudrais savoir svp: d'où vient le nombre hexa &14 ?? en plus, certain autres petits fichiers ont &02 ou &03 comme valeur dans l'octet &0F de leur entrée catalogue. J'ai donc un doute sur la formule de Quasar...

Auteur :	hERMOL [ 13 Mars 2012, 18:49 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
sPOKE a écrit : Je voudrais savoir svp: d'où vient le nombre hexa &14 ?? L'octet représente le nombre d'enregistrements (de paquets de 128 octets) contenus par cette entrée. On se demande pourquoi, mais ce n'est pas la peine, c'est comme ça ( Lalalalala ! je ne veux pas t'abandonner, mon MM...). Si cet octet vaut &80, cela signifie que le descripteur de fichier n'est pas complet et qu'il faudra aller trouver l' entrée suivante du fichier pour récupérer la suite du programme. C' est pas simple. url/src: https://cpcrulez.fr/coding_asm17b-catalogue-amsdos.htm https://www.google.fr/search?q=catalogu ... =Recherche

Auteur :	sPOKE [ 13 Mars 2012, 19:26 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
hERMOL a écrit : L'octet représente le nombre d'enregistrements (de paquets de 128 octets) contenus par cette entrée. [Edit de Spoke:]Bien vu, je corrige mes calculs, merci hERMOL.

Auteur :	hERMOL [ 13 Mars 2012, 19:48 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
chaque secteur fais &200 octets, t'as 5 secteurs , ca fais bien &14 (&200*5)/128=&14

Auteur :	sPOKE [ 13 Mars 2012, 22:46 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
Merci hERMOL! Tout fonctionne à présent. La lecture du livre du lecteur de disquettes me l'a confirmé. Tout d'abord, je tiens à préciser que l'article de Quasar est inexact. Ils ne donnent pas la bonne formule pour comprendre la valeur de l'octet &F de l'entrée du catalogue. Mutiplier le nombre de blocs par 8 ne marche pas toujours, loin de là... Car moi aussi mon fichier tient sur 3 blocs, mais n'indiquait que &14 et non pas &18 comme dans leur exemple. De plus, certains petits fichiers qui tiennent sur 1 seul bloc indiquent &02, d'autres &03... bref c'était pas clair du tout. 1 bloc = 2 secteurs, soit : 1024 octets. 1 secteur = 512 octets. 1 enregistrement = 128 octets. Pourquoi calculer par tranche de 128 octets ? Pour des raisons de compatibilité car quand le premier système CP/M a été crée, les secteurs faisaient 128 octets sur les disquettes 8 pouces. Et non pas 512 comme sur le CPC. Le chiffre indiqué dans l'octet &0F de l'entrée catalogue de chaque fichier indique le nombre d'enregistrements de 128 octets utilisés par le fichiers sur les blocs qu'il occupe. Soit le nombre de 1/4 de secteurs remplis par le fichier. J'ai vérifié avec l'éditeur de secteur, ça tombe juste à chaque fois. Par exemple j'ai 2 fichiers qui tiennent chacun sur 1 seul secteur. Logés dans 1 seul bloc donc. Mais au catalogue, l'un affiche &02, l'autre &03 dans l'octet &0F... En regardant avec l'éditeur de secteurs, mon premier fichier utilise uniquement la première page de 256 octets, soit 2 enregistrements.Le second utilise la première moitié de la seconde page de 256 octets. Donc 3 enregistrements de 128 octets sont utilisés. (Attention, seul les &E5 sont considérés comme espace vide. Les &00 sont considérés comme espace occupé par le fichier.) Pourquoi l'article de Quasar est tombé juste en multipliant 8 par le nombre de blocs ? tout simplement parceque par chance, leur 3 blocs étaient pleins. Ils devraient peut être corriger leur article en expliquant précisément comment l'octet &F se calcule.

CPC Rulez https://cpcrulez.fr/forum/

Déterminer l'emplacement d'un fichier sur disquette https://cpcrulez.fr/forum/viewtopic.php?f=4&t=4810	Page 1 sur 6

Auteur :	Megachur [ 14 Mars 2012, 07:13 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
je crois que sur Quasar.net tu peux leur signaler un erreur sur les articles (y'a un bouton quelque part ou un contact mail) !

Auteur :	sPOKE [ 14 Mars 2012, 08:35 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
Je veux bien leur signaler. Je viens de m'inscrire sur leur site pour ce faire. Quand je relève ce que je pense être une erreur, je l'explique. Ce n'est pas une critique du génial Quasar bien au contraire. C'est plutôt l'attitude scientifique de dire : "Hey les gars! j'ai trouvé un truc faux ici! corrigeons ça." J'ai vraiment un esprit positif je pense. Il ne s'agit pas de montrer "moi je sais mieux que vous" (Je le précise car mon article peut le laisser penser je trouve...) D'ailleurs, si quelqu'un trouve une inexactitude dans un des trucs que j'écris sur le CPC, qu'il n'hésite pas à le signaler, j'en serai ravi.

Auteur :	shap [ 14 Mars 2012, 11:41 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
Petit problème d'arrondi chez Quasar Cela dit, histoire de mettre mon grain de sel, en pratique cela n'a strictement aucune espèce d'importance. En fait, pour reprendre ton exemple, que la valeur de ton octet &0F soit 1,2,3 ou 4 au niveau du système et de ce qu'il va en faire, cela revient au même (enfin pas tout à fait mais presque). Il suffit pour cela d'observer ce qui se passe à plus bas niveau. La quantité minimum de données que peut te renvoyer le FDC en loading est la taille d'un secteur (128 octets donc). Cependant le système utilise des formats avec des secteurs taille 2 cette taille minimum sous AMSDOS est donc de 512 octets mais vu que l'AMSDOS ne connait pas la notion de secteur, et bien il les charge par deux soit 1024 octets (un bloc). ce qui signifie que dans tous les cas, il va monter deux secteurs complets (même si ton fichier réel n'utilise qu'un enregistrement). Mais bon, il y a une deuxième couche un peu plus subtile pour éviter d'écraser des datas en RAM pour rien. En effet, dans 99% des cas, l'AMSDOS charge donc plus de données que nécessaire, c'est pour cette raison qu'il les entrepose dans un buffer (il fait ça par tranches bien entendu, il ne va pas monter un buffer de 32k ). Ensuite, le but est de déterminer la quantité de données un peu plus précisément. C'est donc là qu'il va chercher ton fameux octets pour déterminer ou s'arrêter de copier les données en RAM à l'adresse demandée (il ne le fait que pour la dernière entrée dans le cas où il y en aurait plusieurs bien sur). Donc si ton octet est un poil supérieur à ce qu'il devrait être, le seul résultat est qu'il risque d'y avoir un petit débordement si tu charges des fichiers "cul à cul" en descendant dans la RAM le fichier situé au dessus en RAM risque de voir ses 128 premiers octets écrasés.

Auteur :	sPOKE [ 14 Mars 2012, 13:00 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
shap a écrit : en pratique cela n'a strictement aucune espèce d'importance. C'est important pour moi car je suis en train de coder un utilitaire pour recréer les catalogues effacés, comme Dir Doktor, mais d'une manière différente. Je dois donc être précis. L'octet &F est très important dans ce cas. shap a écrit : En fait, pour reprendre ton exemple, que la valeur de ton octet &0F soit 1,2,3 ou 4 au niveau du système et de ce qu'il va en faire, cela revient au même. Ben non, ça revient pas au même car je dessine une carte géographique de la disquette, qui me permet de voir les secteurs utilisés et leur tranches libres de 128 k en les affichant d'une couleur différente. Je sais ainsi où est-ce que je peux grapiller de la place pour stocker des données en enregistrant directement sur piste. C'est pour ça que j'avais besoin de comprendre pourquoi sur 3 blocs, j'obtenais &14 et non pas &18 qui est la valeur maximum. Tiens tiens! de l'espace libre! Je compte utiliser tout cet espace. Pas de gaspillage.

Auteur :	shap [ 14 Mars 2012, 13:25 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
Effectivement dans ce cas, la précision est de rigueur. Par contre, du coup, vu l'utilitaire que tu fais, il serait intéressant de gérer les formats Parados que beaucoup de monde utilise (enfin depuis la mode des émulateurs, un peu moins du coup ). Car certains formats Parados collent dix secteurs par piste, donc il faut prévoir que le nombre de secteur/piste soit variable dans tes routines de calcul. De plus le nom des secteurs changent à chaque format (valable également pour les formats Vendor et Ibm, d'ailleurs, le format Ibm ne formate que huit secteurs par piste). Et il te faudra donc une routine de détection de format assez performante, j'en avait fait une il y a un bout de temps car l'AMSDOS ne connaissant que trois formats, il se base sur le nom des secteurs pour déterminer le format, ce n'est pas suffisant, loin s'en faut. D'ailleurs, j'avais fait ça dans le cadre d'un loader de fichier entièrement hard (qui n'utilise en aucun cas le système), si ça peut t'aider, je pourrais toujours te filer les sources.

Auteur :	sPOKE [ 14 Mars 2012, 13:44 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
C'est ça que j'aime avec le CPC, il y a toujourd énormément de trucs à comprendre et tout reste à faire pour la partie utilitaires. On a plein de formats différents, c'est vraiment intéressant. Je connais pas Parados, mais je mets ça sur ma liste. En plus, autant ce sera "facile" de récupérer les fichiers binaires Basic et langage machine (un peu moins ceux qui sont dispersés) car ils ont des en-têtes, mais les fichiers ASCII et CP/M qui n'ont pas de header ni de fin de fichier, je vais m'amuser... Les &E5 sont mes amis tu me diras. C'est là qu'il va falloir trouver des ruses de sioux. J'ai commencer à chiffrer des fichiers avec mots de passe, déjà je galère: penser à chiffrer aussi les .bak, effacer le buffer contenu dans le header et qui contient aussi de infos en clair du fichier... faut vraiment penser à tout! ^^

Auteur :	TotO [ 14 Mars 2012, 14:02 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
sPOKE a écrit : J'ai commencer à chiffrer des fichiers avec mots de passe, déjà je galère: penser à chiffrer aussi les .bak, effacer le buffer contenu dans le header et qui contient aussi de infos en clair du fichier... faut vraiment penser à tout! ^^ C'est peut-être pas par la qu'il faut commencer ? Je veux dire, un utilitaire qui permet de cartographier un disque, écrire des fragments de pistes vides et en récupérer des données effacées n'a nullement besoin de cela ?

Auteur :	sPOKE [ 14 Mars 2012, 14:16 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
TotO a écrit : Je veux dire, un utilitaire qui permet de cartographier un disque, écrire des fragments de pistes vides et en récupérer des données effacées n'a nullement besoin de cela ? Tout à fait. ce sont 2 utilitaires totalement différents. J'aime bien avoir un chiffreur de fichiers & un eraseur total. (comme sur PC). Ensuite, si je réunis le tout, ça me fait un outil sympa pour gérer mes disques. Souvent, ce que j'apprends pour coder l'un me sert pour coder l'autre. Donc je m'éparpille pas tant que ça finalement. Après 25 ans, j'ai à nouveau un niveau de newbie, mais bon je suis patient...

Auteur :	sPOKE [ 15 Mars 2012, 14:01 ]
Sujet du message :	Re: Déterminer l'emplacement d'un fichier sur disquette
hERMOL a écrit : Amstrad 100% n°17: "Si cet octet (&F) vaut &80, cela signifie que le descripteur de fichier n'est pas complet et qu'il faudra aller trouver l' entrée suivante du fichier pour récupérer la suite du programme." Cette affirmation m'a intrigué car je la trouvais un tantinet exagérée. Car un si on enregistre un fichier de 16 Ko, je me suis dit qu'il tiendrait sur 16 blocs sans avoir besoin d'une entrée suppléméntaire... J'ai donc vérifié dans le livre du lecteur de disquettes de Micro-Application, page 161: "La valeur de cet octet se calcule ainsi : 16 blocs * 8 enregistrement = &80. Dès que cette valeur (&80) figure à cet endroit, AMSDOS considère automatiquement qu'une extension (autre entrée) suit." Je ne suis pas d'accord. Pour en avoir le cœur net, j'ai sauvegardé un fichier de 16 Ko, entête comprise, comme ceci: SAVE "ECRAN.BIN",B,&C000,&3F80 On obtient bien &80 dans l'octet &F, et il n'y a bien qu'une seule entrée au catalogue, comme je le pensais. Ce qui est logique. Je vais donc demander à Micro-Application de rectifier cela dans la prochaine réédition. Entre A100%, Micro-app et Quasar qui me sortent tous des approximations, vous m'en faites des misères... ^^

Auteur :	sPOKE [ 08 Avr 2012, 21:11 ]
Sujet du message :	Petite devinette... ^^
En fouillant les secteurs du lecteur de disquette, on s'aperçoit que dans le catalogue, si on mets à 1 le bit 7 (+&80) du premier octet de l'extension du nom de fichier, le fichier passe en lecture seule.(R/O). Si on fait la même chose sur le 2ème octet, le fichier devient caché (fichier système). (Ce que vous faîtes avec Disco en choisissant S,P ou SP) Quelqu'un sait-il quelle est l'utilité de faire la même chose avec le 3ème octet et comment on s'y prend ? (3ème lettre de l'extension) Ce n'est documenté nulle part, ni dans le livre du lecteur de disquette, ni dans la bible du CPC ni dans clefs pour Amstrad système disque... Même Discology semble ignorer cela. Pourtant il y a une utilité et le système l'utilise. J'ai trouvé la solution, donc je me demandais si d'autres s'étaient penché sur le sujet.

Page 1 sur 6	Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/