Question image de disquettes IMD

[gotcha]

Hello,

Je suis en train de faire des outils pour travailler avec le format IMD (défini ici: https://oldcomputers-ddns.org/public/pu ... ls/imd.pdf)

Au niveau des secteurs, ce format IMD supporte une certain nombre de choses, dont des erreurs que je ne comprends pas complétement.
Est-ce que quelqu'un pourrait m’éclairer ?

J'imagine que ImageDisk a été "développé pour PC et qu'il suis donc des spécificités du monde PC (?)

• Sector data unavailable : un header de secteur valide avec une taille de data à zero ?

• Data with "Deleted-Data address" mark : Il y a un flag "Deleted-Data address mark" dans le header du secteur ? Est-ce spécifique à certains contrôleurs ? A priori, un certain nombre de contrôleurs comme le très classique uPD765 utilisé entre autre sur les PC gère ce type d'infos, impliquant qu'il va ignorer les secteurs 'deleted' durant une commande de lecture standard.

• Data read with data error : erreur CRC dans la partie data (ou aussi header ?)

• Deleted data read with data error : un secteur avec le flag "Deleted-Data address mark" et qui a en plus une erreur de CRC au niveau des data

[fneck]

Je ne comprends pas trop les questions de ton messages. ImageDisk est probablement le plus complet et le plus performant des copieurs tout format confondu, je l'ai souvent cité ici même. C'est un programme Ms-Dos, qui tourne donc sur PC, mais il est surtout destiné à copier d'autres formats. Tous les outils nécessaires sont contenus dans l'archives, on en est à la version 1.19 aujourd'hui, le site original est celui-ci http://dunfield.classiccmp.org/img/index.htm

Concernant les erreurs, il ne peut pas plus qu'un autre programme les éviter, mais il peut les ignorer lors de l'écriture de l'image (je dis ça de mémoire, à vérifier).

[gotcha]

Je ne parlais pas du programme ImageDisk mais des fichiers .imd que je cherche à interpréter.

Pour chacun des secteurs, on a dans le .img un 'sector data record' qui spécifie le type de secteur c'est.
Et dans la liste des secteurs possibles, il y a la mention de secteurs normaux avec 'deleted data address mark'. Je cherchais à comprendre ce que c'était et si c'était un concept généralisé à tous les contrôleurs floppy ou quelque chose de spécifique au monde des PC.

Mais en retravaillant le premier message de ce fil, je pense que j'ai plus ou moins trouvé la réponse. Ce 'deleted data address mark' semble assez courant pour les contrôleurs floppy, mais ce ne semble pas forcement exploité par les système d'exploitation / DOS.

Screenshot 2023-12-17 at 22-49-26 imd.pdf.png (24.78 Kio) Consulté 1051 fois

[fneck]

Là on est vraiment dans l'enregistrement des informations de formatage (hors données). Je ne connais pas assez pour pouvoir expliquer quoi que ce soit mais j'ai trouvé quelques débuts explications dans cette doc Shugart.

Voir ici et pages suivantes : https://www.manualslib.com/manual/18988 ... e=9#manual

[fneck]

Jeff_HxC2001 pourrait sans doute donner des réponses, mais je ne sais pas s'il nous lit régulièrement.

[gotcha]

Là on est vraiment dans l'enregistrement des informations de formatage (hors données).

Oui, l'IMD permet de stocker des données corrompues (mauvais CRC), tout en informant que le secteur n'est pas valide.

C'est pratique je trouve. Par exemple, le .img ne permet pas ça, et donc la greaseweazle remplit le secteur défectueux avec un pattern particulier pour qu'on puisse le détecter quand même. Mais du coup, on perd tout le contenu du secteur alors que peut-être juste un octet n'est pas bon (pas trop grave dans du texte).

Pour le "Deleted-data address mark", ça semble être une fonctionnalité du contrôleur floppy qui permet de faire 'disparaitre' un secteur de la commande standard 'READ' (sur le uPD765, il y a une autre commande READ DELETED pour lire ces secteurs spéciaux).
C'était peut-être utilisé pour enlever des secteurs défectueux au formatage. Ça a pu être aussi utilisé pour des protections.
Au final, c'est peut-être simplement une fonctionnalité créée par les designers hardware, mais non utilisée par le développeurs software

Une discussion des 'deleted sectors' ici: https://retrocomputing.stackexchange.co ... py-sectors

[Jeff_HxC2001]

Ceci est un secteur complet au format SD et DD :

track7.png (97.65 Kio) Consulté 907 fois

l'IMD décrit la valeur du Data address mark (DATA AM) ainsi que l'état du CRC et la présence ou non de la partie data, car oui il y avoir des headers sans zone data suite à une corruption ou dans le cas d'une protection par exemple. c'est le cas "Sector data unavailable". A noter que l'on peut avoir également des zones data sans header, mais ça le format IMD ne "sait" pas le décrire.
Deleted-Data address : C'est la valeur 0xF8 du Data address mark. Je pense que c'était utilisé par les premiers systèmes IBM pour invalider/libérer un secteur, (aujourd'hui c'est géré au niveau du système de fichier, plus au niveau des secteurs...)

Les cas "compressed" : le format IMD "compressé" les secteurs contenant la même valeur. ça c'est spécifique au format IMD.

Remarques :

- Ce format de secteur vient d'avant l'époque PC : Par exemple le format DD est souvent référencé comme format "System 34" dans les datasheet, c.a.d venant de l'IBM System/34 de 1977. J'imagine que la version simple densité est encore plus ancienne (a priori ça vient de l'IBM 3740 de 1973. A confirmer)...

Ce format est devenu ensuite une sorte de standard et de nombreux systèmes l'ont utilisé : PC, Amstrad, Atari ST , les CNC, les synthés etc etc. Je pense que ça couvre 80 à 90% des machines existantes. Les exceptions sont : Les machines commodores (C64, Amiga), les machines Apple bien que les derniers formats Mac en HD utilisent aussi le format System/34, les machines floppy "hard sectorées"...

- Les format Amstrad "DSK" et "D88" sont très similaires à l'IMD dans l'esprit.

- Le soft HxC sait lire et écrire le format IMD (et DSK, D88...) :

https://github.com/jfdelnero/HxCFloppyE ... d_loader.c
https://github.com/jfdelnero/HxCFloppyE ... d_format.h
https://github.com/jfdelnero/HxCFloppyE ... d_writer.c

[gotcha]

Merci @Jeff_HxC2001 pour ces précisions. Généralement, je dump en format SCP et j'utilise le soft HxC pour convertir dans un format plus compact qui enlève les imperfections du dump.

Le probleme que je vois est que beaucoup de format d'images semblent plus ou moins liés à une machine ou à un contrôleur floppy. De mon coté, je cherche toujours le format idéal d'image pour les disquettes qui n'ont pas de protections contre la copie.

L'IMD semble être un bon support: contient des données de formatage par piste et donc supporte des formats exotiques comme ceux du Goupil G3 (piste 0 en SD et autres pistes en DD avec plus de secteurs). Il garde aussi l'information sur l'interleaving des secteurs.

Le HFE lui garde les imperfections du dump (au niveau timing par exemple) et ne semble pas correspondre à ce que je cherche.

Y-a-t'il des formats d'image floppy ne gardant pas les imperfections du dump, non spécifiques à une machine et qui sont plus générique que l'IMD (gardant par exemple plus d'info sur les headers) ? Un format qui supporterait aussi le hard sector ?

[cathodique]

Il n'y a pas d'info de timing dans le HFE (hormis le débit), c'est un flux ultra linéaire et régulier

[gotcha]

Voici ce que j'obtiens par exemple en convertissant une image SCP en HFE.
Je parlais de timing, et c'est peut être autre chose. Mais je n'obtiens pas l'image 'parfaite' que je cherche.

Image HFE.JPG (141.98 Kio) Consulté 796 fois

[cathodique]

Oui, ok, ça c'est que la vitesse des vieux lecteurs est souvent houleuse et très variables (sans compter que ça accélère aussi sur les pistes proches du centre car on frotte sur moins de distance), il en résulte un nombre de bits par piste variable, loin du très théorique 100.000 bits (6250 octets). Mais le HFE va gommer une partie des variations quand même.

Si tu veux homogénéiser un HFE pour avoir une belle map, tu peux reprendre chaque piste et les caler sur la plus longue (mieux, se caler sur 6250 octets pour des disquettes classiques) et tes secteurs seront bien alignés. Et tu peux appliquer cette méthode à n'importe quel format en fait. Même les formats les plus prémâchés peuvent avoir des disparités dans la longueur de piste car il faut bien à un moment reconstruire la vraie piste à partir des infos secteur.

Histoire d'apporter une petit pierre en plus aux infos de Jeff, "Sector data unavailable" ça veut dire 2 choses:
- soit qu'il n'a pas trouvé de DAM (#F8 ou #FB pour les plus courants)
- soit qu'il a trouvé un DAM qu'il ne sait pas interpréter!!! Avec des infos derrière qui peuvent avoir un intérêt dans une protection

Ces secteurs "sans données", en tous cas, sans DAM compris par le contrôleur peuvent être écrits, puisque l'entête est présente et qu'un DAM n'est pas relu avant une écriture, mais purement et simplement écrasé. Si tu n'ajoutes pas des données "illisibles" à ta reconstruction et que quelqu'un écrit dans ce secteur, il va surtout écraser la suite !