Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Megachur a écrit :
@Gerald: bilan des tests
Last Mission (F) loriciel_notrailer.7z -> ok, l'écran est correctement centré, le jeu se charge et marche ok !
Pièce jointe :
Last Mission (F) loriciel_notrailer.png
Pièce jointe :
Last Mission (F) loriciel_notrailer1.png
mask_nouveauCDT_fixed.7z -> idem, reset après 1er chargement et compteur à 000 !
Pour last mission, ton émulateur devrait pouvoir le lire AVEC le trailer de fin de bloc. La lecture virtuelle de la "bande" est simplement trop rapide. Le CDT contient une pause exactement de la même taille que celle venant de la cassette.
Ce que tu pourrais faire, idéalement, c'est permettre à ton émulateur de se mettre en écoute du port d'entrée de ligne du PC, ceci afin que l'émulateur puisse lire à la bonne vitesse les données lues par un vrai lecteur de cassette tel que le mien. ça permettrait rapidos que tu puisses avoir une idée précise de la vitesse de base de lecture. Ton émulateur et surement celui de thomas lisent trop rapidement les données
essaie le CDT que j'ai réencodé de Mask, et dit moi si ton émulateur le fait fonctionner (suite à la correction du bug, mon CPC 464+ arrive à le lire).
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
César vient de m'expliquer quel est le problème, et surtout comment le corriger.
je cite : "Il ne faut pas modifier la cassette (le cdt quoi), elle n'est pas en faute. Il s'agit d'un point de vue hardware de mettre le bit "MIC" en silence pendant plusieurs millisecondes (100ms suffit)."
la référence est celle-ci :
"50 ms sont peut-être le minimum absolu, si on utilise 960 bauds comme étant la référence pour exactement 32 instances du BIT1."
Voilà Yoann, tu as les bases en main à présent pour corriger le tir
_________________ SPS Community Expert (SPS CE) / SPS France
A tête reposée, j'ai fait le test suivant : Utiliser le .wav de dlfrsilver, avec la seule modification suivante :
Un decalage de l'arrêt/du démarrage de 240000 ticks (à 4mhz => 60ms)
Ca fonctionne : Le jeu démarre correctement.
Par contre, il n'est pas nécessaire de désactiver l'envoie des donnée sur le PPI (à voir si c'est correct ou non)
EDIT : Au niveau de la vitesse de lecture : On se refère à la WAV. Celle-ci nous donne une certaine vitesse, que l'on utilise via conversion en tick du z80 : On est en principe parfaitement synchronisés avec le hard, avec une précision sans doute supérieur aux tolérances du vrai matériel.
Ce que corrobore ainsi le test fonctionnel de Last Mission
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
A tête reposée, j'ai fait le test suivant : Utiliser le .wav de dlfrsilver, avec la seule modification suivante :
Un decalage de l'arrêt/du démarrage de 240000 ticks (à 4mhz => 60ms)
Ca fonctionne : Le jeu démarre correctement.
Par contre, il n'est pas nécessaire de désactiver l'envoie des donnée sur le PPI (à voir si c'est correct ou non)
EDIT : Au niveau de la vitesse de lecture : On se refère à la WAV. Celle-ci nous donne une certaine vitesse, que l'on utilise via conversion en tick du z80 : On est en principe parfaitement synchronisés avec le hard, avec une précision sans doute supérieur aux tolérances du vrai matériel.
Ce que corrobore ainsi le test fonctionnel de Last Mission
Donc le WAV numérique 100% niquel de last mission fonctionne sous sugarbox avec les bytes du trailer ?
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
César vient de m'expliquer quel est le problème, et surtout comment le corriger.
je cite : "Il ne faut pas modifier la cassette (le cdt quoi), elle n'est pas en faute. Il s'agit d'un point de vue hardware de mettre le bit "MIC" en silence pendant plusieurs millisecondes (100ms suffit)."
La modification du CDT a juste ete faite pour simuler l'effet, par pour le coriger Maintenant, je ne pense pas qu'il soit nécessaire de couper l'entrée du PPI pendant ce temps. De facon generale, une emulation parfaite demanderait de faire varier la vitesse de defilement de la bande pendant les phase d’arrêt et de démarrage, tout en intégrant les effet de cette variation sur le transition de flux. Pour cela il faut caractériser le fonctionnement du couple moteur/relais.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
@Gerald Tout à fait, mais là... bonne chance. Je pense qu'au fur et mesure des 'nouveaux' cdt vous allez trouver une valeur 'par defaut' qui servira de référence pour le bon fonctionnement au niveau émulation. Autant, sur du cdt cracké, on sans fichait, autant sur du cdt original... on est en plein dedans (sans jeux de mot tiens).
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Lone a écrit :
A tête reposée, j'ai fait le test suivant : Utiliser le .wav de dlfrsilver, avec la seule modification suivante :
Un decalage de l'arrêt/du démarrage de 240000 ticks (à 4mhz => 60ms)
Ca fonctionne : Le jeu démarre correctement.
Par contre, il n'est pas nécessaire de désactiver l'envoie des donnée sur le PPI (à voir si c'est correct ou non)
EDIT : Au niveau de la vitesse de lecture : On se refère à la WAV. Celle-ci nous donne une certaine vitesse, que l'on utilise via conversion en tick du z80 : On est en principe parfaitement synchronisés avec le hard, avec une précision sans doute supérieur aux tolérances du vrai matériel.
Ce que corrobore ainsi le test fonctionnel de Last Mission
concernant "Last Mission (F) loriciel.cdt", effectivement en mettant une pause au démarrage du moteur de 45ms, cela fonctionne... cependant, je n'aime pas trop cette approche empirique, il faudrait qu'on ait une idée plus précise...et surtout on ne sait pas si cela ne va pas poser problème sur les autres CDTs !
Pièce jointe :
Last Mission (F) loriciel_00.png
Concernant mask, au vue du code de loader, cela ne semble pas être lié à un problème de démarrage/arrêt moteur
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Citer :
Concernant "Last Mission (F) loriciel.cdt", effectivement en mettant une pause au démarrage du moteur de 45ms, cela fonctionne...
Bien evidemment, puisque c'est ce qui se passe sur un vrai CPC. C'est même pas normal que ça n'ait pas été implémenté dès le début, mais voilà, le souci et tu m'arrêtes si je dis une bêtise, tu n'as pas de vrai CPC chez toi, qui te permet d'avoir une base de travail. Tout ce qui est hardware, tu peux pas le deviner avec rien que du code......
Citer :
Cependant, je n'aime pas trop cette approche empirique, il faudrait qu'on ait une idée plus précise...et surtout on ne sait pas si cela ne va pas poser problème sur les autres CDTs !
ça n'en posera aucun, puisqu'un 464 a cette pause. Les 60ms trouvés par Thomas sont pile poil, vraiment impeccable.
45ms c'est trop juste par contre. 50ms c'est le minimum syndical, avec 45ms, une valeur aussi faible, oui ça risque de poser des soucis potentiels.
Citer :
Concernant mask, au vue du code de loader, cela ne semble pas être lié à un problème de démarrage/arrêt moteur
j'aimerai savoir si vous voyez bien les différence entre le CDT MASK1-UK-700-5100.CDT et celui-ci que je poste ?
Citer :
de plus, puis-je avoir le WAV nettoyé avant conversion en CDT pour évacuer tout problème de calcul de timming sur le cdt ?
Alors..... faut aussi laisser tomber le CDT MASK1-UK-700-5100.CDT, j'ai découvert une couille dans un des blocs, qui empêche le chargement du niveau 3 du jeu.
Cesar est en train de repasser sur la planche de travail pour affiner l'encodage du gremlin loader 3. Les timings sont bons, pas de soucis, c'est vraiment la routine d'encodage qui a besoin d'être affinée.
Ton CDT de Mask ne fonctionne pas, son contenu me rappelle le CDT avec le contenu approximatif que César avait mis au point il y a quelques années de ça, mais ça colle pas :/
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
dlfrsilver a écrit :
Bien evidemment, puisque c'est ce qui se passe sur un vrai CPC. C'est même pas normal que ça n'ait pas été implémenté dès le début, mais voilà, le souci et tu m'arrêtes si je dis une bêtise, tu n'as pas de vrai CPC chez toi, qui te permet d'avoir une base de travail. Tout ce qui est hardware, tu peux pas le deviner avec rien que du code......
bah, oui, je t'arrête tout de suite ! j'en ai même plusieurs chez moi qui marchent tous très bien !
dlfrsilver a écrit :
ça n'en posera aucun, puisqu'un 464 a cette pause. Les 60ms trouvés par Thomas sont pile poil, vraiment impeccable. 45ms c'est trop juste par contre. 50ms c'est le minimum syndical, avec 45ms, une valeur aussi faible, oui ça risque de poser des soucis potentiels.
c'est bien ce que je dis 60 ou 45 et pourquoi pas 50 ou 51 ?!
dlfrsilver a écrit :
Alors..... faut aussi laisser tomber le CDT MASK1-UK-700-5100.CDT, j'ai découvert une couille dans un des blocs, qui empêche le chargement du niveau 3 du jeu.
Cesar est en train de repasser sur la planche de travail pour affiner l'encodage du gremlin loader 3. Les timings sont bons, pas de soucis, c'est vraiment la routine d'encodage qui a besoin d'être affinée.
Ton CDT de Mask ne fonctionne pas, son contenu me rappelle le CDT avec le contenu approximatif que César avait mis au point il y a quelques années de ça, mais ça colle pas :/
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 14 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
