Merci pour le temps pris pour l'analyse des protecyt, je vais regarder ca de plus pret.
Par ailleurs, je n'ai tjs pas de réponse de mo5, donc on peu partir du principe qu'il ne seront pas de la partie. Etrange comme comportement de la part d'une assoc pour la preservation mais bon... c'est comme ca.
J'ai rencontré l'équipe de MO5.com il y a quelques années. Je cherchais à l'époque à récupérer des CPC6128 avec toutes les versions de chips CRTC, afin de pouvoir étudier le comportement de ces machines et améliorer mon émulateur.
Quand je suis allé les voir, je me rappelle que j'ai été reçu avec une très grande méfiance. Mais je pense qu'il faut se mettre à leur place. Ils ne me connaissaient pas. Et je suis sûr qu'ils sont sollicités régulièrement par des collectionneurs peu scrupuleux qui tentent de leur extirper les plus belles pièces de leur collection.
Enfin bref, le dialogue n'a pas été facile, mais au bout du compte ils ont accepté d'échanger un CPC6128 Type1 en excellent état que je leur avais amené contre un de leur CPC6128 Type2.
Ce que je peux te conseiller, c'est d'envoyer un mail directement à Philippe Dubois (le président de l'association). Si tu expliques bien ta démarche, je suis sûr qu'il pourra t'aider. Tu trouveras son mail sur cette page web : http://www.mo5.com/association/index.php
_________________ Mon émulateur CPC en JavaScript : http://cpcbox.com
Inscription : 21 Août 2008, 16:03 Message(s) : 342
>phi2x Je te remercie pour les infos mais, Je connais très bien #mo5 et assez bien aussi P. dubois. Je connais aussi assez bien les locaux pour X raisons (participation). J'ai été membre un bon moment chez eux et leur ais rendu quelques services assez... important dirons nous. (sans entrer dans le détails, pas envie de m'étaler sur le sujet).
Le mail en question que j'ai fait à été envoyé justement au president (Dubois donc). Si il n'a pas répondu... soit qu'il est pas en france (possible), soit... il a pas voulu y repondre soit autre chose. (tjs possible mais peu probable).
Après, comme dit dans le mail, je n'oblige personne à rien. Chaqu'un est libre des ses choix, j'attendais juste au moins, une réponse. Chose qu'avant il me donnait.
Mais bon, peu être qu'il est occupé sur autres choses, je lui laisse le bénéfice du toute pas de soucis. Toute façon, ca n'empeche pas de chercher d'autre solution même si, là de suite, je n'en voie pas.
C'est sur que ca vas pas aider Maiiiiiiiiiiis, c'est comme ca
Je me suis fait à l'époque (et j'ai tjs) un CPC multi CRTC (me suis fabriquer une petite carte adapt., je tourne une molette pour choisir le CRTC) C'est un CPC6128 dans une coque de CPC464 (avec donc le lecteur de cassette fonctionnel (ù tape) et le lecteur de disquette est aussi dispo dans la coque modifié. y'a aussi un support ROM amovible sur le dessus de la coque pour Parados ou autre. Un cinch pour les jeux reseau, une led sur le cap's lock BREF... me suis bien amusé et je m'en sert tjs d'ailleurs
Ace ne verra jamais le jour sur CPC, offset à déja été très clair à ce sujet (hélas). Cet emulateur (ace donc) il a quelque chose de différent... sais pas comment dire mais mais vraiment un truc de plus, on a vraiment l'impression d'être sur un CPC pas un emul Difficile à décrire.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Dernière édition par Giants le 14 Déc 2015, 21:32, édité 1 fois.
J'ai regardé, le wav fonctionne. Il doit y avoir un petit arrondi inexact sur le cdt, sans doute (sans rien avoir à voir avec une quelconque polarité, donc)
Le temps de tester Thomas l'a déjà fait, il est partout
Donc oui il fonctionne sur sugarbox même avec un wav en csw
Je pense aussi à un Probleme d'arrondi
Peut être que vous pourriez en discuter avec megachur
Pour info ne marche pas non plus en cdt sur caprice forever
Giants, offset n'est pas ferme à un portage sur Windows, il dit simplement que çela sera dure et long et qu'il veux d'avord avoir ace sur morphos au top de ce qu'on peut faire
D'ailleurs le portable par Adrien sur aiku avançe petit à petit, qui plus est, aiku fonctionne parfaitement sur virtualbox par exemple sur nos PC
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
J'ai regardé, le wav fonctionne. Il doit y avoir un petit arrondi inexact sur le cdt, sans doute (sans rien avoir à voir avec une quelconque polarité, donc)
Ben non justement, cesar a calculé les timings d'après le WAV original, à savoir, le jeu ne fonctionne ni sur CPCE ni sur Sugarbox en CDT (et pour la même raison).
Le système de protection est basé sur la polarité, qui veut que le CPC bascule l'état du signal.
Manifestement il y a un problème de gestion de pause dans l'implémentation CDT de sugarbox, car les pauses entraine la bascule de la polarité (0 devient 1 et 1 devient 0) après la première millisecondes. Avec une exception... lorsque la longueur de la pause est de 0, ex: quand il n'y a pas de pause!
Devinez ce qui se passe ?
Hé bien la polarité n'est pas correctement réinitialisée entre les blocs, ce qui fait que seuls les premiers blocs se chargent. Et c'est le même problème entre CPCE et Sugarbox de ce point de vue.
Contrairement à ce que dit notre tigre de bretagne, ce n'est pas les timings le problème, mais bien ce que le loader attend. En gros quand on charge le jeu sous sugarbox, les premiers blocs qui sont normaux et qui n'utilisent pas la bascule de polarité se chargent normalement sous sugarbox.
C'est après que ça se gâte. Loader est codé pour traiter la polarité, hors, quand il s'attend à ce que le CPC émulé ait fait son travail, qu'il ne fait pas correctement ici, il lui renvoie la polarité inverse de celle qu'il attend, en gros le loader attends un signal basculé à 1 par l'émulateur, mais comme la polarité n'est pas gérée en mode CDT (ça marche en WAV donc), l'émulateur laisse le signal à 0, et comme 0 n'est pas la valeur attendue par le loader, celui-ci considère que le bloc qu'il attend n'existe pas.
C'est la même histoire que la protection utilisée par opérasoft sur Corsaires ou Mot, on a toujours stocké dans le DSK plusieurs lecture d'un même secteur, car la réaction du FDC face à la première lecture de la piste de protection n'est pas émulée. Le jour ou ce comportement sera émulé, on pourra dégager les multiples lectures de secteurs et ne garder que les 1536 octets de long nécessaire à la protection.
Expliqué plus simple, une protection repose toujours entre des données ayant une certaine forme et longueur sur un support physique, et la réaction de la puce contrôleur de disque.
Ici pour ce jeu en cassette, tout est correct au niveau logiciel, le problème est au niveau matériel, la machine virtuelle ne reproduit pas le fonctionnement correctement point de vue du signal, raison pour laquelle le programme réagit de manière incorrecte, puisque la machine ne déclenche pas la bascule qui entraîne le changement du signal, qui est vérifié.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
J'ai regardé, le wav fonctionne. Il doit y avoir un petit arrondi inexact sur le cdt, sans doute (sans rien avoir à voir avec une quelconque polarité, donc)
Cesar a désassemblé le loader, et ce dernier fait usage de la polarité.
En fait, le premier CDT qu'il a crée fonctionnait sous CPCE, mais pas sur un vrai CPC 464. A présent le CDT ne marche pas sous CPCE, mais il marche sur un vrai CPC
_________________ SPS Community Expert (SPS CE) / SPS France
Denis, on ne va pas relancer le débat, je crois qu'on a déjà fait assez de page dessus .... Le wav passe mais pas le cdt, alors que le code derrière c'est le même, chacun en conclut ce qu'il veut.
La mienne, c'est que j'ai sans doute un soucis arrondit sur mon chargement de cdt, et voila.
Sauf si, quand César parle de polarité, il dit que le loader est sensible au front (montant ou descendant), auquel cas on est d'accord. Simplement, le signal n'est pas "inversé" magiquement... Le wav généré par le cdt en est la preuve (il passe partout).
Pour Corsarios, on ne stocke pas plusieurs lecture du même secteur, mais la totalité de ce que le FDC retourne sur une lecture secteur de taille 6 (ou 8). Le stockage de plusieurs lecture du même secteur, c'est pour un weak sector (uniquement)
On stocke plus à cause d'un des défauts du format edsk qui ne stocke pas les données gap et surtout, l'endroit exact ou l'on rencontre l'index et ou l'on poursuit la lecture du secteur sur le début de la piste. D'ailleurs, les formats "MFM" genre ct-raw ne stockent que le nécessaire (d'ou leur supériorité).
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
Denis, on ne va pas relancer le débat, je crois qu'on a déjà fait assez de page dessus .... Le wav passe mais pas le cdt, alors que le code derrière c'est le même, chacun en conclut ce qu'il veut.
La mienne, c'est que j'ai sans doute un soucis arrondit sur mon chargement de cdt, et voila.
C'est possible. Tu gères les WAV de manière "carrée", conforme à la vraie machine, donc pas de problème. Enfin, quoi que
Sugarbox ne sait pas lire par exemple le WAV original du jeu, tu as envie d'y jeter un oeil ?
Le wav en question passe sur mon 464 comme une lettre à la poste.
Citer :
Sauf si, quand César parle de polarité, il dit que le loader est sensible au front (montant ou descendant), auquel cas on est d'accord.
Oui déjà mais pas que. Le CPC déclenche en hard la bascule lorsque certaines conditions sont réunies.
Citer :
Simplement, le signal n'est pas "inversé" magiquement...
Mais c'est bien ce que je dis, il n'y a pas de magie, le hardware du CPC change la polarité lorsque certaines conditions sont réunies.
Citer :
Le wav généré par le cdt en est la preuve (il passe partout).
Sauf que comme je l'ai indiqué, si le WAV digital passe bien, le WAV tiré de la cassette qui est pourtant très propre et que mon 464 charge les deux mains dans le dos en fumant un pétard, ne passe pas sous sugarbox.
Citer :
Pour Corsarios, on ne stocke pas plusieurs lecture du même secteur, mais la totalité de ce que le FDC retourne sur une lecture secteur de taille 6 (ou 8). Le stockage de plusieurs lecture du même secteur, c'est pour un weak sector (uniquement)
Pourtant j'en ai discuté avec Kukulcan, et pour lui ce qu'on a actuellement n'est pas normal. La gestion de cette protection est simulée, et non gérée tel quel, c'est aussi la conclusion que j'ai tirée de ce que j'ai dumpé.
J'en veux pour preuve, si je m'amuse à convertir le DSK tel qu'il est actuellement, en fichier RAW, et que je m'amuse à le passer dans l'outil de génération d'IPF pour voir s'il la reconnait, il m'indique que non, que c'est une piste non pas "modifiée", mais "bricolée".
Ca confirme bien ce que je dis. En plus ce que le FDC retourne est grugé, car la piste de protection d'opérasoft, c'est 7 secteurs de 256 octets suivi d'un Secteur 8K fake composé de 128 octets déclarés et tout le reste des octets dans une immense zone GAP.
Next, cette protection fait usage de variation de densité. La piste fait 6155 octets de long au total, et le secteur est un secteur long, ça c'est pas géré par le format DSK. Hors il se trouve que c'est une partie de la protection, et que le FDC est sensé avoir une réaction particulière suite à la lecture de cette zone. Il n'y a pas de zone ou de secteur réel de 8k, ensuite quand on regarde la piste on s'aperçoit que :
1) on a affaire en piste 40 secteur 2 à un secteur Long d'une durée de 8623,83 µs. 2) le secteur 8 bricolé est de fait un IIF-ISL, à savoir une taille de secteur du champ de données invalide (IIF), donc fake d'une taille 8 dans un secteur ayant une longueur invalide, 128 octets = (ISL) 3) automatiquement les points 2) et 3) amènent tout droit à une erreur de données CRC (DCE DATA CRC Error), car le CRC indiqué n'a été calculé que sur la partie déclarée du secteur "physique" à savoir 128 octets.
Le problème n'est pas le stockage des données GAP, puisque ça le format DSK pourrait tout à faire le faire. Le problème se situe côté émulateur, comment faire pour que le FDC comprenne qu'on a de la variation de densité, sachant que la longueur du secteur est fausse, que la longueur des données du champ data est fausse, et que ces deux erreurs entrainent de facto un comportement particulier du FDC en retour.
Citer :
On stocke plus à cause d'un des défauts du format edsk qui ne stocke pas les données gap et surtout, l'endroit exact ou l'on rencontre l'index et ou l'on poursuit la lecture du secteur sur le début de la piste. D'ailleurs, les formats "MFM" genre ct-raw ne stockent que le nécessaire (d'ou leur supériorité).
Je reprends ici le désassemblage du code z80 de Mauricio :
; check_if_datas_were_read_ok 06 FF ........ LD B,$FF // Verify : 255 octets 21 FF BF ..... LD HL,$BFFF // Track 40 Sector 7 (read in second place) 11 ED BA ..... LD DE,$BAED // Track 40 Sector 8 (datas in the middle of the long track) .check_loop
Déjà, rien que le fait que la routine indique au FDC que c'est un secteur de 8 pousse ce dernier à avoir un comportement anormal provoqué. Le secteur en question devrait contenir réellement 6155 octets - 8*256 octets = 4107 octets, auquels je retranche les 128 octets du dernier secteur, ce qui donne au final 3979 octets. Mais pas de bol, la zone GAP qui suit les 128 premiers octets ne fait que 1193 octets.
Je suis à l'inverse parfaitement d'accord quand tu dis ceci : "....... surtout, l'endroit exact ou l'on rencontre l'index et ou l'on poursuit la lecture du secteur sur le début de la piste."
c'est la conséquence de la lecture farfelue que l'on demande de faire au FDC. Dans le DSK, cette opération est simulée avec le contenu retourné total afin de passer la protection.
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 59 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
