Ça semble logique dans le sens où le raw et l'ipf sont des formats non interprétés comme le dsk

Ce qui serait intéressant de savoir, c'est ce que contient le raw en structure de données pour faire planter l'analyseur qui s'occupe de faire un dsk à partir d'un flux

le format eDSK/DSK est un format interprété, car conçu pour stocker en sectoriel.

Ce format ne permet pas la vraie représentation, qui est une représentation "piste" (qu'on trouve dans les KF-raw, CT-raw, et IPF).

_________________
SPS Community Expert (SPS CE) / SPS France

Au temps pour moi, j'avais vraiment très peu testé la génération d'edsk.
Voici une version qui ne plante plus (à priori améliorée, par contre il est probable que les formats trop bizarres ne fonctionnent pas). En outre, les weak sector ne sont pas supportés.

Merci BCP !!! Je vais tester cela !

Pourtant pour le weak sector côté eDSK, il suffit de mettre trois fois les données du secteur à la suite (avec les weakbits générés aléatoirement) et une longueur de 3 x taille du secteur !

Allez, un petit effort

@Lone : Super ça marche impec maintenant -> BRAVO !

C'est dans des specs quelque part ça?

Tu veux dire qu'au lieu de mettre 512 octets pour un secteur taille 2, tu en mets 1536 et l'émulateur doit lire successivement les trois images du secteur?

oui c'est ca,

cela permet de voir qu'on a par exemple des "demi-weak" sur des protections type afterburner (256 octets identiques suivit de 256 octets weaks)

extrait de http://www.cpcwiki.eu/index.php/Format:DSK_disk_image_file_format



et généralement il y a 3 copies du secteur dans un fichier au format eDSK ce qui est suffisant ! je pense que c'est l'outil SamDisk qui le génère comme cela : http://simonowen.com/samdisk/cpc/.

Cependant, d'un point de vue émulation, Lone a prouvé en le codant dans son émulateur Sugarbox que l'ensemble des bits d'un weak sector ne sont pas tous des fuzzybits... il serait plus juste d'identifier les bits qui sont aléatoires plutôt que de faire une simple copie de plusieurs lectures de tout le contenu du même secteur... mais d'un point de vue lecture par le FDC et interprétation par le programme, c'est la même chose et la copy protection est validée et le loader s'exécute sans problème !

dans le format CT Raw par exemple, il y a au moins 5 copie de la même piste, ce qui permet d'identifier aussi les secteurs dont le contenu (ou une partie) est différent à chacune des lectures du même secteur (vu du FDC).

En fait, quand le lecteur de disquette lit les données sur la disquette, il y a une mauvaise transition qui génère des lectures d'une suite de bit qui est aléatoire, voir plus d'info sur cette page : http://info-coach.fr/atari/hardware/FD-Hard.php#writing de DrCoolZic cf section "Detection of Fuzzy "Border" Bits by the WD1772"

d'un autre côté, difficile de faire une émulation parfaite sur ce point car même avec un Kryoflux on a que le résultat de la lecture...on n'a pas le comment est codé vraiment le champs de bit qui génère l'erreur car c'est codé physiquement sur le disc au moment où on a physiquement écrit sur le disc et comme c'est une erreur volontaire, on a que le résultat de la lecteur aléatoire avec les fuzzybits différents ! je te laisse lire pour comprendre cela !

Si on raisonne en bits comme dans les formats RAW, on reste... ...à la précision du bit

Or pour faire un bit aléatoire, il faut apparemment être plus précis (je vais dire une connerie) au 1/10 d'horloge, j'ai un peu l'impression que c'est ce qu'ils racontent sur ton site, de rapprocher les bits au max, au final la lecture va déconner. Mais Offset me parlait d'une méthode encore plus vicelarde où les écritures étaient si proches que le pulse était altéré, et du coup la lecture encore plus!

J'aime bien l'approche de plusieurs lectures. Y a un moment où il faut savoir simplifier.

Après tout, l'émulateur qui simule le refresh RAM n'est toujours pas d'actualité

allez Je vous aide : C'est la machine traceuse qui détermine au moment de l'écrire lors de la réplication l'état des bits en question.

_________________
SPS Community Expert (SPS CE) / SPS France

Quand je pense que tous ces problèmes/questions auraient/pourraient ne pas être d'actualités si, comme on l'avait préconisé il y a pas mal de temps denis et moi,
que les outils de Lone génère un nouveau format ou plus exactement... un fichier avec une extension AUTRE qu'IPF
mais non...

La 'contrainte', check d'un ipf par rapport au fichier xml de SPS pour savoir si le dump est officiel via son CRC ne sera effectuée QUE par les gens soucieux d'avoir ces infos. (dump officiel ou pas).

Les autres utilisateurs s'en ficheront complètement ce qui augmentera encore plus le risque de mélange et distribution sur le net des IPF validées par SPS et des autre IPF générées pas officiellement par sps.

Demain, n'importe qui ouvre un site facilement, prends un domaine avec dump_cpc_ipf ou dump_cpc_originaux ou autre.
Download tous les dsk dispo sur le net et lance en batch avec SugaConvDisk vers de ces dsk vers de l'ipf
et bien sur, met tout ça en ligne en disant les mots qui fâchent : originaux ou ipf
J'aiiiii pas de boule de cristal, mais je pense que ça va arriver... et vite.

Que dire... on l'avait dit ?


Je n'ai pas les mêmes contacts et position que denis par rapport a SPS mais je peux aussi vous valider qu'ils n'aiment pas ça du tout et que oui, des choses de leur coté sont prévue.
Ce qui est assez logique, le contraire aurait d'ailleurs été assez étrange, sps étant ne l'oublions pas, une société.


PS : J'ai bien aimé aussi la maj de l'exe de shugarbox mis ici mais pas sur le zip officiel du site et les problèmes de test liée à ça ensuite !
Ca m'a rappelé une de mes remarques il y a quelque temps sur le même sujet. (dispo sur le forum)

En faite on tourne en rond depuis combien d'années la sur ces problèmes ?

ça c'est certain. J'ai déjà reçu un PM de la part d'un collègue qui voulait savoir si j'étais à l'origine de cette initiative, et pire, si je me servais de l'outil de Thomas pour générer des IPFs.... ça commence....



C'est certain..... Si encore l'outil de thomas permettait uniquement de mouliner des dumps originaux et de faire un minimum d'analyse de formats comme le ferait Disk Analyse de Keir Frazer par exemple, ça serait quand même plus respectable. La l'outil passe même en IPF des DSK, c'est à dire des copies en mode secteur....

Dans l'idéal, et pour ne rien mélanger, il faudrait utiliser une autre extension qu'IPF, comme *.CPC par exemple, qui permettrait de ne pas mélanger les torchons et les serviettes.



ah ça..... c'est sur que ça va faire du mal. à mon avis ça finira par un cease and desist.....



C'est surtout que dans le principe, et même si je peux comprendre le pourquoi du comment de la part de Thomas, qui grince et rage un peu de voir que certaines protections ne sont pas encore supportées, le principal est d'avoir des bons dumps. Hors, même pour les plus rares, on les a. Tant qu'on a des dumps KFraw qui sont 100% bons, on pourra toujours générer d'ici quelques années des IPFs quand le support aura été ajouté (j'espère avant quand même). En attendant, on pourra jouer avec des CTraw et des eDSKs des logiciels en question, et puis c'est pas comme si on pouvait pas mettre un HxC qui supporte les IPFs et les eDSKs en natif non plus

_________________
SPS Community Expert (SPS CE) / SPS France

Je reprends quelques pages avant :

hERMOL > Oui c'est bien beau tout ca , mais alors comment différencier les vrai vrai des vrai faux ??

Lone > Avec le site de la SPS : CRC + numéro du dump.
Sinon, ben c'est le site sur lequel tu vas le download qui va te le garantir (en quelque sorte).
Donc, ça va être ton taff de faire les verifications !
Bon courage !

dlfrsilver > Les vrais sont ceux que je fournis, ainsi que les officiels qui sont numérotés.
C'est simple. Mon identité personnelle est taguée dans tout les IPFs que je génère.


Hermol, bonne comme question, il me semble l'avoir vue et dit... hummm... 50 fois que cela allé poser ce problème !

J'avoue trouver le 'Bon courage !' de lone ironique vue que, ces ipf non valides SPS auront été crée avec l’outil de lone mis à leurs dispositions.

Sans passer par le Crc, il y a encore plus simple, c'est d’interroger via un browser la base de SPS.
Si le jeux n'est pas encore dans la base (dans le fichier xml accessible en ligne), pas besoin d'aller chercher plus loin, il est pas officiel (pas encore 'en court' ou pas du tout 'ipf pas sps').

Quand à la modification de l'identité du dumper via editeur hexa d'un ipf. Aucune Chance, toute modification change le CRC donc, image modifié = nouveau CRC et donc plus dans la base SPS officiel.

Dans la forme actuel de SugarConvDsk donc en date du 9 janvier 2017, il m'est possible de détecter si l'ipf est officiel ou pas et ça, juste avec la structure du fichier (moulinette perso interne).
En faite, l'image générée ne réponds pas EXACTEMENT et TOUT LE TEMPS au critère du format IPF et ce, surtout sur les pistes de fin (pour info).

J'imagine bien sur que SugarConvDsk va évoluer et il sera de plus en plus difficile de détecter sans outils vraiment spécifique un officiel ipf d'un pas officiel ipf (sans passer par le crc j'entends. Juste en analysant au niveau de la structure du fichier généré).

Et ca, c'est bon signe pour SugarConvDsk et pas bon signe pour le merdier que c'est en train de créer.

Ne vous feriez vous pas des nœuds au cerveau pour quelque chose qui n'en vaut pas la peine ?

Entre le fait que le format soit hyper confidentiel, qu'aucun des émulateurs les plus utilisés ne le supporte (sur cpc), et que les IPF sont introuvable et que l'on peut facilement voir s'ils sont originaux... Je vois mal un nouveau site diffuser en masse des faux (quel intérêt ?).

Les renommer en .cpc est aussi inutile : Il sera encore plus rapide de les re-renommer en IPF.

Par ailleurs, vous qui avez le bras long : Il serait pas mal que la SPS offre un moyen de contrôler les IPF : Si l'on avait un moyen simple d'envoyer CRC+ID et d'avoir "ok" ou "ko", le problème serait résolu (à vrai dire, je me ferais un plaisir de l'ajouter à Sugarbox).

Enfin dernière remarque : Je n'utilise pas le format pour faire des faux, mais pour pouvoir faire des répliques exactes des pistes MFM que je déduis des différents format. Ce qui explique la disparité par rapport aux vrais (c'est moins lissés vu que je fais l'exacte copie), sachant que j'utilise toutes les ressources de ce format.

la verification est de mon ressort pour la france.

c est le cta qui gere cette partie. neanmoins, je constate que sugarbox plantait asez souvent avec les derniers ipfs generes.

_________________
SPS Community Expert (SPS CE) / SPS France