Alors, histoire d'avancer :

Empire : Avec run "Empire, ca fonctionne.

Hunchback : La version est strictement identique au dsk lors du chargement, à l'exception de ces deux fameux secteurs "clés"( qui ne contiennent pas de code )

Le code exécuté par la protection étant strictement identique dans les deux cas, ça n'est pas un problème de protection non supportée. Il est probable que ton disk soit déjà considéré comme une copie (se qui explique les deux secteurs changés).

Double dragon :
2 choses :On voit une différence sur les pistes &11-&15 :
Les données de chaque piste sont correcte (piste unique je rappelle, taille 6).
Il semble cependant que, sur la fin de la piste, avant le GAP final, on ait systématiquement un a deux octets qui sont incorrects (je ne vois que cette différence, si l'on omet les alignements de fin de pistes différents )

La piste 12 par contre est différente assez vite (dès l'offset &FC si mes calculs sont bons)
On y trouve un secteur faible, ce qui n'est pas le cas sur l'original.
Par ailleurs, en désactivant l'algo de détection de secteur faible, je parviens à lancer le jeu sur sugarbox, après 5 ou 6 tentative (sans ejecter le disque) : Une fois que la bonne révolution est lue, ça fonctionne.

Ma conclusion dessus : Trop de révolutions incorrecte pour avoir quelque chose de vraiment fiable. Certes tu as un dsk fonctionnel, mais je me demande comment il reconnait la "bonne" révolution (surtout s'il utilise le ct-raw ! Avec les kryoflux, on peut peut-être déterminer que l'on est dans un faux cas de "secteur faible)

C'est clair.



Oui ces secteurs ne contiennent pas de code, la protection se charge de vérifier leur contenu.



Hé bien non justement, et c'est bien ce qui me chiffonne. Le DSK dont tu parles est systématiquement invalidé par sugarbox et caprice forever 0.26, à partir du moment ou tu passes la demande de restauration de sauvegarde en tapant sur la touche 'N'. La deuxième partie de la protection qui se trouve en piste 41 n'étant pas supportée, écrit d'emblée dans les deux secteurs dont tu parles plus haut, résultat, si tu laisses sugarbox sauver dans le DSK ce qui a été modifié, au chargement suivant, le test speedlock au démarrage détecte la modification du jeu, et affiche the disc is an illegal copy".

C'est pour ça que je dis que la seconde protection n'est pas supportée. Quand tu fais run"hunch", le speedlock AAAA vient vérifier les 2 secteurs contenant normalement le pattern d'octet. avec le DSK en état propre, tu passes cette vérification et le jeu continue de se charger, l'écran titre apparait, puis l'écran de début du jeu ou on te demande la restauration d'une sauvegarde oui ou non. Si tu réponds 'non' en tapant sur 'N', la seconde protection en piste 41 est lue, et c'est là que ça déconne. Comme elle échoue, elle modifie les deux secteurs clés du speedlock. Sur un vrai CPC, si je joue avec le jeu, tout va bien. Si par malheur je reset mon CPC et que je veux charger à nouveau en faisant run"hunch le jeu, le DSK est flaggé comme copie illégale.

Faudrait vraiment voir ce que veut fait et attends le loader du jeu, pas le premier qui checke les 2 secteurs, mais celui qui va chercher la piste 41 qui est protégé par Data Over Index/shifted track.



Oui, seule la piste d'amorçage est standard, les autres pistes sont en taille 6.



Les pistes speedlock de ce jeu sont du type 'NO EDC' ce qui veut dire qu'elles n'ont pas de checksum. Et c'est de la piste longue. La piste 1 fait 100451 bits de long par exemple.

Je viens de refaire le traitement via l'outil, les piste 1 à 21 n'ont aucune erreur. D'ordinaire, en cas de dump avec des pistes de taille 6 qui ont ne serait-ce que 0,003% d'erreur, c'est garanti que le jeu merdera.

Mais ici on y est pas, je joue tout à fait normalement au jeu, et les niveaux se chargent et s'enchaine à la suite sans aucun souci. Moi l'histoire de l'impossibilité de redéfinir les touches quand on appuie sur la touche R, je sais pas mais ça m'interpelle.



Tu ne peux pas trouver de secteur faible. Et je vais t'expliquer pourquoi. Les jeux comme Double dragon I et II 128k ou encore 99,9% des jeux speedlockés n'ont pas de secteur faible. Donc si sugarbox se prend les pieds dans le tapis parce qu'il croit qu'il y a un secteur faible, c'est un bug.

EDIT: ah mort de rire Je comprends pourquoi Sugarbox croit qu'il à affaire à un secteur faible ! Je viens de vérifier le dump KFraw, les pistes speedlock de ce jeu font usage de variation de densité ! A l'aide de l'outil du Dr Coolzic, je vois que les pistes ont une taille oscillant entre 6449 et 6471 octets ! Pour claquer des pistes aussi longue, il faut utiliser la variation de densité. Et la piste 12 est tout à fait réglementaire, j'ai vérifié les 5 révolution, elles n'ont aucun problème.

Conclusion : le bug est du côté de sugarbox. je ne sais pas comment tu as codé ta routine pour les "weak sector", mais elle induit en erreur l'émulateur.



Ce qui m'embête, c'est que je n'ai pas trouvé une seule révolution pourrie sur ce jeu. L'outil du Dr Coolzic est sans appel à ce sujet, il n'y a pas de pistes pourries, ni de secteur faible. Et le CTraw est propre



Sauf que comme je l'ai expliqué plus haut, toutes les révolutions sont bonnes sur le dump de ce jeu. J'ai pas vu de piste speedlock pourrie, ou de révolution merdiques. Tout est carré sur celui-là.



Mais les révolutions sont bonnes ! Comme ce jeu utilise en plus de la compression pour chacun des niveaux, le moindre octet qui serait pas bon casserait le jeu..... Le dsk serait merdique si le CTraw était foireux ou pire encore le dump en stream.



Mais justement, moi ce qui m'ennuie, c'est qu'on ne peut même pas parler de faux cas de secteur faible, puisque ce jeu (et son dump) en sont totalement dépourvu, l'outil du Dr Coolzic me permettant d'infirmer ton constat

Cherches plutôt du côté de ta gestion de la densité des données, je pense plutôt que ton problème vient de là.

_________________
SPS Community Expert (SPS CE) / SPS France

Après analyse de lapiste 12 du CTRaw : Il y a bien une révolution différente des autres. (je te mets pas le dumps pour que tout ça erste lisible).
Vu que l'on est dans une configuration de secteur avec CRC incorrects, je déduisais un secteur faible.

J'ai ajouté un algo supplémentaire pour comparer les pistes, et conserver celles qui sont identiques : Le jeu tourne désormais... Mais tu as bien une révolution incorrecte (sachant qu'elle n'est pas détectable sans CRC !). Compare les révolutions avec ton dump kryo, tu verras une différence....

Le CT Raw peut marcher, mais n'est pas propre, non...

Visuellement, le signal tracé de la disquette en piste 12 est correct sur les 5 révolutions. Quand un dump est pas propre, l'outil du Dr Coolzic permet de le voir. On voit que le signal est soit abimé, soit en mode "fuzzy".

Ici, aucun problème



Ce que tu dis pourrais être correct si sur Caprice Forever 0.26 j'avais eu les même problème. Un CTraw ou encore un dump KFraw qui est merdeux ne peut pas donner en sortie un bon DSK ou un IPF ou encore un bon CTraw.

Je te rappelle que l'outil interdit la génération d'IPF si le dump brut tiré de la disquette est mauvais ou pas propre. Rends-toi quand même compte que même l'IPF, Sugarbox n'arrivait pas à le faire tourner !

Alors que mon CPC 6128 le charge sans problème, et idem Caprice Forever 0.26. C'était clairement un problème de ton émulateur, et rien de plus. Et te bile pas, y aura d'autres jeux qui poseront encore problème sous sugarbox, étant donné que tu fais une gestion tout à fait personnelle des datas des disks .

Maintenant qu'on sorti de cette histoire avec Double dragon, je confirme bien que la protection de hunchback n'est pas supportée.

J'ai repris le dump KFraw, j'ai regénéré un IPF et un fichier CTraw qui semblent de prime abord fonctionnel.

1) je fais run "hunch"
2) test des deux secteur, suivi du test de la piste 41 en Data over index
3) proposition de restaurer la sauvegarde, je réponds non en tapant 'N'
4) je peux jouer avec le jeu jusqu'au bout
5) comme le test de la protection en piste 41 a échoué, les 2 secteurs speedlock AAAA sont modifiés
6) si je coupe sugarbox, la modification demande à être sauvée ou non.
7) en admettant que je dise oui, au prochain lancement de l'IPF, CTraw, ou DSK, le jeu est détecté comme une copie illégale, et le processus de formatage de toutes les pistes est lancé, et le jeu est détruit.

Conclusion : Avoir les 2 secteurs speedlock propres ne suffit pas, leur condition est amenée à changer si le test de la protection en piste 41 échoue. hors, comme le dump est OK, je n'ai pas vu de secteur frelaté sur la piste en dehors du secteur avec BAD CRC de 256 octets.....

Et ce qui m'embête, c'est qu'à priori, c'est le premier jeu CPC que je vois avec une protection de type Data Over Index / Shifted track.....

Est-ce que tu pourrais examiner le code la protection, et indiquer ici ce qu'elle recherche et attends en résultat s'il te plait ?

_________________
SPS Community Expert (SPS CE) / SPS France

Stoppons donc la polémique sur Double Dragon ou les investigations n'ont pas besoin de continuer : Nous avons une dump CTRaw avec une piste "différente" des autres, en l'éliminant par ma méthode heuristique, nous arrivons à un dump correct. Tu me soutiens que toutes les révolutions sont bonnes sur le Kryoflux, en l'absence d'éléments, je ne peux que constater que le CTRaw généré a une révolution différentedes autres.

Au passage, tout le monde a une "gestion personnelle" des data du disque. En l'occurence, je pense être relativement proche de la machine via mon support MFM natif... Mon objectif, c'est surtout de ne pas perdre de temps sur des problème d'émulation qui n'en sont pas.



Pour Hunchback : Vu qu'il n'y a rien de bizarre nul part, (et surtout pas de CRC en vrac, qui pourrait éventuellement accréditer une vérification par dessus l'index), le problème ne vient pas de la lecture des données sur le disque.

Deux options : Soit il s'agit d'autre chose, soit le dump est en cause (déjà écrasé).
Pour valider le dump, une seule méthode, le CPC.
Soit la procédure suivante :

- Prendre le dump réputé fonctionnel (issue de l'IPF ?)
- En faire une copie
- Jouer au jeu en le déprotegeant, en disant 'N' pour une reprise de sauvegarde
- Relancer le jeu.

Si le jeu se lance plusieurs fois de suite sans soucis malgré cela, c'est autre chose. S'il ne se relance pas, on peut imaginer une protection à double détente :

- Je détecte une copie
- J'écrase une première fois la piste 41 avec des EA
- A la relecture, la fois suivante, pour ne pas éveiller les soupçons, je lance le jeu et écrase la piste tartenpion avec des E5
- A la relecture, si je vois des E5, j'indique "copie illegale".

En bref, il faut déjà être sur que l'on a un dump qui se lance bien plusieurs fois sans soucis.


Dernier point, qu'entends tu par protection de type "Data Over Index / Shifted track." ?
J'imagine un secteur qui passe au dessus du trou d'index (comme la série des "Réussirs") ?

Surtout, sur quelle piste le constates-tu ?

ça je dis pas, mais le souci venait bien de sugarbox.



Caprice32 avec support IPF et Caprice Forever 0.26 utilisent avec exactitude la LIB de SPS exactement comme indiqué. Tu es le seul à faire un support custom des IPFs



Le problème vient de la protection qui n'est pas supportée. J'ai deux dumps issus de disquettes différentes de ce jeu, et les deux ont le même problème.



Sauf que le jeu n'est pas déjà écrasé. Si tu me relis mon post juste au dessus, tu verras que le jeu se lance correctement la première fois. Tout part en couille quand la piste 41 est lue. Hors cette piste je ne l'ai pas touchée, et le problème se présente avec le dump stream, CTraw et IPF.



J'ai testé aussi avec le DSK, c'est la même merde. Tu lances le jeu la première fois, dès que tu dis 'N' pour la sauvegarde, le jeu teste la piste 41 et modifie les 2 secteurs speedlock, tu peux jouer 1 fois.

Si tu tentes de jouer une seconde fois, en ayant laissé juste avant la protection modifier le disque, là tu obtiens le message le "disc est illégal".



C'est exactement ce que j'ai fait, relis mon post au-dessus ! A la relance, si les modifications ont été enregistrée dans le fichier (CTraw, IPF, Dsk ou version stream), le jeu indique "This disc is illegal".



La protection détecte une copie, parce qu'elle n'est pas supportée. La modification se produit parce que le test de la protection en piste 41 échoue.

Le souci c'est que le dump en stream vient d'une disquette originale. La piste 41 est telle qu'elle sur la disquette.



Comme je l'ai indiqué, le dump ne se lance correctement qu'une et une seule fois. Si on accepte que Sugarbox accepte la modification liée à l'échec du test de la piste 41, lors de la relance, comme les 2 secteurs Speedlock AAAA ont été modifiés, le jeu affiche "this disc is illegal".

Faut vraiment gratter sur le test de lecture de la piste 41, et ça n'étant pas programmeur, toi seul peut le faire.



Oui c'est bien ça. le secteur protégé en BAD CRC de 256 octets a une partie de bloc qui est au dessus du trou d'index. Shifted track signifie Piste décalée.

Vraiment Thomas, perds pas ton temps, regarde ce que fait la routine de test qui checke la piste 41.

La solution du problème est là. Qu'est-ce que cette dernière veut, et qu'elle ne trouve pas quand sugarbox la lit, et qui conduit à la modification des 2 secteurs speedlock AAAA ?



ça fait 2 posts que je l'indique mais tu me lis pas : Piste 41 ! Elle contient la protection physique, et celle-ci foire, puisque les 2 secteurs speedlock sont modifiés systématiquement à cause de ça.

_________________
SPS Community Expert (SPS CE) / SPS France

C'est sans doute aussi pour cette raison que je lis des dumps que la lib ne supporte pas (les weaks sectors IPF pour ne pas les nommer)...



Tu ne m'as pas compris en fait, Denis :
Le test que tu fais est à faire sur un vrai CPC.

La piste 41, par ailleurs, est très étrange : Elle contient un secteur olé olé (FE 21 21 21 20 20 8C 02 dans le dsk)... Qui n'est pas lu !
On se contente de lire le secteur 82 (qui ne contient rien de bizarre : Que des EA)
Il n'y a rien de bizarre au niveau du contenu ou des appels au fdc.



Le secteur qui peut provoquer un Data over index, c'est le premier secteur (le fameux FE 21 21 21 ).
Vu sa taille fantaisiste, il n'y a que lui qui pourrait provoquer ce type de chose.
Et il n'est jamais lu, que ça soit via ReadSector ou ReadTrack...

Donc je réitère : Il faut faire appel au juge de paix. Soit le dump fonctionne ad vitam eternam SUR UN VRAI CPC, soit non.
Je ferais le test ce soir, tiens.

Le support des weak-sectors se fera vient la programmation qui va bien du contrôleur de disque custom de la carte kryoflux. Ce que tu fais "ça marche", mais les IPFs sont non conformes.

Le créateur du système te dirait que c'est du "cheat". Enfin.... on verra quand on y sera



Non mais c'est une blague ? Je t'ai indiqué plus haut dans mon post que j'avais aussi fait le test sur mon 6128 !

Sérieusement arrête de mater de du porno pendant que tu lis mes posts, tu rateras peut-être moins d'information lol !



Ah bah ça c'est un souci !



Bon sang, mais alors quelle est la condition lié à cette foutue piste qui fait que le programme flingue les secteurs à contenu "protégé" ?



Comme tu me lis toujours en biais, je te redis ici ce que j'ai écrit plus haut, sur un vrai CPC c'est pareil. Tu peux jouer la première fois que tu lances le jeu, si tu laisses le programme déprotégé en écriture, il te flingue toute la disquette en indiquant que c'est une copie.

Il y a quelque chose qui nous échappe et qui conduit à ce problème.

_________________
SPS Community Expert (SPS CE) / SPS France

?? Tu plaisantes ???
Donc Sugarbox se comporte comme un vrai CPC ??
Je crois que parfois tu manques de clarté (ou alors, j'ai tendance a être parano...)

Il n'y a pas de problème de support de la protection : Si un vrai CPC ne l'accepte pas, c'est que la disquette (ou le dump) est incorrect. Pour la préservation, c'est dommage (il faudrait sans doute un autre original). Après, on pourrait tenter de voir ce que recherche la protection, mais j'avoue que je ne suis pas le mieux placé (ni le plus motivé ) maintenant que j'ai mis mon ému hors de cause (avec 100% du batch qui se comporte comme un vrai cpc ! -> Dans la version "WIP" pour Double Dragon, bien sur)

J'ai été très clair, et c'est pas la première fois que tu me fais le coup lol.



J'ai quand même dumpé 2 disquettes différentes, ensuite ce qui m'ennuie c'est que tu dis que le secteur protégé de la piste 41, tu le vois comme étant le premier de la piste alors que c'est impossible, seule sa deuxième moitié se trouve avant le trou d'index.

Tu peux aller plus loin dans ton affirmation ?



Ben j'aimerais bien connaitre les conditions justement qui conduisent à la détérioration de la disquette.



Ah parce que c'est tout ce qui t'intéressait ? Et moi qui croyait que tu ratissais plus large......

_________________
SPS Community Expert (SPS CE) / SPS France

Le premier secteur (le fameux secteur "farfelu") n'est pas lu.
Le secteur 82 est le seul lu.
Si on le supprime, le format de la disquette est immédiat, donc il est nécessaire, mais sans doute doit-il contenir autre chose que ce que l'on observe.

Si tu pouvais nous fournir le kryoflux (au moins la piste &29), on verrait mieux qu'avec le dsk, bien sur !



A vrai dire, je suis sur un autre sujet en ce moment (sur lequel je ne passe déjà pas le temps que je voudrais), donc je fais le "minimum syndical", orienté compatibilité principalement.

Bon ok, au point ou on en est, je t'envoie le Dump KFraw du jeu sur ta boite.

_________________
SPS Community Expert (SPS CE) / SPS France

@lone : un indice -> je pense que le problème ne vient pas de la lecture mais de l'écriture...

FDC : Command=0f-00 01
FDC : Command=4d-00 02 09 52 eb

format du track 1 (standard avec 9 secteurs) -> 6250 bytes

FDC : Command=0f-00 29
FDC : Command=4d-00 02 0a 52 eb

format du track 41 (pas standard avec 10 secteurs) -> 6706 bytes !!!

quand je regarde le dsk original (celui de cpc-p0wer...j'en ai pas d'autres...), je ne vois que des "ea" dans les secteurs... et en plus le secteur 10=0a est tout bizarre au niveau du Track-info l'IDR=c1 c1 cd 17 01 et de la longueur=0 avant le formatage !!!

(SYNC+IDAM+IDR+GAP2+SYNC+DAM)

0000: 00 00 00 00 00 00 00 00 00 00 00 00 a1 a1 a1 fe ................
0010: e1 c1 c1 cd 17 01 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e ......NNNNNNNNNN
0020: 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 00 00 00 00 NNNNNNNNNNNN....
0030: 00 00 00 00 00 00 00 00 a1 a1 a1 fb ............

le contenu des secteurs est "ea" avant le formatage et "eb" après le formatage (cf la commande envoyée au FDC) !

Sauf le dernier secteur "c1" qui n'a pas de longueur !

après formatage il reste "c1" mais se retrouve avec &200 de "eb"... c'est ce que demande la commande de formatage au FDC pourtant !!!

--> bizarre non !?

--> je me demande ce qui se passe au niveau du fdc, quand on est en train de formater un secteur et qu'on arrive peut-être à l'index de la piste !?

@dlfrsilver : je suis preneur du "nouveau" dsk pour voir ce qui'il y a exactement sur la piste 41 avant le formatage normal par le loader !

à noter que le loader prend la valeur contenu dans le secteur (ex : "ea") et envoie à la commande de formatage "octet+1" (ex:ea+1=eb, etc.) ce qui explique qu'on a en piste 1 et 41 toujours le même octet mais pas toujours la même valeur d'un load à l'autre !

Ca y est, je viens de voir ce qui ne va pas... c'est en rapport avec la taille de la piste...

au départ elle est inférieure car le secteur 10 n'a pas de data (d'après les infos du dsks)... et quand on reformate, la taille des données contenu dans la piste est plus importante, il faut donc que la piste soit en rapport avec cette augmentation de données et de taille de piste pendant le formatage et pas qu'après le formatage !

Lone, j'espère que cela pourra t'aider à identifier le pb dans Sugarbox !

Voici le dump KFraw du jeu en PJ.

Vous pourrez en faire un DSK ou CTraw ou examiner la piste 41, mais comme je l'ai expliqué, le secteur 256 a une partie de lui-même qui est au dessus du trou d'index.

J'ai compris quelque chose. La révolution 5 du dump KFraw est mauvaise, on ne voit pas le secteur de 256 octets en BAD, par contre, il est présent dans les révolutions 1 à 4.

voici les infos de la piste qui ne contient que 9 secteurs et non 10.

T41.0 shifted track: Data over Index (DOI) ; piste décalée: Donnée au dessus de l'index
T41.0 S193 invalid track number 225 (ITN) ; numéro de piste invalide
T41.0 S193 invalid head/side number 193 (IHN) ; Numéro de tête/face invalide (193 = C1)
T41.0 S193 invalid sector length 205 (ISL) ; longueur de secteur invalide (205 = CD)
T41.0 S193 invalid DATA CRC (IDC) ; CRC des données invalides (car coupé en deux avec un bout du secteur C1 au dessus de l'index

Et la représentation graphique de la piste en PJ :

_________________
SPS Community Expert (SPS CE) / SPS France