Interpreter les disquettes CPM et CPM/86

[gotcha]

Bonjour,

J'ai dumpé des disquettes CPM80, CPM86 et CCPM86 et je souhaiterais maintenant en extraire le contenu en développant mes propres outils.
Pour cela, j'ai besoin de comprendre comment la disquette est organisée (boot sector, file system).

J'ai regardé un peu sur le web et j'ai du mal à trouver un document très clair sur le sujet. C'était déjà assez compliqué pour DOS car il y a eu beaucoup de versions et que les informations sont finalement assez diffuses, mais ça semble encore pire sur CPM, à moins que je ne regarde pas au bon endroit.

Est-ce que quelqu'un aurait un pointeur vers un document qui explique clairement l'organisation des disquettes CPM et comment l'ordinateur boote dessus ?

[fneck]

Tu peux peut-être consulter ce livre, voir chapitre 8 :
https://archive.org/details/Mastering_CPM/mode/2up

Sinon il y a beaucoup à lire sur Internet Archive sur CP/M (OK, sur le coup je ne t'aide pas) :
https://archive.org/search?query=cpm&an ... 22texts%22

[gotcha]

Merci. Le premier livre est intéressant. Il ne semble pas tout dire, mais il donne déjà des infos sur les aspects fichiers.

Mon interprétation est pour l'instant la suivante:

• Il y a une ou plusieurs pistes réservées au système sur la disquette (la ou les premières pistes, généralement 2 pistes). Les pistes système doivent contenir le 'BIOS' CPM qui n'a pas l'air d’être en ROM : le BDOS

• Il y a une table appelée DPB (Disk Parameter Block) quelque part qui donne comme pour les DOS modernes les information utiles. Ce bloc doit être dans les pistes systèmes, mais je ne sais pas si c'est à localisation fixe

• La partie fichiers démarre après les pistes système. Les blocs d'allocation sont de 1K. Le premier 'fichier' est le répertoire qui donne la liste des fichiers (entrées de 32 octets)

Une question que je me pose encore est : est ce qu'en double face, les faces sont entrelacées, comme pour DOS ? face 0 & track 0 puis face 1 & track 0

[gotcha]

J'ai trouvé un site intéressant qui m'aide a développer un outil d'extraction de fichiers:
https://www.seasip.info/Cpm/formats.html

Pour l'instant, je ne travaille qu'avec des disquettes 8" Simple et double densité pour CPM80.

• La simple densité a des secteurs de 128 octets.

• La double densité a sa première piste en simple densité, puis des pistes MFM en 256 octets par secteur.

Globalement, l'organisation de la disquette CPM est plus rudimentaire qu'avec DOS.
Par exemple:

• Le 'root directory' et la FAT sont ensemble. Chaque entrée fichier utilise 32 octets comme en DOS, mais il contient aussi la 'FAT', ce qui laisse peu de place pour le reste. Aussi, due à la limitation de place, une entrée fichier dans le repertoire ne peut pointer que vers 16 blocs de donnée. Il faut donc plusieurs entrées pour les gros fichiers, ce qui complique les choses.

• il n'y a pas la taille exacte du fichier. Les fichier doivent donc avoir une taille multiple de 128 octets et on a donc du 'garbage' à la fin des fichiers.

• Il n'y a pas de date

Le DOS, même s'il s'est bien inspiré de CPM est je trouve plus simple pour la gestion des fichiers.

[cathodique]

Il n'y a pas de garbage à la fin des fichiers mais à la fin des secteurs car les disquettes double densité avec secteurs de 256 octets (ou plus!) continuent à être logiquement gérées par blocs de 128 octets (voir description des entrées dans le catalogue). L'OS peut utiliser un tampon pour charger chaque secteur et ainsi tronquer avant de copier les données sans déborder quand on charge en mémoire. Il peut aussi se servir de l'entête (sauf ASCII pur) pour connaitre la taille précise à l'octet près.

[gotcha]

Le probleme est que pour enlever les octets en trop à la fin du fichier, il faut interpréter les fichiers. Seul le logiciel qui les utilise sait le faire. Il doit effectivement y avoir un entête dans le fichier qui donne plus d'infos.

Dans mon cas, je me contente d'extraire les fichiers de l'image de la disquette. Comme je ne sais pas interpréter les fichiers, je ne peux qu'utiliser les infos du root directory et donc créer des fichiers dont la taille est un multiple de 128 octets.

[cathodique]

pour les fichiers CMD, l'entête est décrit ici http://www.seasip.info/Cpm/cmdfile.html

à voir si cet entête peut se retrouver sous d'autres formes (offset #7F pour le type avec des flags)

bon courage

edit: il y a d'autres formats décrits si tu remontes d'un cran http://www.seasip.info/Cpm/index.html => "Some file formats"

[gotcha]

Voici pour illustrer la fin d'un fichier BASIC que j'ai extrait d'une disquette CPM.
Ce fichier est du pur ASCII.
Après le RETURN, on peut voir 2 lignes en trop.

J'imagine qu'ils mettent un caractère spécial pour repérer la vraie fin de fichier.
Ici, on a le caractère 1Ah juste après le RETURN.

CPM garbage.jpg (18.06 Kio) Consulté 833 fois

[electropuce]

0x1A = Ctrl-Z

The CP/M file system (and also the original 8-bit FAT implemented in Microsoft BASIC) only recorded the lengths of files in multiples of 128-byte "records", so by convention a Control-Z character was used to mark the end of meaningful data if it ended in the middle of a record.

[gotcha]

Donc je peux à priori simplement chercher ce caractère pour connaitre la taille exacte et virer le garbage quand j'extrais les fichiers de l'image de disquette. Mais je pense que ca ne marche que pour des fichiers ASCII, les fichiers binaires pouvant avoir ce fameux 0x1A n'importe où.

[cathodique]

Je me méfierai et tiendrait compte de l'extension
D'autant plus que le garbage ne gêne que la visualisation et pas l'exploitation du fichier sur la machine!
Rien ne dit que l'enregistrement "ascii" n'a pas été utilisé pour du binaire sans entête d'autres données structurées, avec potentiellement des CTRL-Z un peu partout

[electropuce]

Mais je pense que ca ne marche que pour des fichiers ASCII, les fichiers binaires pouvant avoir ce fameux 0x1A n'importe où.

Bien sûr !

[gotcha]

Dans quelques disquettes CPM-86, j'ai un caractère étrange (0xCD = 205) au milieu de l'extension ('C' 0xCD 'D').
Quelqu'un sait ce que c'est ?

La logique voudrait que ca soit CMD

Quand j'extrais les fichiers de l'image de disquette, ça me crée des noms qui posent ensuite problème (quand j'essaie de bouger les fichiers par exemple)

CPM file extension.jpg (26.45 Kio) Consulté 672 fois

[gotcha]

Bon, j'ai trouvé dans la doc d'un ordinateur.

Les bits de poids fort dans l'extension sont en fait des flags (en tout cas pour CPM-86)
Si on enlève le bit de poids fort, 0xCD devient 0x4D, qui est effectivement le caractère 'M'.

CPM-dir-flags.jpg (66.73 Kio) Consulté 660 fois