CPC Rulez :: Consulter le sujet

@fred : juste renommer l'ipf, tout un chacun pourrais faire l'inverse donc aucun intérêt je suis d'accord avec lone

1/ Si un nouveau format émerge, je le supporterais. A la fois via mon avis sur les specs - si celui-ci importe, et via son intégration. Ca n'est pas ce que j'appelle être fermé sur un sujet

Je donne juste mon avis sur ses chances de succès !

2/ Pour aider les webmaster à savoir si un IPF est valide ou non, on peut faire des outils. Je peux faire ces outils, s'ils sont nécessaires (et que personne ne les fait). Reste à savoir si ça intéresse quelqu'un. Pour le reste, je ne donne autorité à personne, mais je te dis ce qu'il en est : D'expérience, si je veux un dump fonctionnel, je vais sur cpcpower, parce que je leur fait confiance. Tout est basé là dessus. Tu fais confiance à la de la même manière pour savoir que tel dumps, avec tel CRC et tel ID, est bien issu d'un original.
Par ailleurs, "Vérifier les IPF" signifie surtout "Vérifier qu'ils sont tamponnés par le SPS". Pour rappel, la lib de la SPS lit correctement mes fichiers IPF.

3/ Important : IPF et préservation ne devraient pas être associés. Tu ne préserves pas en convertissant en IPF. Convertir, c'est modifier. Préserver, c'est conserver les dumps de plus bas niveau possible (SCP ou Kryoflux, rien d'autre). Jeter ces dumps et conserver uniquement les IPF serait une grave erreur de ce point de vue là.

perso l'ipf me convient pour deux raisons. la première est la possibilité de refaire une disquette telle que l'originale (a savoir que l'on peut aussi ecrite le flux raw directement sans avoir besoin d'un ipf); sur ce point, la sps boude trop le cpc et n'intègre pas assez vite nos protections (latis par exemple, a savoir qu'un ipf cree avec l'outil de thomas fonctionne sur un vrai cpc après écriture sur une disquette 3"). la seconde, cela permettrais surtout d'avoir un format universel commun a tous nos chers sasfepus. bien sur en prenant soin de bien remplir les infos permettant de différencier tel ou tel micro.

Cela ressemble à la discution sur le format edsk...

Format mauvais d'après beaucoup mais pourtant aucune protection ne semble pas possible à y faire entrer

Ton analyse des infos trouvées dans un ipf et dans le raw face à un ipf génère à partir d'un edsk ... n'oublie pas que çe n'est qu'une représentation graphique faisant suite à une interprétation des données lues en entrées, donc sujet également à discution

Je trouves personellement que lone fait avancer les choses, comme toi j'ai mis à dispo à la sps des dumps CPC il y a quelques années et je n'ai toujours rien reçu d'officiel (protection toujours pas supportée)

La denis fait bien son boulot et heureusement sinon point d'ipf sur CPC :downnn:

J'ai loupé quelque chose puisque tu parles d'ipfs officiels donc avec numérotation :-|

un lien ?

Ce que tu dis est juste, cependant..... comme le disait si bien Giants au dessus, et il a tout à fait raison dans son raisonnement, c'est que comme un fichier eDSK n'est qu'une approximation fonctionnelle d'une disquette originale passée par la boite noire qu'est le FDC du CPC, on a plus du coup les données originelles à 100%. On approche, on simule, mais on est pas sur du rigoureusement exact par rapport à un original. Alors qu'avec un IPF, on y est rien ne manque, c'est carré et conforme à la disquette originale.

@Giants : Ne reparlons pas de l'usage de l'IPF, chacun son avis (son dogme serais-je tenté de dire). Parlons du sujet, qui est l'outil de conversion que je propose.

En reprenant les messages au dessus, tu parles de conversions qui sont mal traitées.

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.

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

Est-ce lié à cela ? En résumé, peut-être peux tu me dire :

- Quel dumps est fautif ?
- Sur quel outil ?

Merci d'avance

Auteur :	Fredouille [ 12 Jan 2017, 15:19 ]
Sujet du message :	Re: SugarConvDsk
breiztiger a écrit : @fred : juste renommer l'ipf, tout un chacun pourrais faire l'inverse donc aucun intérêt je suis d'accord avec lone La seule différence, c'est que ce sera une action manuelle et délibérée de renommer le fichier que générera l'outil. L'outil de Thomas ne sera plus en cause. De plus, les IPFs de Thomas ne contiennent pas les mêmes infos que ceux de la SPS, même en utilisant le même format.

Auteur :	dlfrsilver [ 12 Jan 2017, 15:46 ]
Sujet du message :	Re: SugarConvDsk
Citer : 1/ Si un nouveau format émerge, je le supporterais. A la fois via mon avis sur les specs - si celui-ci importe, et via son intégration. Ca n'est pas ce que j'appelle être fermé sur un sujet Je donne juste mon avis sur ses chances de succès ! 2/ Pour aider les webmaster à savoir si un IPF est valide ou non, on peut faire des outils. Je peux faire ces outils, s'ils sont nécessaires (et que personne ne les fait). Reste à savoir si ça intéresse quelqu'un. Pour le reste, je ne donne autorité à personne, mais je te dis ce qu'il en est : D'expérience, si je veux un dump fonctionnel, je vais sur cpcpower, parce que je leur fait confiance. Tout est basé là dessus. Tu fais confiance à la de la même manière pour savoir que tel dumps, avec tel CRC et tel ID, est bien issu d'un original. Par ailleurs, "Vérifier les IPF" signifie surtout "Vérifier qu'ils sont tamponnés par le SPS". Pour rappel, la lib de la SPS lit correctement mes fichiers IPF. En fait j'aimerais que tu m'expliques quel est ton but. Est-ce que tu cherches à mettre en boule celui qui a crée le système ? Quand je lis ce que tu écris, on a l'impression que tu cherches le cease and desist. Le système IPF a été crée par une seule personne, et ce système lui appartient. Si tu as eu accès aux sources de la lib, c'était uniquement dans le but d'aider les développeurs d'émulateur. Mais maintenant, si tu cherches à le spolier, il se retournera contre toi. Citer : 3/ Important : IPF et préservation ne devraient pas être associés. Tu ne préserves pas en convertissant en IPF. Convertir, c'est modifier. Préserver, c'est conserver les dumps de plus bas niveau possible (SCP ou Kryoflux, rien d'autre). Jeter ces dumps et conserver uniquement les IPF serait une grave erreur de ce point de vue là. STOP. IPF et préservation SONT associés, et ceci depuis le début, et ça a toujours été comme ça, et ça le restera. Le format IPF est le format de préservation et le seul qui existe actuellement, c'est malheureux mais c'est comme ça. Quand on génère un IPF, on ne modifie rien, on prend l'existant, on enlève toute la crasse inutile de la lecture au ras du disque magnétique de la disquette commerciale, et on regénère un master identique à celui crée par l'opérateur de duplication, qui permettra un tracage des données en mode piste (jamais en mode secteur !). Les dumps brut kryoflux sont gros, remplis de saletés et d'erreurs, car tirés de disquettes agées de 30 ans, lues par des lecteurs vieillissants. Leur seule utilité est de permettre la génération de masters, mais on ne peut pas les utiliser car ils sont beaucoup trop gros, et imparfaits à cause des erreurs qu'ils contiennent. La préservation dans le sens musée et bibliothèque du terme implique un assainissement/dépoussiérage/sortie de gangue. C'est comme quand un plongeur remonte un objet du fond de la mer, quand on est professionnel et qu'on fait le travail correctement, on ne met pas directement l'objet en vitrine dans un musée. Il faut sortir l'objet de sa gangue de crasse, le protéger avec des produits spécifiques, afin d'avoir quelque chose de beau à présenter au public. Ici pour les vieux logiciels, c'est la même méthode, on met pas sur le net des dumps Kryoflux sales et super gros de logiciels lus au ras du métal. On est pas des crasseux, et on bosse correctement, on fournit un fichier final de qualité, nettoyé de ses impuretés. Ce fichier final c'est un fichier master IPF, avec une description intégrale du format. Pour les fichiers SCP, ceux-ci sont des copies dont le signal enregistré est modifié car digitalisé (je précise, le signal présent sur les disquettes, c'est un signal analogique). Problème : en cas d'erreur, impossible de voir cette dernière. Avec un dump kryoflux, quand il y a une erreur, cette dernière est visible, on voit parfaitement à quel endroit le signal est abimé ou déformé. Les dumps Kryoflux lourd sont une base de travail, de plus, les auteurs des logiciels voir les ayants droits sont beaucoup plus virulents concernant ces derniers. Autant les fichiers eDSK sont de vulgaires copies secteur (dont ils se foutent), autant mettre en ligne un dump entier permettant de générer un master définitif pose problème. C'est comme avoir les moules pour imprimer des billets de banques. Voler des billets de banque c'est déjà un problème, mais avoir de quoi les imprimer c'est un crime encore plus grave. Juste pour information, par exemple, quiconque demande à Activision ou Capcom par exemple l'autorisation de mettre en ligne leur jeux CPC, se voit refoulé par leurs services juridiques. C'est pas pour rien que SPS se protège en ne mettant pas les fichiers en ligne eux-même. Sinon ça serait un balai incessant d'avocats. C'est pour ça que c'est aux contributeurs de mettre en dispo s'ils le souhaitent leurs IPFs numérotés. Jamais ces entreprises n'iront poursuivre un particulier pour ça. SPS étant une organisation à but non lucratif (y a pas de salariés, on est pas payé), tandis que la carte kryoflux est vendue par une petite entreprise qui n'a rien à voir juridiquement parlant avec SPS. La licence très onéreuse de l'application d'analyse se paie directement à son créateur, ça ne passe pas par l'organisation de préservation. Citer : perso l'ipf me convient pour deux raisons. la première est la possibilité de refaire une disquette telle que l'originale (a savoir que l'on peut aussi ecrite le flux raw directement sans avoir besoin d'un ipf); sur ce point, la sps boude trop le cpc et n'intègre pas assez vite nos protections (latis par exemple, a savoir qu'un ipf cree avec l'outil de thomas fonctionne sur un vrai cpc après écriture sur une disquette 3"). la seconde, cela permettrais surtout d'avoir un format universel commun a tous nos chers sasfepus. bien sur en prenant soin de bien remplir les infos permettant de différencier tel ou tel micro. Ce qui m'embête avec l'écriture d'un dump KF raw, c'est que les erreurs possibles qui se trouvent dedans peuvent se retrouver écrites sur la disquette cible. C'est pour ça qu'à titre personnel je ne le fais pas. Sache que la SPS ne boude pas le CPC, j'ai même un collègue finlandais, Rakki, qui dumpe du CPC lui aussi. Beaucoup de protections CPC non supportées sont génériques. Le jour ou la KBI-10 Weak sector CA sera supportée, j'aurais 150 jeux à passer en IPF et ainsi de suite Après, je tanne aussi mes collègues, vous vous souvenez, j'ai fais une promesse, j'ai dis que les IPFs officiels CPC seraient distribués, et ils l'ont été. J'ai tenu ma parole ! Je viens régulièrement aux nouvelles pour savoir ou en est la programmation de SPS studio. Il faut comprendre qu'un logiciel de qualité professionnelle et industrielle prend du temps à programmer. C'est comme l'outil de nouvelle génération de création de fichiers CDT pour les jeux cassettes, je m'excuse de ma part et de celle de César, mais le nouvel outil appelé CSW2CDT doit être le plus parfait possible à sa sortie, avec le moins de bugs possibles. Comme ce dernier va remplacer définitivement SAMP2CDT, et toute la clique de logiciels buggés et pourris qu'on se traine depuis plus de 10 ans, il devra faire la différence. Samp2cdt calcule au petit bonheur la chance les constantes utilisées par les cassettes, et les outils de réversion génère des fichiers WAV qui dans bon nombre de cas ne fonctionnent pas. j'assiste César pour que son utilisation soit perçue comme vraiment super, et que les fichiers en sortie soient niquel. dernièrement, nous avons implémenté l'encodage des cassettes Bleepload v2 musical, avec comme premier logiciel passé Druid de Firebird. Le cdt résultant fait 730ko. C'est gros, mais la protection et le système musical particulier est intégré exactement comme sur la cassette originale. Actuellement, nous travaillions sur le système d'encodage hexagon cassette utilisé sur les jeux U.S.Gold et Rainbow Arts. le système parait simple en apparence, tout en étant complexe en interne (le CRC est interne sur les blocs, et codé sur 16 bits et encrypté). J'espère que César pourra rapidement fournir une version stable et fonctionnelle en ce début d'année. Je ferais un tuto complet pour l'utiliser au mieux.

Auteur :	Lone [ 12 Jan 2017, 21:11 ]
Sujet du message :	Re: SugarConvDsk
C'est trop long denis... Après, ne te plains pas si on ne lis pas tout. 1/ Je ne vois pas en quoi je peux énerver le créateur du format ? Je propose juste des outils pour l'utiliser. Le format est documenté, les sources sont dispo, nul mention nul part d'interdiction de générer ce format... S'il s'agit bien d'une organisation à but non lucratif, qui plus est, je ne vois pas pourquoi on parle d'avocat. 2/ Ipf et la préservation. La question à se poser est la suivante : Les IPF sont-il suffisant pour la préservation ? La question peut être formulée ainsi : Si l'on a un IPF, peut-on jeter les dumps SCP et Kryoflux ? Si la réponse est oui, alors l'IPF est suffisant pour la préservation. Si la réponse est non, alors l'IPF n'est pas suffisant. 3/ Ton histoire d'amphore est bien belle... Mais je trouve que la comparaison irait mieux avec, admettons, un vieux manuscrit. Le vieux manuscrit, c'est la disquette 3". Le dump kryoflux, c'est une photocopie couleur de super qualité, hyper précise. L'IPF, c'est la même photocopie, mais retouchée (pour remettre des lettres, scotcher les pages déchirés, etc). Utile pour utiliser le document, mais avec moins de valeur que la photocopie originale, et encore moins que la disquette si l'on souhaite faire des recherches dessus. Nul besoin d'expliquer pourquoi garder la disquette, ou au pire la photocopie est plus utile pour des travaux d'analyse (au delà du texte) que l'image retouchée.

Auteur :	Giants [ 12 Jan 2017, 21:29 ]
Sujet du message :	Re: SugarConvDsk
>...Pour rappel, la lib de la SPS lit correctement mes fichiers IPF. 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). >..Important : IPF et préservation ne devraient pas être associé. Je t'invite à aller sur le site et a lire, t'informer du pourquoi de la création de CAPS à l'époque, là je fatigue. Tu ne peux arriver comme ça avec tes gros sabot et remettre en cause tout ça. Donc IPF=master sur toute les plateforme dumpé par SPS MAIS... pas sur le CPC car Lone l'a décidé ! Lone qui n'est pas de SPS mais qui le décide quand même. Non seulement tu as ta propre définition de master mais maintenant tu as ta propre définition de préservation, décidément, tu doute de rien... OK, que veux tu que je te dise ?! Ok ? Fait ce que tu veux, comme dab, après tout... > ...Le format est documenté, les sources sont dispo Tu voie et lie/écoute vraiment ce que tu veux, hallucinant... Donne nous un lien officiel de SPS ou le format est documenté s'il te plaît. >...Convertir, c'est modifier. Préserver, c'est conserver les dumps de plus bas niveau possible (SCP ou Kryoflux, rien d'autre). Tu vas dans l’extrême, je vais faire bêtement de même alors. En partant de ce principe même, un dump flux n'est aussi pas une préservation... Dump une disquette en flux 3 fois, tu n'auras jamais les mêmes infos au bit prêt dans le flux (je parle SANS le décoder, Brut de pomme). Je sais pertinemment que c'est vrai mais pas pertinent ce que je vient de dire, mais.. j'utilise ta même logique stupide sur ce sujet. Une vrai préservation serait le media Originel utilisé par le traceur d'époque et cela en bon état. (bonne chance) >Fredouille Non, c'est pas si simple. Pour vivre un format doit apporter quelque chose qui le différencie des autres. Mais ce n'est pas ce qui manque dans la problématique, ce qui manque c'est l'envie, nuance. >breiztiger Un flux n'est pas vraiment un format, c'est... du flux. Faire une bibliothèque de préservation avec des fichiers flux...c'est utopique. Dans le meilleur des mondes oui je suis d'accord et encore, vue l'état des disquettes et des parasites que l'on as au dump... Je garde les wav car les outils actuel ne suffisent pas encore de les traiter correctement tout le temps. Je veux pouvoir dans le future, si un nouvel outil ou format sort, utiliser ces wav en entrée. Mais oui, je fait la même chose avec mes dumps disquette, je garde les flux juste pour le 'cas ou'. Après, rien que pour du flux c'est quand même quelque chose, d'où le format Ipf qui fait la liaison. Et puis y'a tout et rien dans le flux, même des trucs qui n'ont rien a y faire. >perso l'ipf me convient pour deux raisons... Je ne suis pas sur que ce soit l'IPF qui te conviennent mais plutôt ce qu'il transporte non ? Toute les infos que tu juges pertinente ! Que ce soit l'IPF ou autre format pour toi, je pense ne pose pas de soucis tant que tu as toutes ces infos. Je ne pense pas que lone soit dans cette optique. Mais pour les 'ipf de 'lone', après tout... pourquoi pas ?! Dans ce cas, il faudrait entrer en relation avec SPS et leur proposer une nouvelle entrée dans le champs 'ENCODER' du header par exemple chose qui permettrait de différencier très facilement ses ipf ! As t'il ne serais qu'essayer un compromis avec SPS ? La j'avoue, je ne comprends pas ce qu'il cherche à faire. SPS à, comme beaucoup de société la problématique des 'ressources'. Ils ne sont pas des centaines à valider/travailler sur ça, je ne leur cherche pas d'excuse mais, c'est un fait. Perso, je leur ai envoyé plusieurs dumps sur Amiga via leur ftp et j'ai eu une réponse 1 ou 2 ans après. OUI, ce n'est pas normal mais que peu t'on y faire ?! La seul solution ai de travailler sur un projet identique comme vous faite ?! Mais pas avec le même format. Que veux tu que je te dise...je ne vais pas prendre leur défense sur le cpc. D'une je n'ai aucune raison de faire ça, j'ai d'une pas assez d'info et de deux, je me veux neutre. Oui, ça avance pas assez vite, je suis d'accord mais c'est plus un autre sujet. Ceci dit ça n'avancera pas plus vite avec l'outils de Lone, il faudrait un routine de vérification. (bonne chance vue les entrées possible du soft en question).

Auteur :	Giants [ 12 Jan 2017, 21:34 ]
Sujet du message :	Re: SugarConvDsk
Prenons un exemple concret : On prends un jeux IPF déja dumper et 'distribué' par SPS en IPF. On est pas tous des ingénieurs mais on sais regardé un écran. On prends l'outils de jeff, on charge l'image IPF et on génère une image bitmap que l'on sauve : jeu_sps_ipf.bmp On prends maintenant sur cpc-p0wer, l'image de dump dit 'original' mais au format dsk on prends ton superbe outils, on crée une image ipf et on la sauve : jeu_dsk_vers_ipf.bmp On devrait avoir la même image en sortie que l'image IPF de SPS ?! Bein non... Est ce que la protection est dans l'image ipf de SPS : Oui Est ce que la protection est dans l'image ipf créer par ton soft : Oui Maintenant on prends les fichiers flux, utilisé pour créer l'image ipf de SPS et on génére une image via le soft de jeff On tombe (comme c'est bizare) sur la MEME image que celle préalablement créer avec l'image IPF de SPS PAS, celle créer avec ta moulinette de dsk vers ipf. Ca, n'importe qui peu le tester et voir que clairement le probleme. Pas besoin d'être dev ou d'avoir des compétences. Ce que ton soft génére à partir de dsk... je ne sais pas ce que sais mais je sais ce que ca n'est pas. Ca n'est pas un fichier master. Je ne voie aucun intérêt dans ton outils a y avoir intégrer les fichiers dsk et edsk en entrée. à part faire des images ipf 'Supposé', 'reconstitué', 'déduite'. Désolé de te le dire mais, ta moulinette de 'déduction'... elle ne sert à rien car aussi puissante soit elle (c'est un fait), elle fait de la déduction. Qu'es ce que viens faire de la déduction dans une image IPF ???? C'est du grand n'importe quoi. Intégrer dans un emulateur, Ok, pourquoi pas. La proposer en libre service pour faire des IPF a à partir de n'importe quel source dsk c'est du grand n'importe quoi. La proposer en libre service pour faire des IPF à partir de flux, la... je dit pas, je prends, je voudrais juste qu'en sortie quelque chose fasse que je puisse la distingué d'un DUMP sps très rapidement et sans le crc. En faite, tu dit ne pas être têtue mais perso, j’arrête pas d'essayer de proposer des solutions alternatives qui, au passage, peuvent ne pas plaire a SPS mais à chaque fois, tu contres tout. Tu lies, mais tu reste bloqué sur tes positions et raisonnement que seul toi tiens. Regarde dans le dico la définition de têtue.

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

SugarConvDsk https://cpcrulez.fr/forum/viewtopic.php?f=8&t=5844	Page 10 sur 14

Auteur :	breiztiger [ 12 Jan 2017, 22:35 ]
Sujet du message :	Re: SugarConvDsk
Cela ressemble à la discution sur le format edsk... Format mauvais d'après beaucoup mais pourtant aucune protection ne semble pas possible à y faire entrer Ton analyse des infos trouvées dans un ipf et dans le raw face à un ipf génère à partir d'un edsk ... n'oublie pas que çe n'est qu'une représentation graphique faisant suite à une interprétation des données lues en entrées, donc sujet également à discution Je trouves personellement que lone fait avancer les choses, comme toi j'ai mis à dispo à la sps des dumps CPC il y a quelques années et je n'ai toujours rien reçu d'officiel (protection toujours pas supportée) , la denis fait bien son boulot et heureusement sinon point d'ipf sur CPC J'ai loupé quelque chose puisque tu parles d'ipfs officiels donc avec numérotation un lien ?

Auteur :	dlfrsilver [ 12 Jan 2017, 23:12 ]
Sujet du message :	Re: SugarConvDsk
breiztiger a écrit : Cela ressemble à la discution sur le format edsk... C'est certain. Citer : Format mauvais d'après beaucoup mais pourtant aucune protection ne semble pas possible à y faire entrer Mauvais n'est pas le bon terme. Le format n'est pas assez poussé, et il a une limite : il a été conçu pour stocker le niveau d'information traitée et recraché par le FDC du CPC. Hors, comme je l'ai expliqué, ce dernier ne voit pas les données telles qu'elles sont écrites, il les voit à sa manière. C'est pour cette raison que le FDC du CPC ou du PC ne peuvent pas être utilisés pour la préservation. On est obligé de passer soit par un Amiga, soit par une carte contrôleur dotée d'un FDC propriétaire comme la carte kryoflux pour vraiment lire les données comme elles sont écrites sur disquette. Le format eDSK est un format FDC en fait, c'est à dire sectoriel. C'est une approximation en terme de données, celles-ci ne sont pas stockées et représentées comme elles le seraient sur un original. Citer : Ton analyse des infos trouvées dans un ipf et dans le raw face à un ipf génère à partir d'un edsk ... n'oublie pas que çe n'est qu'une représentation graphique faisant suite à une interprétation des données lues en entrées, donc sujet également à discution Ce que tu dis est juste, cependant..... comme le disait si bien Giants au dessus, et il a tout à fait raison dans son raisonnement, c'est que comme un fichier eDSK n'est qu'une approximation fonctionnelle d'une disquette originale passée par la boite noire qu'est le FDC du CPC, on a plus du coup les données originelles à 100%. On approche, on simule, mais on est pas sur du rigoureusement exact par rapport à un original. Alors qu'avec un IPF, on y est rien ne manque, c'est carré et conforme à la disquette originale. Citer : Je trouves personellement que lone fait avancer les choses, comme toi j'ai mis à dispo à la sps des dumps CPC il y a quelques années et je n'ai toujours rien reçu d'officiel (protection toujours pas supportée) C'est vrai, j'ai une énorme quantité de dump en attente à cause de ça. Thomas en ajoutant le support des IPFs a bien fait avancer les choses Citer : La denis fait bien son boulot et heureusement sinon point d'ipf sur CPC Je fais comme au boulot, le maximum pour le meilleur des résultats. Partout ou je peux pousser les leviers je le fais. Maintenant voilà, le créateur ayant un boulot à temps complet chez Sony, mais aussi une femme et des gosses, c'est pas aisé de coder le soir (et la fatigue....) Donc je patiente. Le plus important, c'est d'avoir de bon dump, avant que les disquettes ne soient toutes mortes d'ici pas très longtemps. on pourra alors générer et traiter tranquillement les logiciels. Citer : J'ai loupé quelque chose puisque tu parles d'ipfs officiels donc avec numérotation un lien ? cpc-p0wer possède tout les IPFs officiels que j'ai remis à Loic Daneels. Pour information, j'ai l'accès à l'intégralité du catalogue des IPFs numérotés pour Amiga, ST, CPC. quiconque me demande un IPF s'il a fourni un dump l'aura, il suffit simplement de me contacter. Actuellement, je suis pas moins de 10 contributeurs différents, anglais, français, espagnols, australiens. Et je précise qu'à côté je suis auto-entrepreneur (chef d'entreprise), je travaille aussi comme technicien support VIP ++ pour la 2nde boite du CAC 40, et je trouve encore de l'énergie pour faire ça La passion je pense....

Auteur :	Megachur [ 13 Jan 2017, 07:43 ]
Sujet du message :	Re: SugarConvDsk
@giants; je peux pas répondre à ton MP car tu as desactivé qu'on puisse t'en envoyer...sinon MP moi ton mail !

Auteur :	JMD [ 13 Jan 2017, 08:41 ]
Sujet du message :	Re: SugarConvDsk
Hello, Je me permets juste une petite remarque dans ce flot plus que fournit … Je me dis qu’au-delà des quelques parties anecdotiques non supportés par l’IPF, un nouveau format pourrait être moderne et adapté aux besoins de l’émulation, plus que ceux de la préservation (que la SPS semble s’être approprié …). Je m’explique, la grande majorité des personnes utilisant des émulateurs et les images disque le font pour jouer et/ou par nostalgie. Plus ça va aller, plus ce sera le cas et du coup, un nouveau format pourrait aller dans ce sens et aider les émulateurs à amener ceci. Ainsi, en plus des problématiques purement techniques, devrait proposer des infos au niveau « au dessus » : comment lancer le jeu, pourquoi pas des surcouches « de patchs » telle que vie infinie ou autre, voir même remappage des touches pour jouer avec manette. On pourrait y inclure des meta data dans le genre de ceux présents sur cpc-p0wer ou CPC Rulez (titre, année, éditeur, dev, version, cover, manuel, origine du dump …), gérer le multidisk … Les images prendraient un peu de poids mais rien de significatif pour un ordinateur moderne. La partie technique pourrait alors être un simili IPF et les metadata feraient la différence. Si des gros sites adoptent ce format, je pense qu’il prendra rapidement le pas sur des edsk et des IPF, préservation ou non car simplement plus convivial pour le casual. JM

Auteur :	Giants [ 13 Jan 2017, 09:15 ]
Sujet du message :	Re: SugarConvDsk
On met un peu de couleur >...Ton analyse des infos trouvées dans un ipf et dans le raw face à un ipf génère à partir d'un edsk ... n'oublie pas que çe n'est qu'une représentation graphique faisant suite à une interprétation des données lues en entrées, donc sujet également à discutions. C'est le but, c'est la problématique. Un dsk ou edsk n'a rien a faire en entrée pour créer un ipf en sortie ! Denis, au vue de sa réponse au dessus, à compris de quoi je voulais parlé, je le reprends et te souligne ce qui est important à bien comprendre de la problématique. => Citer : Ce que tu dis est juste, cependant..... comme le disait si bien Giants au dessus, et il a tout à fait raison dans son raisonnement, c'est que comme un fichier eDSK n'est qu'une approximation fonctionnelle d'une disquette originale passée par la boite noire qu'est le FDC du CPC, on a plus du coup les données originelles à 100%. On approche, on simule, mais on est pas sur du rigoureusement exact par rapport à un original. Alors qu'avec un IPF, on y est rien ne manque, c'est carré et conforme à la disquette originale. >...n'est qu'une représentation graphique faisant suite à une interprétation des données lues en entrées, donc sujet également à discutions. Maintenant on va remettre la représentation graphique d'aufit et hxc en doute... Alllllerrr, du grand n'importe quoi. Une représentation graphique est ce qu'elle est rien de plus, elle n'a va vocation à être parfaite mais à donner une idée du contenue d'une image. SI, tu fait le test que j'ai dit, tu pourra voir de toi même que les images final n'ont tout simplement AUCUN rapport. Et pourtant... l'image dsk/edsk utilisée en entrée est 'censé' être un dump original de la même disquette. (dump original en dsk/edsk... -_-' c'est un non sens...). Je pense que tu devrais avoir ce genre de discutions, à savoir 'remettre en cause la représentation graphique' avec Jeff pour le soft de Hxc et DrCoolZic pour aufit. Je suis sur qu'il apprécierons à ça juste valeur tes remarques sur ce sujet. La représentation graphique se base sur le contenue de ce qu'elle analyse, elle n'invente pas des données. Un dump Flux représenté en graphique par Aufit aura la même tête que le même flux représenté par HxcSoft. Il aura aussi la même tête si tu code toi même un soft de représentation graphique par rapport au contenue en question. La 'problématique' en question que l'on voie dans la 'représentation graphique' est tout aussi visible techniquement à l'étude de l'image disk. Seulement, à moins d'être technique, ça va pas spécialement être parlant à tous, alors qu'une représentation graphique de la disquette est parlante pour TOUS LE MONDE. D'où mon exemple. Tu sembles ne pas avoir bien compris la problématique dont je parle et qui est gênante, je la répète : Avoir une entrée dsk ou edsk pour sortir vers un format ipf est un non-sens. Avec le dsk ou edsk, tu as une approximation en entrée et bien, tu aura une approximation en sortie. (peu importe le code utilisé aussi bon soit t'il, et il l'es). Cela reste de l’interprétation de donnée et n'a rien à faire dans de l'IPF On ne change pas le plomb en or, on le rends plus jolie, on peu le peindre, le faire ressembler à de l'or mais au final, ce n'en ai tjs pas. Tu aura beau mettre le contenue d'un VCD sur DVD, même avec un traitement d’amélioration des données, ça ne te fera pas un DVD Tu peux prendre une pomme, la découper pour qu'elle ressemble à une poire, ça reste une pomme. Je peux te donner plein d'exemple.... tant qu'il y aura 'déduction', ça restera de l'approximation. Le format dsk et edsk n'est pas le sujet, n'est pas la problématique. Il à juste rien à faire en entrée de ce soft, aussi simple que ça. On peu régler cette problématique par différentes solutions, j’arrête pas d'en proposer... Un nouveau format en sortie serait une très bonne alternative, c'est un exemple. Lone voie, je pense, voie l'IPF comme juste un format. Un format comme les autres, qui contient toutes les infos qui lui semble intéressante pour un dump le plus proche du réel. Je suis d'accord, c'est le cas... mais ce n'est pas QUE ça. Si je prends la def faite par leur créateur : IPF : Interchangeable Preservation Format IPF stands for Interchangeable Preservation Format, and is the file format we use to preserve content, that is, floppy disk images..... Tu 'preserve' quoi avec un ipf crée à partir d'un edk/dsk ??? Tu préserves la déduction créer par le code, c'est tout. C'est je pense le point majeur de discorde il me semble et du coup, tout ce qui en découle. Il aurait mieux fallu que la team SPS mette clairement un copyright sur ce format, cela aurait réglé des le départ la problématique. C'est dommage.

Auteur :	Lone [ 13 Jan 2017, 10:36 ]
Sujet du message :	Re: SugarConvDsk
@Giants : peux tu nous mettre une capture d'écran de tes images générées (qu'on ait une base de discussion) ? @Jmd : Je trouve ton idée très intéressante. Ca demandera sans doute pas mal de réflexion pour trouver comment mettre ça en place, mais c'est effectivement une idée à creuser.

Auteur :	breiztiger [ 13 Jan 2017, 11:34 ]
Sujet du message :	Re: SugarConvDsk
pour quelqu'un d'ouvert et qui reproche aux autres d'etre obtus, tu restes bien campé sur tes positions également tu "interpretes" également ce que j'ai pu ecrire ... je rappelle quand meme que dans l'ipf toutes les infos en tant que donnees n'y sont pas, juste scriptée (weak sector par exemple), m'enfin ... comme tu vas finir par me dire je n'y comprends rien, je retourne a mon ignorance ps ; la discution sur un nouveau format, rien de nouveau, grand debat a une reset il y a de cela quelques annees avec certains, comme offset par exemple

Auteur :	Giants [ 13 Jan 2017, 11:41 ]
Sujet du message :	Re: SugarConvDsk
lone : Il y a 1 an oui, aujourd'hui non ! Comme déjà dit par email, je ne participe plus techniquement. Tu as déjà toutes les infos nécessaires pour ré-creer de toi même ces image graphique. Maintenant, je donne mon avis, mon points de vues et travailles de mon coté. Libre à toi de tenir compte de mes remarques, de faire la mini-procédure que j'ai indiqué... ou pas. Je pense de mon coté avoir fait le tour de la problématique et avoir exprimé mes craintes sur cet outils dans l'état actuel de ce qu'il permet de faire à base de dsk/edsk vers de l'ipf. Pour moi, de mon coté, le sujet est clos car je ne voie rien de plus à apporter, je n'ai aucune valeur ajouté. La balle est de ton coté avec la création ou pas d'un nouveau format. C'est le moment ou jamais. breiztiger : Scriptée dans l'ipf... scripté, dans l'ipf..No comment. -_-' Pas de temps à perdre à te répondre et je n'ai pas envie de débattre avec toi sur des sujets techniques pour des raisons qui me sont propre. Mes remarques étaient destinées à Lone et que car c'est le créateur de ce soft et aux autres dev qui sont dans l'idée de la création d'un nouveau format. En gros, pour faire avancer le chmiblique et voir aboutir la création d'un nouveau format. Tous autres avis en tant qu'utilisateur d'emulateur est bien sur le bien venu sur l'utilisation des IPF. (officiel ou pas)

Auteur :	Lone [ 13 Jan 2017, 13:46 ]
Sujet du message :	Re: SugarConvDsk
@breiztiger : Etait-ce à l'époque ou l'on parlait de SFWR ou est-ce encore plus vieux (auquel cas, ça deviendrait un marronier du cpc !). On pourrait toujours ouvrir à nouveau le sujet... Mais il faudrait quelqu'un qui y croit, ait la motivation et du temps pour ça ! @Giants : Ne reparlons pas de l'usage de l'IPF, chacun son avis (son dogme serais-je tenté de dire). Parlons du sujet, qui est l'outil de conversion que je propose. En reprenant les messages au dessus, tu parles de conversions qui sont mal traitées. 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. J'en déduis que le problème vient d'une partie du format lui-même, à priori incorrect ? 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 librairie officielle de la SPS (version 5.1) gère bien sur correctement cet aspect : Dans tous mes développements, elle a été mon juge de paix pour savoir ce qui était correct de ce qui ne l'était pas. Est-ce lié à cela ? En résumé, peut-être peux tu me dire : - Quel dumps est fautif ? - Sur quel outil ? Merci d'avance

Page 10 sur 14	Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Auteur :	dlfrsilver [ 13 Jan 2017, 14:53 ]
Sujet du message :	Re: SugarConvDsk
Giants : Breitztiger a raison, les ipfs contiennent les informations scriptées effectivement, nécessaires à l'écriture via le controlleur FDC programmable de la carte kryoflux. Citer : @Giants : Ne reparlons pas de l'usage de l'IPF, chacun son avis (son dogme serais-je tenté de dire). Parlons du sujet, qui est l'outil de conversion que je propose. Il n'est pas question de dogme, mais d'exactitude technique. J'ai déjà expliqué 1 million de fois qu'on ne pouvait pas faire de préservation en captant les données écrites sur un disque CPC, ST ou PC, avec un contrôleur de disque Nec Upd765 ou WD1772. Pour préserver les disquettes de ces machines, on est obligé de passer par des controleurs de disque plus puissants comme celui de l'amiga ou de la carte kryoflux qui ne modifient pas les données lues. Et toi Thomas, t'es encore en train de nous parler de dogme, alors que le seul problème est que tu penses avoir une opinion sur le sujet, quand d'un point de vue technique tu te trompes et tu as tort. 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. 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. Rappel : un IPF ne peut contenir que des données originales et non modifiées ne provenant d'un passage à la moulinette ou d'un format lié au format esclave du FDC du CPC. On ne peut pas préserver un logiciel en lisant les données via le FDC du CPC, ou utilisant comme source un format secteur conçu pour le FDC. Les données étant forcément de par le fonctionnement de cette puce modifiées. modifiées = pas d'IPF. 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. C'est aussi logique que de dire que le soleil est dans le ciel et que la pluie ça mouille. Et c'est ce que les graphiques de giants montrent, et c'est ce qu'il a voulu t'expliquer. 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 me demande ce qui est le pire entre les deux..... Le format eDSK est largement inférieur et de loin au format IPF. Citer : Est-ce lié à cela ? En résumé, peut-être peux tu me dire : - Quel dumps est fautif ? - Sur quel outil ? Merci d'avance Je vais te faire une réponse en ce qui me concerne. J'ai vu dernièrement des dumps (faudra que je retrouve les titres), qui ne fonctionnent pas une fois écrit depuis un IPF sur mon 6128, et qui fonctionnent sur sugarbox...... 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....