Mauvaise pioche, de telles pistes nécessitent pour tenir sur de la 3 pouces soit une traceuse industrielle, soit une carte kryoflux.

Jettez un coup d'oeil ici :



La couleur bleue dans Aufit indique que la traceuse a gravé la disquette en utilisant la variation de densité.

Pour info, une piste CPC normal, c'est gravé en 2us. Ici, ils ont abaissé la taille du bitcell à 1,5x - 1,6x us.

Pour info bis, une piste longue sur Amiga utilisée pour faire de la protection seulement fait par cylindre $1900 de long soit $3380 en double face, en longueur de bits ça fait 105xxx bits de long.

C'est la taille de la piste de protection de la série du jeu Ishar.

Ici sur cette compilation, ils ont réalisé la même chose en 2 volets :

1) 40 pistes longue impossible à recopier, aucun drive CPC n'a la précision requise pour écrire correctement ne serait-ce qu'une seule piste, même avec l'astuce de la coupure moteur. Il faut pouvoir gérer la variation de la densité, que ne peut faire qu'une machine pro.

2) Contenance supérieure. une piste CPC normal fait $1200 (4608 octets 512x9 secteurs) de long. Les pistes utilisées ici font $1930 de long. Le gain en contenance est presque 70% supérieur à des pistes normales.

c'est complètement dingue, la piste 2 en hexagon $fait 182467 bits !!!

Autre chose. En visuel secteur, comme expliqué il y a pas mal de temps, une piste hexagon est une piste trafiquée par son entête, qui ne déclare que 512 octets sur les 6438 ou un chouille plus.

J'ai examiné la piste 41, elle est décomposée comme suit hors marqueurs de la structure de piste :

512 octets + 5860 octets de zone GAP = 6438 octets. Les 5860 octets étant bien sur les 3/4 manquants des données qu'un CPC ne saura pas copier car bloqué par la déclaration des 512 premiers octets.

_________________
SPS Community Expert (SPS CE) / SPS France

Et encore tu es gentil :

Mate ça :





On se rends compte qu'au final, Samdisk v3.8.10 est le plus près du dump de mon original.

Tu peux voir que les premières pistes sont super longues, j'ai trouvé 182467 bits !!! Bon par contre, ça s'amenuise au fur et à mesure qu'on avance sur les pistes.



C'est simple : j'aurais du regarder d'abord avec Aufit. Que dit Aufit ? Aufit indique que d'une piste sur l'autre, les données de fin de pistes sont bite à cul avec l'entête de piste suivante.

Le seul moyen pour avoir de la marge, c'est d'utiliser la variation de densité pour mettre un max de données dans un minimum d'espace. Sinon impossible d'esquiver le problème avec le trou d'index.



Justement, je n'ai pas eu l'occasion d'examiner ces pistes sur le logiciel "réussir", faudrait voir si un IPF est faisable, ou du moins voir si la piste de protection s'encode correctement ou pas.

_________________
SPS Community Expert (SPS CE) / SPS France

Autre souci que j'ai, c'est que la protection Hexagon $18A0 est reconnue par le CTA. Mais pas cette version parce que les pistes sont plus longues.

Il s'agit surement de la version Hexagon $19XX utilisées sur les compilations entre 1989 et 1991.

_________________
SPS Community Expert (SPS CE) / SPS France

La longueur en bits indiqué par Aufit me laisse perplexe : 192147 bits ne correspond à rien de logique...

Ni au niveau IPF, ni DSK, ni CT Raw, et surtout, ni même au niveau des autres infos retourné par Aufit.
La longueur qu'on récupère unanimement est plutôt de 102 000 bits (ce qui colle avec le reste).

Au niveau de l'utilisation de la piste, on est effectivement sur du lourd : On force un peu la tolérance (+2.5%), et surtout, on enlève le plus de gap possible (entre les pistes, et en fin de piste).

Pour faire un calcul un peu plus précis, d'habitude, on a (9 secteurs de 512 bytes) :
9*512 = 4608 * 16 = 73 728 bits utiles (de data, en MFM)
Là on a 6305 octets de donnée brutes, soit 100 880 bits de données (en MFM).

Soit un ratio de 136%. Le tout couplé avec un système de protection très compliqué à copier.
Bref, un bel ouvrage technique, même si on voit bien que la pérennité des disques n'est pas assurée....

Est-ce qu'il y a un format qui supporte la variation de densité? On pourrait tomber sur un loader qui contrôle cette densité (moins d'attente que la donnée soit prête)

Il n'y a qu'une seule réponse je pense à ce sujet : est-ce que tu te rappelle du mec qui a déplombé le jeu X-out sur CPC, qui expliquait que ce jeu avait des pistes de taille variable, et que certaines faisaient 12k ?

en gros, pour avoir autant de bits, il n'y a qu'une seule explication, la variation de densité. C'est un élément qui est perdu lors du passage au format DSK, puisqu'il ne gère que du sectoriel. La variation de densité, pour ce que j'en ai vu sur CPC, n'a été utilisée qu'en mode piste.

Chaque piste a une quantité complètement variable de bits. On voit d'ailleurs que cette quantité baisse au fil des pistes, ce qui est normal, puisque l'espace à remplir se réduit plus on arrive vers le centre du support magnétique.



Attention, avec la perte de la densité du format DSK, on perd le visuel d'origine.



Il y a plus que ça. Tu ne prends que 6305 octets parce que le format DSK dégage les octets composant la structure, et la zone GAP toute petite qui se trouve en fin de piste.



Oui la pérénité pose souci parce que les gens n'ont pas stocké les disquettes correctement.

En attendant, le dump lourd kryoflux montre qu'il y a un écart sérieux entre ce qu'on a en DSK et ce qu'on a dans le CTraw voir l'IPF.

_________________
SPS Community Expert (SPS CE) / SPS France

Pour répondre à ta question, le seul format qui supporte la variation de densité, c'est le format CTraw et IPF. Le format CTraw parce que même si les données sont stockées au format MFM, la représentation des données est conservée, et respectée par la DLL de SPS.

Pour le format IPF ça va de soi, puisque c'est un container de description de format de piste. C'est la description contenue dans la structure du fichier IPF qui va permettre à la carte kryoflux de graver exactement les données comme il faut.

_________________
SPS Community Expert (SPS CE) / SPS France

J'ai essayé avec une supercard pro et une Kryo: meme résultats => ça plante après le menu, peu importe le jeu selectionné.

tout à fait normal. Pour réécrire correctement ces pistes, il ne faut pas perdre la variation de densité.

_________________
SPS Community Expert (SPS CE) / SPS France

C'est surprenant : Au niveau de la densité, l'IPF fournit ne donne que de la densité automatique ( taille de cellule calculée d'après la taille totale). On n'a pas de variation au sein de cet IPF, de ce fait.

Le CTRaw donne également des informations de timings, celles-ci étant un peu plus précises : On a une taille moyenne pour un octet MFM (8 bits). Si on regarde le contenu, on voit d'ailleurs que l'on oscille entre 15 et 16 us.

Concernant les tailles de pistes, on est de toute façon limité par le hardware : Il n'est pas possible pour un FDC de stocker plus de (environ) 110 000 bits MFM sur une piste (en prenant une tolérance de 10%, ce qui doit être le max du max).

110 000 bits MFM, ça donne 6800 octets de données, en considérant aucun header d'aucune sorte. On est donc loin des pistes de 12k (sauf si 12k = 12k de données MFM, auquel cas c'est tout a fait dans la norme, et ça n'a rien de spécial)

Sinon, le DSK s'en sort tout de même pas mal : J'ai (quasi) la même piste entre un décodage sioux du dsk et celles du ctraw (qui n'est pas ambigue).

Les indications données dans l'IPF au delà du fait qu'il n'est pas valide, sont là pour dire au FDC propriétaire du Kryoflux, tu m'écris telle taille dans un espace réduit de 10% (par exemple).

ça n'est pas indiqué en clair, mais le FDC de la carte le comprend automatiquement.



Quand j'examine le dump lourd avec Aufit, je vois que la taille des bitcells est de 1,5x / 1,6x us et pas 15 ou 16 comme tu l'indiques, au lieu de 2us en temps normal. Rien que ça confirme la variation de densité.



Pour l'Amiga c'est pareil. Même cette machine ne peut lire que des pistes faisant pas plus de 6800 octets (piste écrite avec variation de densité).

Comme le CPC utilise un FDC pour machine 16 bits, il en est lui aussi capable, tout comme le ST, mais avec une limite physique de 6700 octets, et pas sur toutes les pistes, à cause des limites du support 3".



C'est incorrect. Les pistes les plus grosses que j'ai vu sur FDC upd765/WD1772 c'est 6700 octets, MAXIMUM, données + octets de structure de pistes + gap.



le format DSK perd les zones GAP, la variation de densité, et le format de piste hexagon (ce qui invalide toute réécriture ultérieure).

_________________
SPS Community Expert (SPS CE) / SPS France

juste pour info …

de mon edsk transforme en ipf avec sugarconvdsk et ecrit avec le kryoflux fonctionne nickel sur mon 6128

Faut que je teste à partir du eDSK ce soir

@Breiztiger: lis tes MP

Super Dommage que l'outil de Thomas ne puisse pas être utilisé officiellement.......

_________________
SPS Community Expert (SPS CE) / SPS France

@marcel : Par contre, de ma compréhension, impossible pour un loader sur un cpc d'utiliser la variation de bitrate pour gérer une protection !

C'est une histoire entre le support, le data separateur et le FDC !
En sortie du FDC, on a des beaux octets et le résultat des commandes vers le z80 via le bus de données -> c'est tout !

--> Il y aurait fallu avoir la possibilité de piloter cela depuis le z80 avec l'hardware du cpc pour que ça marche !

@dlfrsilver : pour l'outil de Thomas, il utilise le format IPfs en mode raw bits pour tout (les données, les gaps, etc.) contrairement à l'outil SPS pour la partie CPC qui gère en octets la partie data !
Mais pour moi, surement que cet outil évoluera un jour pour prendre en compte les données en mode rawbits, car c'est la seule chance de faire fonctionner des dumps parfait pour la série des réussirs de Logiciel 44 par exemple... de mémoire, dans ce cas le loader se sert de cet particularité car il lit en mode piste puis en mode secteur avec un N supérieur pour vérifier le décalage de bit en début de piste...
pour l'explication, en gros de ce que j'ai compris avec mes tests : les données ne finissent pas sur un octet fixe suite à la coupure volontaire d'écriture en fin de piste, du coup le début de la piste n'est pas le même car il y a un décalage de bit avec la lecture de secteur avec N supérieur à la quantité de données !
D'ailleurs cette astuce de lire une piste en lisant le premier secteur avec un N supérieur à la taille de la piste pour le premier secteur (exemple N>6), permet sur amstrad de lire la totalité des infos présentes (IDTrack, synchro, gap, IDR, etc) ! bon après, le problème reste qu'on peut pas les réécrire comme cela sur amstrad car on ne peut pas piloter le FDC en écriture en mode piste, surtout s'il y a des infos dans les gap ou des secteurs entrelacés, etc....on les a mais impossible de les réécrire, y compris si la densité est supérieure -> boum on écrira pas assez de données -> d'où ce type de protection anti-copie bien efficace sur cpc mais pas sur d'autres machines !