il reste environ 9 secteurs. C'est un cas d'école intéressant en fait, car c'est sur les erreurs et les cas spéciaux qu'on fait avancer l'émulation. Les cas standard ne permettent pas grand chose en fait.

_________________
SPS Community Expert (SPS CE) / SPS France

Quand je mets le dsk de l'autre original, j'ai le même resultat vu du FDC, mais la protection passe...



j'en déduis à ce stade, que cela ne semble pas être une erreur d'émulation FDC... et que la protection semble la même puisque

puis si je reprends le "Titus...raw" quand j'essaye de lire le secteur avec l'utilitaire FDCTEST : j'ai bien le mot "Titus" en &xx1b !
bizarre quand même.. par contre, le contenu du secteur n'est pas le même, je vous mets les deux images...

dsk d'avant :

nouveau raw :

reste plus qu'à faire la même chose sur un vrai CPC avec la vraie disquette (alt) :

commande FDC : 0f
param : 00 28

commande FDC : 46
param : 00 5a 00 0c 05 0c 2a ff

de plus, le test du loader doit être bon sur le mot "Titus" car le loader ne reset pas !!!

ce qui est encore plus bizarre...

et dès qu'on mets le dsk, le loader continue est charge le jeu...

--> il y a t-il encore un autre test dans le loader z80 non décrit dans l'article après et qui ne matche pas avec le contenu du disk !??

En théorie, tout cela sont des problèmes résolus : Les FDC émulés modernes prennent en compte la vitesse de rotation des disquettes (voir une vitesse variable en fonction de la piste !). Donc, le comportement émulés d'un point de vue piste ressemble fortement à la réalité.

Les GAPS, de plus, ne sont pas évalué au doigt mouillé : Le RAW les contient et permet de les avoir exactements.

Ce que j'observe par contre, c'est la chose suivante.
Sur le deuxieme secteur 0C (celui de taille 5), la routine va :
- Copier les 256 premiers octets a &8000
- Vérifier les octets de résultats... Qui sont, dans notre cas, les octets suivants sur la piste ! On n'attend pas la fin du secteur pour les lire. Et ce sont eux que l'on va interpréter via les AND que j'ai mentionné plus haut. A la manière d'un test de resultat standard. D'où l'explication de l'auto retry : On est pas en test de la protection, mais de la lecture de secteur.

Dans ce cas, je ne pige pas ou est le problème !

Le secteur 0C est toujours en première position juste après l'index. C'est comme ça qu'est le dump original.

est-ce que tu peux nous dire de quoi il en retourne plus précisement ?

quels sont ces octets érronés que la protection rejete au final ? Est-ce qu'ils font partie du premier secteur du reste de la KBI-19 ?

_________________
SPS Community Expert (SPS CE) / SPS France

Je m'en charge ce soir. Je vais faire le test sur mon 6128.

_________________
SPS Community Expert (SPS CE) / SPS France

Comme je l'ai dit, le lecteur 0C lu effectivement a une taille de 5. Donc, de &1000 octets.
Après avoir lu les &100 premiers, la routine va vouloir lire le resultat, sauf que.... La commande n'est pas terminée. Ce qu'elle prend pour des octets de résultat est donc la suite de la lecture (moins l'overrun possible, dû au temps pris par la sortie de la routine de lecture).
Evidemment, ces octets n'ont rien à voir avec des octets de résultats, d'où la détection d'erreur avec les émulateurs...