Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
Kris a écrit :
Je viens d'essayer de recréer une disquette 3" à partir des fichiers RAW: ça plante sur old comme sur PLus. (fichiers transformé sous Sugarbox 0.29.209)
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 :
Pièce jointe :
Les Chevaliers Pistes Hexagon face A.jpg
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.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
Lone a écrit :
Le CTRaw, pour la piste 13, présente une taille (après mes algo de reconstruction) de 102746 bit MFM. Si on divise ce total par 16, ça donne 6421 octets. Une piste "standard", c'est 6250 octets (100 000 bits). On est donc 2% au dessus de la norme, ce qui est supporté largement par le hardware (de mémoire (à prendre avec des pincettes donc), les tolérances son de l'ordre de 5%).
Et encore tu es gentil :
Mate ça :
Pièce jointe :
Les Chevaliers Pistes Hexagon face A 2.jpg
Pièce jointe :
Les Chevaliers Pistes Hexagon face A.jpg
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.
Citer :
Kris : Pour la reconstruction, ça va être coton (même si l'IPF généré par Sugarbox 0.29 est correct, ce qui ne semble pas puisque le ctraw ne semble pas se charger sur cette version d'après Denis (je n'ai pas vérifié)). En effet, cette fameuse piste 13 (et ça n'est pas la seule) déborde au dessus du trou d'index.
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.
Citer :
J'ai fait des tentatives avec MAxit dans le même genre : Pour avoir tenté le coup sur les dumps "réussir", on a pu constater que le dump fait à partir de l"image reconstituée merdouillait au niveau de ce trou d'index. Difficile, voir impossible avec le matériel actuel, d'avoir donc quelque chose d'assez précis. On pourra d'ailleurs corroborer cette intuition avec des dumps, si tu as le temps, de l'IPF qui a servi à la reconstruction, et du CTRaw (ou autre format bas niveau) issue du dump généré.
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.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ 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)
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
Lone a écrit :
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).
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.
Citer :
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).
Attention, avec la perte de la densité du format DSK, on perd le visuel d'origine.
Citer :
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).
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.
Citer :
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....
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
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
marcel a écrit :
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)
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
Je viens d'essayer de recréer une disquette 3" à partir des fichiers RAW: ça plante sur old comme sur PLus. (fichiers transformé sous Sugarbox 0.29.209)
Mauvaise pioche, de telles pistes nécessitent pour tenir sur de la 3 pouces soit une traceuse industrielle, soit une carte kryoflux.
.
J'ai essayé avec une supercard pro et une Kryo: meme résultats => ça plante après le menu, peu importe le jeu selectionné.
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
Kris a écrit :
dlfrsilver a écrit :
Kris a écrit :
Je viens d'essayer de recréer une disquette 3" à partir des fichiers RAW: ça plante sur old comme sur PLus. (fichiers transformé sous Sugarbox 0.29.209)
Mauvaise pioche, de telles pistes nécessitent pour tenir sur de la 3 pouces soit une traceuse industrielle, soit une carte kryoflux.
.
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).
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
Lone a écrit :
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.
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.
Citer :
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.
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é.
Citer :
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).
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".
Citer :
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)
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.
Citer :
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).
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
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
@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 !
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 2 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum