Voila une bonne nouvelle !

Enfin bonne.... Je reste un peu sceptique sur l'intérêt de faire des dumps numérotés pour préservation, si derrière c'est pour les conserver dans un endroit non disponible et interdire leur diffusion...

C'est donc une nouvelle qui risque d'intéresser bien peu de monde, au final (et c'est bien dommage).

J'ai fini d'uploader tout les fichiers sur le serveur d'SPS.

Je vais donc mettre ici à disposition les fichiers RAW, ça te permettra de corriger les bugs (il y en a encore) dans le chargement des RAW/IPFs (exemple, tout les jeux ocean à secteur faible genre dragon ninja resetent, même en IPF), alors que sous caprice32 la protection est bien gérée.

On se tient au courant

Je suis surpris pour le nécromancien : La protection est certes pas simple (des CHRN contenant n'importe quoi ), mais si l'on reste au niveau MFM, il n'y a pas de raison que ça ne fonctionne pas. (je passe sans problème la protection sur un dump RAW ou SCP)

Il faudrait que je me penche un peu sérieusement sur ce format IPF (même si son côté "je ne diffuse pas" me déplaît), pour comprendre quelle plus-value il apporte par rapport a un dump RAW tout bête...

fano avait fait des tests d'écriture avec un lecteur 3" de PCW en 80 tracks...
A la relecture, le lecteur du CPC ne sait voir qu'une piste sur deux. Du coup, même si tu avais 2 pistes en 1 écrite avec un ST, un PC ou même un fer à repasser (soit 12K par piste CPC), tu ne pourrais que relire la moitié au risque que ça ne soit pas la même en fonction du calibrage de la tête... Pire, ne rien pouvoir lire. Du coup, je trouve ça vraiment étrange...

Le nécromancien a déjà été dumpé sans problème avec SAMdisk et il passe sous cpc++ et sugarbox (peut-être ACE ?) sans soucis.
Du coup, je ne vois pas où est le problème pour les outils IPF de reproduire cela ?

La piste 40, à cet égard est d'ailleurs tout ce qu'il y a de plus classique au sens MFM, comme nous le montrent les Dumps RAW ( qui ne mentent jamais) : on a bien nos ( à peu près ) 100 000 bits avec les sync la ou il faut. C'est juste les secteurs qui sont fantaisistes et trompent les outils qui se basent dessus ( d'où la supériorité du raw ou scp pour l'émulation ). Je soupçonne donc l'outil ipf de se baser dessus, et donc, comme le dsk, de fournir des données interprétées.

Forcément c'est moins simple.

C'est exactement ça.
D'ailleurs, on peut quasiment toujours reconstituer une piste de 6250 octets (grosso modo) a partir d'une piste de 12k ou plus (c'est ce que fait sugarbox).

La plupart du temps, quand on a beaucoup de secteurs, ils se chevauchent : On a le début du secteur 2 en plein milieu du secteur 1, etc, ce qui peut faire passer une piste de taille normale pour une de taille bien plus grosse.

On au aussi les tailles énormes. Par exemple, APB possède une piste avec des secteurs de taille 0, 1, 2, 3, 4, 5, 6, 7, 8. Si l'on regarde le dsk, on vois que l'on n'a jamais plus de 256 octets de "vrai" données, on tombe ensuite sur les CRC, GAP, et sur le secteur suivant. C'est là dessus que je me base pour reconstruire la piste attendue, qui (miracle) fait dans les 6k....

Ca se voit au coup d'oeil : Dans un dsk, une zone de 4E précédé de deux octets divers indique souvent un gap (et donc, un secteur plus court que ce que l'en-tête laisse présager). Après cette zone, si elle est suivie d'autre chose, on trouvera souvent des 00 ou FF, si la synchro a été un peu perdue (c'est pour ça que l'on a des zones de synchro et de gap), puis l'en-tête CHRN suivante (CHRN = Cylinder-Head-secteur-size, ce qui sert au FDC pour identifier le secteur à lire à partir des paramètre d'une commande de lecture secteur), en-tête parfois "brouillée" si la synchro n'est pas bonne, là encore.

Mais au final, on s'y retrouve toujours : Même si la synchro n'est pas bonne, on retrouve les bits de clock plutôt que les data, et donc on peut "recoller" la piste en un seul morceau.

L'outil de SPS va donc faire ce que font les outils de lecture de disque : interpréter le flux MFM. Ce qui, une fois encore, est très bien si la destination ne comprend pas le bitstream MFM, et parfaitement inutile dans le cas contraire.

fano avait fait des tests d'écriture avec un lecteur 3" de PCW en 80 tracks...
A la relecture, le lecteur du CPC ne sait voir qu'une piste sur deux. Du coup, même si tu avais 2 pistes en 1 écrite avec un ST, un PC ou même un fer à repasser (soit 12K par piste CPC), tu ne pourrais que relire la moitié au risque que ça ne soit pas la même en fonction du calibrage de la tête... Pire, ne rien pouvoir lire. Du coup, je trouve ça vraiment étrange...