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

Le marauder / ubisoft / Disquette amstrad
https://cpcrulez.fr/forum/viewtopic.php?f=8&t=5001		 Page 4 sur 4
Auteur :  Lone [ 25 Juil 2013, 16:38 ]
Sujet du message :  Re: Le marauder / ubisoft / Disquette amstrad
Bonjour a tous,

Je me permets d'exhumer ce relativement ancien post, car il aborde un sujet qui m'interpelle en ce moment.
Je suis actuellement en train de mettre au point un émulateur maison, destiné a être le plus précis possible.
Je suis actuellement en train de peaufiner mon émulation du FDC, et ce post m'intéresse au plus au point.

Mon FDC est basé sur une reconstruction de la piste à l'octet prêt (donc, avec toutes les informations MFM : synchro, GAP, CRC, issue de la datasheet). Mon émulation est sensé être synchro avec le temps : 32 us par byte lu, lorsque le moteur est en vitesse de croisière.

Le problème que j'ai se situe sur le jeu Chicago90, au moment de la lecture de la piste 39, secteur 41 (celle contenant les fameuses valeurs en GAP).

Lors de la lecture de ce secteur, les interruptions ne sont pas désactivée, ce qui fait que lors de cette lecture, plusieurs vont survenir, me faisant rater la lecture en temps et en heure des datas en provenance du FDC, ce qui fait que je termine en overrun....

Je contourne le problème en utilisant un buffer pour tamponner les valeurs en provenance du FDC... mais sans en trouver aucune trace dans aucune doc, par ailleurs. Je souhaiterais donc comprendre précisément ce qui se déroule lors de cette routine du diable, non pas au niveau de la protection elle-même, mais au niveau du comportement du FDC et du CPU lorsque ces interruptions sont activées.

N'ayant pas de CPC réel sous la main (oui, j'aime le challenge...), je fais appel à vous, bonnes âmes et heureux possesseurs de nos vielles machines, pour éventuellement me donner un coup de main : Est-il possible, avec vos machines infernales (multiface & co) de faire du debug en réel, pour savoir ce qui peut se passer exactement ?

Idéalement, il faudrait mettre un point d'arrêt sur l'adresse 8075 (routine de lecture de l'octet suivant), puis sur l'adresse 0038 (interruption) , et, une fois sur cette adresse 0038 atteinte, evaluer DE, qui est le nombre d'octet à lire depuis le disque.

De ce fait, je pourrais comprendre si :
- Le problème vient d'une inhibition des interruptions que je ne gère pas, pour une raison ou une autre (un DI quelconque automodifié dans le code, que je ne gère pas correctement ?)
- Il y a bien un buffer, qui permet l’exécution pas trop long d'une interruption en cours de lecture du disque. (dites moi si je me trompe, mais 32us pour executer une interruption en plus de lire les octets en provenance du FDC est un laps de temps bien trop court ?)

Je tente de bricoler un programme de test plus simple à vous soumettre (sauf évidemment si vous avez tous des idées de génie sous la main...)
Auteur :  Lone [ 26 Juil 2013, 13:52 ]
Sujet du message :  Re: Le marauder / ubisoft / Disquette amstrad
Bonjour.

Après avoir sorti mes docs sur le Z80, j'ai finalement réussi à concocter un programme de test permettant de savoir si, oui ou non, on a le temps de mettre de la latence entre deux byte lors d'un read track.

Vous trouverez ci-join un bin (et un dsk,; si ça peut faciliter le lancement), et je serais très reconnaissant à la personne lançant le binaire contenu sur un vrai CPC.
L'idée de ce programme est assez simple :
1/ Faire un read track "normal", et retourner le nombre d'octet lu
2/ Faire un read track en attendant systématiquement 67us entre le moment ou la donnée est prete, et celui ou on la lit effectivement.

Ce second cas devrait retourner un nombre de lecture très inférieur à la première. En fait, on devrait, dans le cas d'absence de fifo, avoir une valeur proche de 0 ou 1.

En faisant les tests sur les émulateurs que j'ai sous la main, j'obtiens :
- Caprice32, CPC++ et Winape ne gère pas de tempo sur l'overrun (les valeurs du test 1 sont importantes.
- Sur ma version de mon émultaeur FDC équipé d'une fifo de 16 bytes, j'obtiens 7

Il me manque donc la version "Vrai CPC", ce qui permettrait de trancher la question.
Si quelqu'un peut faire l'essai et me poster le résultat, je lui en serais éternellement reconnaissant.

Un simple Run "TFDC.bin" et une lecture de l'écran suffit.
Auteur :  fano [ 26 Juil 2013, 13:59 ]
Sujet du message :  Re: Le marauder / ubisoft / Disquette amstrad
Citer :
Test FDC
Overrun detected
01cf
Test 1 : Standart
Overrun detected
009b


32µs pour gérer une interruption, tu peux caser quelques instructions en plus de la gestion de l'interruptions en elle même (genre le saut/ei/ret/exx/ex af,af') mais c'est vraiment court.
Auteur :  Lone [ 26 Juil 2013, 14:14 ]
Sujet du message :  Re: Le marauder / ubisoft / Disquette amstrad
Merci, plus rapide que l'éclair !

Bon, il faut que je me plonge dans le pourquoi du comment, parce que c'est une valeur que je n'attendais pas tout a fait...
(Je soupçonne un bug dans mon prog de test, mais bon, ça ne serait pas très étonnant vu que c'est plus ou moins mon premier prog z80...)
Auteur :  Lone [ 26 Juil 2013, 22:22 ]
Sujet du message :  Re: Le marauder / ubisoft / Disquette amstrad
Hello à nouveau

Une petite mise à jour de mon test : Il semble donc qu'un read track sur lequel on ne vient pas tout lire ne termine pas immédiatement.

Pièce jointe :
tfdc1.DSK


Ce qui veut dire que si on ne lit pas les informations, celles-ci sont juste perdues.
On aura malgré tout le bit overflow de levé à la fin de la commande.

Merci d'avance a ceux qui pourront me poster le résultat sur un vrai CPC !
Auteur :  fano [ 27 Juil 2013, 03:48 ]
Sujet du message :  Re: Le marauder / ubisoft / Disquette amstrad
Trop de texte à taper :D
Auteur :  Lone [ 27 Juil 2013, 10:39 ]
Sujet du message :  Re: Le marauder / ubisoft / Disquette amstrad
Merci une fois de plus.

Que constate-t-on ?

Le programme réalise deux lectures du secteur C1 de la piste 0. On s'arrête au bout de 255 octets, et on affiche les 20 premiers. (ce qui explique le caractère systématique du bit overrun)

La commande de lecture est la suivante :
&42, &00, &00, &00, &C1, &02, &c1, &2a, &ff

Le début du contenu du secteur en question est la suvant :

00 54 46 44 43 20 20 20 20 42 49 4E 00 00 00 07 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5

Le premier test est en mode polling en continue, le second également, mais en intercalant, des qu'un caractère est prêt, un délai d'a peu près 60-70 us.

On constate que le résultat du premier test est conforme :

00 54 46 44 43 20 20 20 20 42 49 4E 00 00 00 07 02 00 00 00, ce qui correspond exactement aux 20 premiers caractères du secteur.

Le second cas, lui, est intéressant.
On lit les octets suivants :
46 20 20 4e 00 00 00 00 00 00 e5 e5 e5 e5....

Ce qui fait qu'on lit, grosso modo, un caractère sur 3. Ce qui semble correspondre au délai introduit.

On doit pouvoir en conclure :
- Que le FDC ne passe pas en phase de résultat immédiatement si l'on ne lit pas la donnée présente (du moins, pas avant la fin du secteur)
- Qu'il n'y a pas de buffer pour tamponner les données.

Concernant le sujet de départ, j'en conclus donc que, dans le cas de Chicago 90, la somme des temps passés en interruption ne dépasse pas le nombre d'octet en F7 présents dans le GAP.

Mon problème se situe donc définitivement sur mes timings d'interruptions.
Auteur :  Lone [ 30 Juil 2013, 11:50 ]
Sujet du message :  Re: Le marauder / ubisoft / Disquette amstrad
Bonjour à tous.

Comme je suis tenace (ma femme dit plutôt "Têtu", mais je préfère "tenace"), je suis toujours à tenter de comprendre comment fonctionne ce fichu Chicago 90.

J'ai désormais les informations suivantes en ma possession :

- Le FDC n'a pas de fifo, ou de tampon quelconque
* Le FDC ne stoppe pas son envoi de donnée en cas d'overflow (du moins, pas avant la fin du secteur courant).
- La protection de Chicago 90, une "classique" protection GAP, est déroulée sans interrompre les interruptions.

En mesurant les temps totaux passés dans les interruptions, tout au long du déroulement de la routine de lecture du sector+GAP, j'arrive aux temps suivants (testé avec WinAPE en mode debug, qui semble gérer (a peu près) correctement l'overrun et les timings FDC), et avec mon emu "maison", que j'ai modifié pour coller au plus près de la structure MFM) :

- WinAPE : 6 interruptions, 4 d'une durée de 108us , une de 390us et une de 977us, pour un total de 1799 us (soit, divisé par 32, 56 à 60 byte ratés, suivant le placement des timings)
- Mon emu maison : 5 interruptions, 3 d'une durée de 108us, une de 390 et une de 983, pour un total de 1697us (soit 54-58 byte loupés)

La différence s'explique sur l'absence d'une quelconque synchro HALT ou VBL dans le lancement du soft : Suivant le moment ou tout se passe, on peut avoir une interruption de plus.
Je suis donc en phase avec Winape.... Mais pas du tout avec le dump que l'on possède, qui ne présente que 34 caractères F7 dans le GAP du secteur C1 de la piste 39....

Mon hypothèse suivante est la suivante : Le dump est incomplet. (je me base sur le dump de cpc-p0wer)
Avec un GAP de longueur standard (78 si je ne m'abuse ?), et contenant des octets F7 uniquement, la protection passerait sans soucis.

Quelqu'un, parmi vous, a-t-il possibilité de vérifier l'original ?

Note : Je sais que certains emulateurs lancent le jeu. C'est le cas de tous ceux qui ont un FDC plus attentiste (qui donne les données quand le CPU les demandent, le tout sans gérer l'overrun de manière précise au niveau des timings). D'ailleurs, ça marchait également pour moi avec un FDC customisé (avec un buffer !)
Auteur :  Lone [ 30 Juil 2013, 21:13 ]
Sujet du message :  Re: Le marauder / ubisoft / Disquette amstrad
Après avoir pu tester sur un dump différent (avec le nombre correct de GAP3 à F7 !), l'hypothèse est vérifiée.
Le dump est donc en cause, je vais pouvoir dormir sereinement : Sur ce nouveau dump, tout se passe comme prévu.

Merci a breiztiger/maxit pour ce dump.

(en tout cas, ce fut un excellent exercice de debug soft/hard !)
Page 4 sur 4 Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/