CPC Rulez
https://cpcrulez.fr/forum/

SugarConvDsk
https://cpcrulez.fr/forum/viewtopic.php?f=8&t=5844		 Page 11 sur 14
Auteur :  Lone [ 13 Jan 2017, 15:14 ]
Sujet du message :  Re: SugarConvDsk
dlfrsilver a écrit :
C'est pas une question d'avis ou d'opinion, mais de savoir si techniquement c'est bon ou pas. Et je te redis que techniquement tu te plantes.
Le FDC de l'Amstrad, de l'Atari ST et du PC ne permet pas de faire de la préservation. Point à la ligne.
Les FDCs qui équipent ces machines sont des puces "esclaves", qui zappent une bonne partie des données parce qu'elles ne gèrent pas en mode piste.
TOUT les originaux sont gravés en mode piste, et pas en mode secteur. C'est encore la 2ème raison pour laquelle tu te trompes.

Alors là, je ne vois même pas quand j'ai pu dire le contraire.
Evidemment que le FDC ne peut pas faire de la préservation... (et encore moins en mode piste)
On est d'accord, mais manifestement, tu n'as pas compris certain de mes propos.
D'ailleurs, tu associes beaucoup FDC et DSK... Rien ne nous y oblige !
Sugarbox (et d'autre) déduisent une piste MFM du DSK. On sort donc de la gestion "uniquement secteur ou readtrack" dont tu parles.
dlfrsilver a écrit :
Citer :
En reprenant les messages au dessus, tu parles de conversions qui sont mal traitées.

Je vais être brutal dans ma réponse : tu fais exprès de ne pas comprendre ce qu'on te dit en fait.
Giants n'a pas parlé de conversions mal faite, il te dit comme moi qu'un eDSK ou un DSK n' a rien à faire dans un IPF.

Ok, c'est votre avis, je le respecte. J'ai renoncé à discuter sur le sujet.
Cela dit giants a bien dit :

"Désolé, ce n'est pas vrais tout le temps, surtout sur des conv. avec des pistes en fin hors norme.
Ta moulinette 'actuel' les traites mal et du coup sur un certain soft, ça ne passait pas (maintenant, ça passe en warning depuis que j'ai demandé une modification au dev du soft en question)."

C'est à cela que je fais allusion.
dlfrsilver a écrit :
Citer :
Peux tu me donner des détails ? J'ai fait le test suivant : J'ai pris l'ensemble de mes dumps (tout format confondus), et via un script, je les ai convertis en IPF, puis comparés track par track à l'original (comprendre l'original chargé sous forme de piste). La dernière version converti correctement l'ensemble de ces dumps.

Les eDSK n'étant pas 100% conformes aux originaux comme expliqué juste au dessus, ces derniers ne peuvent pas proposer le même contenu qu'un IPF.

Cela ne peut expliquer un problème de format.
Les protections sont correctement incluse dans les DSK. Ce qui manque, c'est tout ce qui est autours et non indispensable, et ne peut être déduit (taille de certain gaps, certains CRC, éventuellement les bricolages MFM, etc).
dlfrsilver a écrit :
Citer :
J'en déduis que le problème vient d'une partie du format lui-même, à priori incorrect ?

Oui, depuis le temps que je t'explique que le format eDSK est limité à cause du FDC lui-même, car il ne fait que de la gestion sectorielle avec un peu de read track.....
En fait, cette phrase indique et explique que soit techniquement tu n'as pas compris la différence entre un eDSK et un IPF, soit que tu ne vois aucune différence entre le format eDSK et le format IPF.

Je connais la différence. Mais tu as raison, je fais un abus de langage. En fait, quand j'évoque le dsk, je pense plutôt à la piste MFM déduite d'un dsk (ce qui n'est pas tout à fait pareil).

Par ailleurs, ce qu'on déduit permet de reconstruire une disquette fonctionnelle, protection comprise (exemple, la LATIS mentionné par breiztiger). Je suis d'accord pour dire que ça n'est pas une image du master original (tout au plus, un équivalent fonctionnel).
dlfrsilver a écrit :
Quand j'ai vu ça, je me suis dit et merde..... ça y est on repart de nouveau vers le 'ça marche en ému et pas sur un vrai CPC....'
Je tacherais de retrouver les titres....

Ah ben voila qui m'intéresse. L'idéal, si tu peux le faire, serait de dumper (en kryoflux ou ctraw) la disquette générée incorrecte, on aurait des tonnes d'infos intéressantes.
Auteur :  Giants [ 13 Jan 2017, 15:38 ]
Sujet du message :  Re: SugarConvDsk
@Denis
Les ipfs contiennent des informations, elles ne sont pas scriptées.
Scripté est un terme que l'on utilises quand l'on programme quelque chose.
Scriptée veux dire que tu codes quelques choses pour en faire autre chose, ce n'est pas la même définition que décrite, integrer dedans, etc..
Il ne faut pas confondre scripté avec 'écrite dedans'. j'ai bien compris ce qu'il a voulu dire mais le terme choisie n'est pas le bon.
C'est une des raisons pour lequel je ne discute pas technique avec breiztiger, les autres raisons sont personnel et n'ont pas lieu à débat ici.

Un/une ?(c'est un mal ou une femelle, ils ont oublié ce champ dans le header) ipf n'est pas un programme, il n'a pas de script à l'intérieure, ce sont des données préalablement traité avant par cta ou autre comme tu le sais mieux que moi.
C'est dans ce sens que le terme scriptée à été mal utilisé par breiztiger.


@Lone : dans le désordre de ma lecture
>Ne reparlons pas de l'usage de l'IPF, chacun son avis (son dogme serais-je tenté de dire)
Je suis d'accord. peu être, après tout, c'est nous qui avons mal compris la liaison ip<>master
Si on prends leur définition cité plus haut, il est vrai qu'ils disent : C'est Celui que l'on a choisi...
Je veux bien t'accorder le bénéfice du doute sur ce sujet après tout.
Ceci n'étant pas publiquement, officiellement, légalement clair.
Néanmoins, et jusqu'à maintenant le format IPF ne contenait que des données type 'original', 'master' et ce à base de flux.
Avec ton outils, ça ne sera plus forcément le cas. Ca me gène, il faudrait le différencier, enlever cette confusion possible.

>J'ai eu quelques discussion à ce sujet avec plusieurs personnes, qui faisait parfois des raccourcis sur un aspect du format : Dans le cas de description de champs de bit, elle considéraient que l'on n'avait que des nombres multiples de 8. Ce qui n'est pas forcément le cas, et surtout, ce qui fait la puissance du format. De ce fait, mes dumps générés avec des nombres de bits non multiples de 8 plantait leur soft.

La tu parles d'aufit ? Tu en a déjà fait une version patché, a priori, je ne parle pas de cette problématique.

>J'en déduis que le problème vient d'une partie du format lui-même, à priori incorrect ?

C'est le mot que j'aurais utilisé oui, incorrect sur certaines pistes en sortie à moins que tout les autre softs que j'utilise soit bugé sur ce sujet, ce qui, je te l'accorde est aussi une possibilité mais vue que ces softs fonctionnent avec la lib SPS, peu probable.


A ma connaissance, le seul logiciel public pouvant re-créer le plus fidèlement possible un dump ipf est dtc, donc, essaye ça déjà :

- Tu prends Black Tiger original dump Uk sur cpc-p0wer au format dsk ou edsk que tu convertie avec sugarconv au format ipf
- Essaye de re-creer la disquette avec dtc et ton ipf généré. Prends WildeWutz par exemple. Le format n'est pas compris.
- Au niveau analyse, regarde la longueur des Data sur chaque block de la piste 00 et donc le nbr de bytes/sector, compare par rapport au dump sps. 'secteur par secteur'
- Regarde aussi dans ta structure du fichier crée par sugarbox, les infos des pistes 40 et 41.

Ton image Ipf générée, quand elle 'passe' à la moulinette de la lib SPS, à de grosses variantes par rapport au dump SPS du même jeux.
Es-ce important ? Pour moi oui ! Peu importe si elle fonctionne ou pas.

Donc l'une de vos images ipf est forcément plus proche de la réalité que l'autre.
La tienne, générée à partir d'une image dsk/edsk
ou
la leur, générée à partir d'un flux


Black tiger est un 'petit' exemple, j'en ai des beaucoup plus flagrant et ce visuellement au niveau des différences (chose qui n'est pas le cas avec black tiger).
Si tu n'as pas l'ipf ou le flux original de BlackTiger: Mp ou mail, je ne le donne pas mais je te donne un lien ou tu verras ce que je viens de dire.
Pour info... ce lien est accessible a tout le monde et tjs au même endroit...
Auteur :  dlfrsilver [ 13 Jan 2017, 15:47 ]
Sujet du message :  Re: SugarConvDsk
Lone a écrit :
Alors là, je ne vois même pas quand j'ai pu dire le contraire.
Evidemment que le FDC ne peut pas faire de la préservation... (et encore moins en mode piste)


C'est pas exactement ça. Le format eDSK ne permet pas de faire de la préservation parce qu'il a été conçu autour du FDC du CPC. Comme ce dernier tronque les informations, pas de préservation.

Citer :
On est d'accord, mais manifestement, tu n'as pas compris certain de mes propos.


j'ai parfaitement compris ce que tu dis, c'est pour ça que je manifeste mon désaccord.

Citer :
D'ailleurs, tu associes beaucoup FDC et DSK... Rien ne nous y oblige !


En fait, tu t'es embourbé le cerveau avec ton système de "déduction" et de reconstruction de piste pour le format eDSK.

Le format DSK est pieds et poings liés au FDC du CPC. Tu t'acharnes à reconstruire et à palier les trous laissés par le format DSK. Mais les données ne sont toujours pas identiques à l'original.

C'est pas parce que tu as une image disque fonctionnelle, pour reprendre les mots de JMD, qu'on peut parler de préservation.

le format Edsk est juste fonctionnel, et facile d'usage en émulation, et c'est tout.

Citer :
Sugarbox (et d'autre) déduisent une piste MFM du DSK. On sort donc de la gestion "uniquement secteur ou readtrack" dont tu parles.
dlfrsilver a écrit :

Ce que tu dis là est correct. Mais ce n'est toujours pas identique à l'original. J'illustrerais ce soir quand je serais rentré du boulot avec le cas de Strider.

Citer :
Ok, c'est votre avis, je le respecte. J'ai renoncé à discuter sur le sujet.


Ce n'est pas une question d'avis. L'inclusion d'image reconstruites, ou de données tirées d'images disque secteur ou piste (pour l'amiga), ne sont pas autorisées.

Genre je prends pas une image ADF sur Amiga, je la converti en MFM ou en flux et j'en fais un IPF. C'est pas un original, il manquera toujours des informations dedans.

VERBOTEN !

[quote)Cela dit giants a bien dit :

"Désolé, ce n'est pas vrais tout le temps, surtout sur des conv. avec des pistes en fin hors norme.
Ta moulinette 'actuel' les traites mal et du coup sur un certain soft, ça ne passait pas (maintenant, ça passe en warning depuis que j'ai demandé une modification au dev du soft en question)."

C'est à cela que je fais allusion.


tu vas plus vite que la musique, et pire, j'appréhende ce que le créateur du système aura mis en place pour reprendre la main.

La "génération d'IPF par les gogoles" (pardon pour le terme) c'est quelque chose qu'on a toujours évité jusqu'ici, car c'est obligé, on va se retrouver avec des fichiers claqués, y a forcément des mecs qui vont générer des images pourries.

C'est du garanti sur facture. Et j'attends de voir ça.....

dlfrsilver a écrit :
Cela ne peut expliquer un problème de format.


C'est ultra simple pourtant. Télécharge Aufit, et examine un dump original KF raw d'un soft, et compare avec une réversion KF raw d'un edsk, ou même d'un IPF généré avec ton soft via HxC.

Ensuite examine les graphiques des pistes, tu t'apercevras tout seul comme un grand que ta reconstitution de pistes ne règle rien du tout. Et pire, tu vas faire un bon de ta chaise quand tu verras que certaines protections ne ressemblent plus du tout à l'original.

Tes conversions mode secteur mode piste (c'est ça en fait ton histoire de reconstruction MFM des pistes), c'est juste fonctionnel, mais pas correct.

Citer :
Les protections sont correctement incluse dans les DSK.


non car le format DSK ne permet pas pour nombre d'entre elles de les stocker tel qu'elles sont véritablement.

Citer :
Ce qui manque, c'est tout ce qui est autours et non indispensable, et ne peut être déduit (taille de certain gaps, certains CRC, éventuellement les bricolages MFM, etc).


justement, tu déduis des choses approximatives tandis que moi je récupére depuis un original non modifié les données telles qu'elles ont été préparées, je les analyse, je confirme quel système de protection est utilisé, et j'active la génération (j'injecte les données analysées par le CTA dans le container vide IPF).


Citer :
Je connais la différence. Mais tu as raison, je fais un abus de langage. En fait, quand j'évoque le dsk, je pense plutôt à la piste MFM déduite d'un dsk (ce qui n'est pas tout à fait pareil).


C'est pas tout à fait pareil, mais l'abus de langage est là. Tu as voulu par le biais de tes routines "boucher les trous", car c'est bien de ça qu'il s'agit, mais c'est de la donnée modifiée au final.

Le format IPF ne peut pas être associé avec ça.

Citer :
Par ailleurs, ce qu'on déduit permet de reconstruire une disquette fonctionnelle, protection comprise (exemple, la LATIS mentionné par breiztiger). Je suis d'accord pour dire que ça n'est pas une image du master original (tout au plus, un équivalent fonctionnel).


Merci, ça soulage de lire ça enfin !

dlfrsilver a écrit :
Ah ben voila qui m'intéresse. L'idéal, si tu peux le faire, serait de dumper (en kryoflux ou ctraw) la disquette générée incorrecte, on aurait des tonnes d'infos intéressantes.


Ah bah comme indiqué plus haut, tu seras surpris du résultat......
Auteur :  Giants [ 13 Jan 2017, 15:49 ]
Sujet du message :  Re: SugarConvDsk
@Lone
>Les protections sont correctement incluse dans les DSK. Ce qui manque, c'est tout ce qui est autours et non indispensable, et ne peut être déduit (taille de certain gaps, certains CRC, éventuellement les bricolages MFM, etc).

Intéressante comme remarques mais erroné il me semble.
Si ses données sont non indispensable, pourquoi alors le jeux au format dsk/edk ne fonctionne pas une fois gravé ?
Ou même sur un emulateur qui n'a pas une routine pour re-créer ses données non-indispensable !

Pour moi, elles font partie de la protection, elle font partie du master

>Je suis d'accord pour dire que ça n'est pas une image du master original (tout au plus, un équivalent fonctionnel).
Ah la je dit bravo, on avance. 100% d'accord. Du coup, comment l'utilisateur l'ambda va faire la différence avec les images SPS CPC ?
Je dit bien utilisateur lambda (pas de crc, pas de site de confiance ou autre truc de ce type)


Que l'on s'entendent bien, ta routine de reconstruction me trous le cul, vraiment.
Mais, comme l'on* a associé IPF<>MASTER, pour moi, la sortie de ton soft ne devrait pas être en Ipf
C'est tous, et surtout pas avec en entrée des dsk/edsk
C'est le mélange de tout ça qui porte a confusion.

*On c'est quand même l'ensemble de la communauté Amiga entre autre... Y'a pas que moi et denis ;)
Auteur :  dlfrsilver [ 13 Jan 2017, 16:10 ]
Sujet du message :  Re: SugarConvDsk
Giants a écrit :
@Denis
Les ipfs contiennent des informations, elles ne sont pas scriptées.


Alors je m'explique plus précisément : le format IPF contient des informations scriptées. Scriptées, parce qu'un master disquette, comme à la belle époque consistait en une image disque, comme un IPF, contenant les informations secteurs et pistes, mais aussi les timings, la taille en bitcell, l'état des bits (weak ou strong).

La console DTC est dotée d'un parseur, qui lorsqu'il rencontre les infos "scriptées" trace les données en fonction. On parle d'ailleurs, et même à l'époque de description de format via un script externe. dans le format IPF, ces infos scriptées sont dans l'IPF. Elles sont indiquées par le CTA lors de l'analyse et sauvegardées dans l'IPF résultant.

Citer :
Scripté est un language que l'on utilises quand l'on prgramme quelque chose.
Scriptée veux dire que tu codes quelques choses pour en faire autre chose, ce n'est pas la même définition que décrite, integrer dedans, etc..


Justement Giants, les infos scriptées du format de disque sont insérées dans l'IPF pour que le DTC sache de quelle manière piloter le FDC custom présent sur la carte kryoflux.

Citer :
Il ne faut pas confondre scripté avec 'écrite dedans'. j'ai bien compris ce qu'il a voulu dire mais le terme choisie n'est pas le bon.
Un/une ? ipf n'est pas un programme, il n'a pas de script à l'intérieure, ce sont des données préalablement traité avant par cta ou autre.
C'est dans ce sens que le terme scriptée à été mal utilisé.


C'est le terme utilisé par le créateur du système.

Citer :
@Lone : dans le désordre de ma lecture.
>Ne reparlons pas de l'usage de l'IPF, chacun son avis (son dogme serais-je tenté de dire)
Je suis d'accord. peu être, après tout, c'est nous qui avons mal compris la liaison ip<>master
Si on prends leur définition cité plus haut, il est vrai qu'ils disent : C'est Celui que l'on a choisi...
Je veux bien t'accorder le bénéfice du doute sur ce sujet après tout.
Ceci n'étant pas publiquement, officiellement, légalement clair.
Néanmoins, et jusqu'à maintenant le format IPF ne contenait que des données type 'original', 'master' et ce à base de flux.
Avec ton outils, ça ne sera plus forcément le cas. Ca me gène, il faudrait le différencier, enlever cette confusion possible.


Je suis d'accord avec toi. Thomas doit créer une autre extension, afin de tuer toute confusion avec le format IPF, et que ça n'engendre des problème.

Appelle la nouvelle extension *.CPC *.SUG *.SDF (Sugarbox disk format)

Citer :
A ma connaissance, le seul logiciel public pouvant re-créer le plus fidèlement possible un dump ipf est dtc, donc, essaye ça déjà :

- Tu prends Black Tiger original dump Uk sur cpc-p0wer au format dsk ou edsk que tu convertie avec sugarconv au format ipf
- Essaye de re-creer la disquette avec dtc et ton ipf généré. Prends WildeWutz par exemple. Le format n'est pas compris.
- Au niveau analyse, regarde la longueur des Data sur chaque block de la piste 00 et donc le nbr de bytes/sector, compare par rapport au dump sps. 'secteur par secteur'
- Regarde aussi dans ta structure du fichier crée par sugarbox, les infos des pistes 40 et 41.


Merci Giants, tu illustres par cet exemple exactement ce que je voulais dire et démontrer. C'est le même cas de figure que Strider, le cas de Black Tiger que tu indiques.

Et l'explication est simple, même en reconstruction de piste, le contenu original est définitivement altéré. Samdisk converti le format PISTE de ce jeu en format Secteur.

Sur la disquette originale de Black Tiger ou de Strider, le format Secteur de ces 2 jeux tel qu'on le connait en format DSK n'existe pas sur les disquettes originales.

L'un comme l'autre utilisent la protection hexagon, qui n'est PAS contrairement à la croyance populaire constituée d'un gros secteur de taille 6, mais une piste longue composé d'un faux secteur de 512 octets avec une erreur DCE (Data Checksum error), car tronqué. Les 5278 octets de données de la pistes sont vues comme une gigantesque zone GAP par le CPC.

C'est ça que Giants veut aussi illustrer. Le FDC du CPC est incapable de voir la piste longue telle qu'elle a été écrite par la machine traceuse en usine. Le CPC lit chacune de ces pistes comme un gros secteur de taille 6.

ça montre parfaitement ce que je disais. Le FDC modifie et transforme dès la lecture les données lues.

Citer :
Ton image Ipf générée, quand elle 'passe' à la moulinette de la lib SPS, à de grosses variantes par rapport au dump SPS du même jeux.
Es-ce important ? Pour moi oui ! Peu importe si elle fonctionne ou pas.


C'est plus grave que ça, le CTA voit non seulement que la piste est modifiée, mais en plus, il indique que le format n'existe pas !

Citer :
Donc l'une de vos images ipf est forcément plus proche de la réalité que l'autre. La tienne, générée à partir d'une image dsk/edsk ou la leur, générée à partir d'un flux


C'est bien évidemment le dump en flux tiré de la disquette originale qui nous permet d'avoir un IPF officiel parfaitement conforme à ce qu'il y avait sur la disquette originale, alors que l'IPF généré par sugarconv contient du contenu copié, du gloubi boulga quoi, mais rien qui soit ou ressemble à l'original".

Citer :
Black tiger est un 'petit' exemple, j'en ai des beaucoup plus flagrant et ce visuellement au niveau des différences (chose qui n'est pas le cas avec black tiger).
Si tu n'as pas l'ipf ou le flux original de BlackTiger: Mp ou mail, je ne le donne pas mais je te donne un lien ou tu verras ce que je viens de dire.
Pour info... ce lien est accessible a tout le monde et tjs au même endroit...
[/quote]

Je posterais ce soir des images tirées d'Aufit, c'est tellement criant que ça saute au visage....
Auteur :  Lone [ 13 Jan 2017, 16:13 ]
Sujet du message :  Re: SugarConvDsk
Bon, je pense avoir compris une partie de notre désaccord :

Vous pensez que j'affirme que les IPF générés à partir d'un dsk sont des masters, alors que j'affirme juste qu'un dsk généré en IPF peut donner un équivalent fonctionnel !

Donc, on ne s'entend pas juste sur les détails : Pour quel but l'IPF a-t-il été créé.

Pour finir avec le DSK : Je n'ai a l'heure actuelle aucun exemple de dump dont la protection ne passe pas en dsk. Et on en a vu des tonnes !
- Le format dsk peut tout supporter.

Enfin, sur la re-création des données à partir d'un IPF, qui ne fonctionne pas : Cela demande analyse.
On ne peut pas faire de conjecture la dessus tant que l'on ne sais pas d'ou vient le ou les problèmes.

Par ailleurs, je n'exclus pas des bugs de SugarConvDsk, il y en a sans doute plein !
Mais au niveau logique, je ne vois pas ce qui peut coincer.

PS : Je regarde Black Tiger dès que j'ai un moment.
Auteur :  dlfrsilver [ 13 Jan 2017, 16:37 ]
Sujet du message :  Re: SugarConvDsk
Lone a écrit :
Bon, je pense avoir compris une partie de notre désaccord :



Citer :
Vous pensez que j'affirme que les IPF générés à partir d'un dsk sont des masters, alors que j'affirme juste qu'un dsk généré en IPF peut donner un équivalent fonctionnel !


Ah enfin ! C'était pas ce que tu disais jusqu'ici, j'ai même lu des horreurs de ta part.....

Citer :
Donc, on ne s'entend pas juste sur les détails : Pour quel but l'IPF a-t-il été créé.


Pour la préservation. Point à la ligne. Et pas pour contenir des copies remachonnées.

Citer :
Pour finir avec le DSK : Je n'ai a l'heure actuelle aucun exemple de dump dont la protection ne passe pas en dsk. Et on en a vu des tonnes !
- Le format dsk peut tout supporter.


Les protections sont simulées. Tu ne comprends pas que Samdisk fourni du pré-digéré passé par le FDC ?

Je rebondis sur les propos de Giants, si les DSKs sont impossible à réecrire dans nombre de cas, il y a 2 raisons :

1) les particularités du format de disque utilisé pour un soft ne sont pas décrit, et les pistes réecrites sont totalement hideuses et ne ressemblent à rien.

2) le FDC du CPC est bloqué, et incapable d'imager avec exactitude ce qu'il lit. Pour faire simple le FDC du CPC est surtout fait pour faire de la lecture.

Citer :
Enfin, sur la re-création des données à partir d'un IPF, qui ne fonctionne pas : Cela demande analyse. On ne peut pas faire de conjecture la dessus tant que l'on ne sais pas d'ou vient le ou les problèmes.


C'est simplement, le FDC d'un vrai CPC ne retrouve pas ou mal ses petits, voilà pourquoi ça ne marche pas. les FDCs CPC émulés ont une tolérance trop grande par rapport à un vrai, c'est aussi bête que ça.

Citer :
Par ailleurs, je n'exclus pas des bugs de SugarConvDsk, il y en a sans doute plein !
Mais au niveau logique, je ne vois pas ce qui peut coincer.

PS : Je regarde Black Tiger dès que j'ai un moment.


Le cas de Black tiger n'a rien à voir avec des bugs dans sugarconv. On est dans le cas ou la protection est simulée pour pouvoir tenir dans un fichier DSK.

Tu voulais un exemple quand on parlait de simulation, c'est un cas parmi un certain nombre. Ce qui est stocké dans le DSK ne correspond pas à la réalité.
Auteur :  Giants [ 13 Jan 2017, 17:13 ]
Sujet du message :  Re: SugarConvDsk
@Denis
Non, tu m'as mal compris. Il faut bien prendre mot à mot ça phrase.
Les infos ont été scriptée mais ne sont pas scriptée, tu voies la nuance ?
Il n'y a pas de traitement fait par l'ipf, le traitement est externe.
Scriptée c'est écrire une code exécutable, des data ne sont exécutable mais exécutée.

Ca c'est incorrecte :
>je rappelle quand meme que dans l'ipf toutes les infos en tant que données n'y sont pas, juste scriptée

Ca c'est correcte :
>je rappelle quand meme que dans l'ipf toutes les infos en tant que données n'y sont pas, elles ont juste été scriptée dedans

Ca aussi
>Justement Giants, les infos scriptées du format de disque sont insérées dans l'IPF pour que le DTC sache de quelle manière piloter le FDC custom présent sur la carte kryoflux.

Pour quelqu'un qui code, la nuance est importante car elle introduit un fichier qui va faire une action d'elle même
qu'un simple fichier contenant des datas qui seront traité Extérieurement.
Il ne faut pas prendre que le mot mais la phrase en elle même pour bien comprendre la nuance qui, pour des gens qui codent diffère l'action.

@Denis
>...C'est plus grave que ça, le CTA voit non seulement que la piste est modifiée, mais en plus, il indique que le format n'existe pas !
Tout a fait, c'est ce que me dit d'ailleurs DTC à la tentative de re-création de la disquette :)

@Lone
>Vous pensez que j'affirme que les IPF générés à partir d'un dsk sont des masters.
Oui et non, je pense que du fait que tu utilises en sortie le format IPF qui, jusqu'a maintenant servait UNIQUEMENT à un contenue de master, tu crée un confusion.

@Lone
>...alors que j'affirme juste qu'un dsk généré en IPF peut donner un équivalent fonctionnel !
Au vue de ce que fait ta moulinette, oui, elle peu donner un équivalent fonctionnel, je suis d'accord.

>Donc, on ne s'entend pas juste sur les détails : Pour quel but l'IPF a-t-il été créé.
C'est tout à fait ca :)

>Par ailleurs, je n'exclus pas des bugs de SugarConvDsk, il y en a sans doute plein !
Sans doute, mais du coup, comme tu utilises en sortie l'ipf, tu es obligé d'être dans les spec. de l'ipf, en l'occurence avec dans tes header :
ENCODER SPS(V1)
FILE 1(V0)

Donc, comment va t'on faire la différence avec les dumps que tu feras avec le NOUVEAU futur sugarconv (qui aura réglé le probleme)...
Vue que, en sortie ca sera tjs de l'ipf et tu sera tjs obligé d'être dans les spec. On ne peux pas...
à moins que tu changes quelques chose dans le header pour l'indiquer mais du coup, du sera hors spec. de l'IPF et donc, pas forcément utilisable en tant qu'ipf avec les autres outils se servant de la lib officiel SPS.


Oui je confirme, blacktiger n'est qu'un parmi tant d'autre et il y a d'autre soucis.
Auteur :  dlfrsilver [ 14 Jan 2017, 11:10 ]
Sujet du message :  Re: SugarConvDsk
Rapidement, j'y reviendrais cet après midi :

Black Tiger utilise des pistes hexagon, qui sont des pistes longues, et qui en plus font usage d'une protection par densité. En effet, les pistes point de vue données sont plus denses compte tenu de leur longueur.

Elles contiennent plus de données qu'elles ne le devraient. chaque piste fait en moyenne entre 6280 et 6293 octets de long.
Auteur :  Megachur [ 14 Jan 2017, 14:50 ]
Sujet du message :  Re: SugarConvDsk
Citer :
lles contiennent plus de données qu'elles ne le devraient. chaque piste fait en moyenne entre 6280 et 6293 octets de long.


je voudrais compléter ce point : si il y a plus de densité de données et que le drive + le data separator du FDC arrive à lire les données, c'est qu'elles sont ok d'un point de vue densité ! Je ne comprends pas la remarque "qu'elles ne devraient"... ça veut rien dire d'un point de vue hardware !!!
C'est juste que généralement, on mets moins de données en max car il faut une machine capable d'écrire avec cette densité qui doit être donc plus haute que la "normale"...

mais ton bon drive + data separator FDC sera capable de lire cela !!! ou alors, comme j'ai eu une fois avec l'original "outrun europa" sur un vrai cpc qui avait un drive fatigué (surement la courroie) -> read error !

cf uPD765_App_Note_Mar79

Citer :
With this circuit, peak-shifts of up to 375 ns (500 ns theoretical maximum) may
be tolerated in MFM encoded data before read errors wi I I be encountered.
Auteur :  Lone [ 14 Jan 2017, 15:51 ]
Sujet du message :  Re: SugarConvDsk
Cela dit, 6293 octets = 100688 bit MFM. Soit, à 5 tours par secondes, 503440 bit/s

Rien de foufou : Une cellule, c'est donc dans ce cas 1.986 us.
On est largement dans la tolérance pour la lecture.

Bref, il faudrait la version réécrite pour comprendre (ne serait-ce que la différence entre la version réécrite et la version destinée à la réécriture, si tant est qu'il y en ait une !)
Auteur :  Giants [ 14 Jan 2017, 16:15 ]
Sujet du message :  Re: SugarConvDsk
@Denis
Concernant le dump officiel de black tiger au format ipf donc, sur la track, disont...1 2 et 3
Donne moi la taille que tu voies via CTA en octets pour ces pistes.

Je voudrais vérifier quelque chose par rapport à ce que j'ai relevé de mon coté.
Si tes valeurs colles avec les miennes alors ont à la même source d'ipf et mon script est bon.
Si on a pas les mêmes valeurs, soit j'ai merdé quelque part dans mon script, ou, soit on a pas la même source et dans ce cas, je t'enverrais l'ipf que j'ai pour que tu me donnes les valeurs que tu voies pour ces 3 pistes histoire de valider mon code à cet endroit.

C'est juste pour checker et corriger mon script si besoin.
Tu peux mettre ca ici ou par mail, comme tu le sent !

merci
Auteur :  dlfrsilver [ 14 Jan 2017, 17:00 ]
Sujet du message :  Re: SugarConvDsk
Lone a écrit :
Cela dit, 6293 octets = 100688 bit MFM. Soit, à 5 tours par secondes, 503440 bit/s

Rien de foufou : Une cellule, c'est donc dans ce cas 1.986 us.
On est largement dans la tolérance pour la lecture.

Bref, il faudrait la version réécrite pour comprendre (ne serait-ce que la différence entre la version réécrite et la version destinée à la réécriture, si tant est qu'il y en ait une !)


Tu te trompes. Ce que tu dis n'est vrai quand si les 6293 octets étaient écrits en mode normal.

Regarde simplement :

Black Tiger piste 1, taille 6288 octets, longueur en bit = 122509 sur une durée de 199977,05 micro-secondes.

Ou encore Piste 7, taille 6291 octets, longueur en bit = 152659 sur une durée de 199976,56 micro-secondes.

Voici une image que j'ai assemblé pour montrer clairement la différence :
Auteur :  dlfrsilver [ 14 Jan 2017, 17:13 ]
Sujet du message :  Re: SugarConvDsk
Citer :
je voudrais compléter ce point : si il y a plus de densité de données et que le drive + le data separator du FDC arrive à lire les données, c'est qu'elles sont ok d'un point de vue densité !


Le FDC du CPC est capable de lire des pistes aussi longues que celles qu'on peut trouver sur une disquette 3,5 pouces de l'Atari ST ou du PC.

Le FDC du CPC est capable sans problème de lire des pistes avec variation de densité (comprendre, écriture avec un moteur ralenti dans le but d'écrire plus de données dans un "espace de données" normal.

Une quantité assez grande de protection contre la copie utilisent ce système, l'échec à la copie sur le système cible est garanti sur facture.

Ce que tu dis Megachur, est d'une évidence folle, mais ce n'est pas important, car il est clair qu'une variation de densité sur une disquette n'a jamais empêché un FDC de lire les données.

Tu enfonces un peu une porte grande ouverte :)

Citer :
Je ne comprends pas la remarque "qu'elles ne devraient"... ça veut rien dire d'un point de vue hardware !!!


Mais si justement !!! D'un point de vue hardware c'est pourtant TRES clair ! Quand on ralenti le moteur d'un lecteur de disquette, il y a en gros 10% de données en plus d'écrites sur le support !

D'ou ce que j'ai dit, en gros tu as 6291 octets de données écrites sur un espace plus réduit, les données sont donc plus denses !

Citer :
C'est juste que généralement, on mets moins de données en max car il faut une machine capable d'écrire avec cette densité qui doit être donc plus haute que la "normale"...


Rappel : les disquettes commerciales, en dehors de certaines au tout début de la vie du CPC, sont TOUTES gravées avec du matériel de duplication industriel, en mesure d'écrire des données avec une précision qu'un CPC n'a jamais atteint ni de près ni de loin.

Ton raisonnement n'est valable que si la disquette est écrite avec un lecteur de CPC avec un upd765. Mais comme on parle de disquettes commerciales, ton raisonnement n'est pas correct.

Ces disquettes étaient gravées via des machines dotées de FDC propriétaires n'ayant comme limites que le nombre de pistes maximales gravables, et une longueur maximale de pistes, toutes les fantaisies étaient possible.

Citer :
mais tout bon drive + data separator FDC sera capable de lire cela !!! ou alors, comme j'ai eu une fois avec l'original "outrun europa" sur un vrai cpc qui avait un drive fatigué (surement la courroie) -> read error !


C'était peut-être simplement ta disquette qui s'est mise à déconner :) Si les autres disquettes passaient, cherche pas, c'était ton outrun europa.
Auteur :  Giants [ 14 Jan 2017, 18:02 ]
Sujet du message :  Re: SugarConvDsk
@Denis
Petit détail mais, ce que tu as analysé n'est pas l'ipf (au vue de tes captures d'images) mais le format RAW.
Je ne suis pas dans le code de Lone mais je pense que la moulinette vers du RAW n'est pas forcément la même qu'en sortie vers de l'IPF.
De toute façon, aufit n'a pas en entrée le format IPF...
J'imagine donc que tu as utilisé shugarconv avec en sortie le format RAW (et pas un autre soft pour extraire le flux de l'ipf, sinon c'est mort)
Tu me valides que tu as pris en sortie le format RAW de shugarconv et pas un autre outils ? merci.

De mon coté, j'ai utilisé sugarconv comme toi mais vers de l'ipf en sortie et ça me donne pas du tout ça en sortie :

Diskview de l'image IPF SPS
Image


Diskview de l'image IPF convertie depuis le DSK original pris sur cpc-p0wer au format edsk/dsk
Image

On peu voir qu'en sortie via le 'diskview', le code de lone semble sans sortir vraiment pas mal.
Par contre, si tu regardes au niveau interne des données... là, c'est pas top du tout.
Plus de détail ici

http://sasfepu78.fr/cgi-bin/IPFanalyse.cgi?Black_Tiger_SugarCon_From_BlackTiger_UK_Original_Dsk
http://sasfepu78.fr/cgi-bin/IPFanalyse.cgi?Black_Tiger_SPS

Je pense que la moulinette de shugarbox vers le format RAW est encore plus imparfaite que la sortie vers l'IPF :?
Page 11 sur 14 Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/