Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Megachur a écrit :
Bon, perso, je voudrais juste réexpliquer quelque chose :
d'abord tous les émulateurs cpc ne sont pas au même niveau d'émulation. je m'explique : on a d'un côté des émulateurs plus proche du vrai hardware, c'est à dire qu'il émule le coeur du cpc, le gate array à 16Mhz, le Z80 à 4 Mhz, l'ay et le crtc à 1Mhz, etc.... C'est le cas de mon emu, et de celui de Lone...
On est bien d'accord vous émulez de façon pointue les différentes puces. Concernant mame, à ce jour précis tu as tord, bizarrement j'ai regardé le driver amstrad cpc de mame, et s'il reste des choses à implémenter, les valeur de clock d'horloge sont à présent les bons. Le GA est bien clocké à 16mhz, le Z80 à 4mhz (mais attention, c'est pas 4mhz réel, puis que ce dernier est ralenti par les états d'attente (wait states) de la RAM).
je cite tiré du driver amstrad CPC de mame :
"/* la clock actuelle du CPU est de 4 MHz, mais elle est ralentie par les accès mémoire. Un HALT est utilisé pour chaque accès mémoire par le CPU. Celà allonge les timings des opcodes, et donne une vitesse effective de 3.8 MHz */
Est-ce que cet effet est bien émulé ?
/* Info au sujet de la structure ci-dessous: L'Amstrad possède un CPU qui tourne à 4 MHz, ralenti par les wait states. J'ai mesuré 19968 instructions NOP par frame, ce qui donne 50.08 fps en taux de rafraichissement tv. Il y a 312 lines sur un écran PAL, donnant 64us par ligne. Il y a seulement 50us de visible par ligne, et 35*8 lignes visibles à l'écran. C'est la raison pour laquelle la zone affichée n'est pas la même que la zone visible. */
et puis de l'autre des ému comme WinAPE et mame par exemple (aller vérifier dans le source de amstrad.c de Mame, j'y étais au commencement et comme dirais quelqu'un, je sais de quoi je parle) ) qui émule tout à 1Mhz ! pourquoi cette approche, parce qu'elle est basée sur une approche de performance et pas forcément sur l'exactitude du hardware !
Justement, regarde ce que j'ai écris au dessus, y a eu de l'eau qui a coulé sous les ponts depuis que tu es intervenu sur le driver, mame gère à présent les puces des machines en 'devices', et les clocks d'horloge sont mesurés. Ce qui était vrai quand tu as mis la main à la patte, mais plus maintenant.....
Citer :
Également, il ne faut pas oublier, qu'on a pas non plus ouvert tous les chipsets pour en faire une belle photo de l'intérieur et du réingénéring propre et compréhensible !!!
C'est bien ce que je disais, vous savez programmer, par contre pour effectivement creuser en profondeur le fonctionnement des puces, c'est au delà de vos compétences, ce qui signifie que vous pouvez tout à fait vous tromper et faire des erreurs dans votre code.
Citer :
Si on prends exemple sur le crtc 6845 par exemple, l'émulation de mame est une catastrophe si on la compare au comportement réel du hardware et des différents types de crtc que l'on connait !
Il faudrait que tu regardes à quel niveau ils en sont en regardant dans le github de mame ou en est l'émulation du CRTC 6845 (edit : je viens de regarder et clairement certains registres ne sont pas encore émulés).
Citer :
une autre anèdocte, quand on a fait le réingénering de l'AY : le doc du constructeur disait le contraire de ce que le hardware faisait exactement l'inverse :
C'est aussi ce que je disais plus haut, c'est pas parce que tu as le schéma qu'il n'est pas exempt d'erreur. Ce que tu dis en est un bel exemple. C'est pour ça qu'il faut avoir un vrai CPC sous la main quand on programme un émulateur, afin de pouvoir comparer chaque chose que l'on met en place, et voir si c'est rigoureusement pareil ou non, et si non, corriger l'émulateur.
Citer :
pour en revenir au sujet qui nous intéresse, notre soucis, c'est que le PPI fourni au programme z80 qui lit le contenu de la K7 des 0 et des 1.
a) Comment on alimente cela ? en lisant le wav ou le cdt fourni en entrée !
par exemple pour traduire un wav en 0 et 1 à 4Mhz pour les fournir au PPI :
un wav c'est à 44100 Hz généralement
donc à un moment, je dois calculer quand je dois envoyer une nouvelle valeur au ppi, pour cela, je calcule :
ce qui donne dans notre cas : 90,702947845804988662131519274376
qui est arrondi pour l'instant dans mon cas !
b) A quoi ca sert ?
a me donner la longueur d'un pulse minimum... en multiple de 4Mhz c'est à dire la plus petite unité à laquelle le PPI sera fourni !
Sauf que comme indiqué plus haut, si l'horloge est clockée à 4mhz, à cause des temps d'attente mémoire, c'est pas 4mhz mais 3.8mhz lol avec étirement des timings des opcodes !
Est-ce que tu en as tenu compte ?
Citer :
je calcule cela car j'utilise le même moteur pour construire ces pulses de 0 ou 1 entre le CDT et le WAV...
pour rappel sur CDT les pulses sont en 3.5Mhz (3.5Mhz (frequency of data in zxtape format)) alors qu'en WAV, c'est moi qui les calculs et les mets en 4.0 Mhz direct !
donc forcément, avec les arrondis, on peut imaginer des différences entre un CDT et un WAV à ce niveau !!!!
ensuite, je regarde en lisant le wave - PCM, si la nouvelle valeur lue est supérieur à 0x80 j'enverrai 0 au ppi sinon j'enverrai 1 au ppi et j'envoie valeur d'une durée qui correspondra à un multiple de 4Mhz !
c) donc si b) est faux, ça a rien à avoir avec l'émulation cpc des composants après, c'est soit le wav qui n'est pas au bon timming soit b) qui n'est pas correctement codé !
A priori b) est la source de l'erreur. La vitesse d'horloge effective du CPC n'est pas 4mhz mais 3.8mhz.
Citer :
ce qui explique qu'on cherche pas forcément un bug d'émulation de composant, mais plutôt dans la préparation des données qui vont être envoyé au cpc.
Ben si c'est un problème d'horloge, c'est un problème d'émulation de composant, ce qui génère forcément un souci dans l'envoi des données envoyées au CPC.
Citer :
--> si on prend l'exemple de mask, j'ai l'ancien cdt qui marche sans pb...ce qui prouve que si on envoie les données au ppi avec le bon timming attendu par le programme z80, celui-ci fonctionne sans pb et donc l'émulation des composants hardware du cpc est ok !
J'ai expliqué que l'ancien CDT de mask que César avait généré était fonctionnel, mais pas rigoureusement exact par rapport au contenu de la cassette d'un point de vue timing.
Le nouveau CDT reproduit exactement ce qui se trouve sur la cassette, que ce soit l'aspect polarité, timings, bordure, midsyncs longues, et ainsi de suite.
Citer :
--> si on prends last mission, l'ancien cdt provoque le même pb de décalage -> cela vient donc soit des calculs timmings (calculé en b)) ou sinon d'autre chose dans l'émulation qui ne fonctionne pas comme attendu !
Clairement, le problème de décalage, j'aurais pu penser que ça pouvait être du à une pause de 0ms. Mais comme la pause au niveau du loader est de 40ms, ça ne peut pas être ça. C'est plus un truc du style données envoyées trop rapidement, résultat, c'est comme si y avait pas de pause entre les 2 blocs du loader, résultat pas le temps de check le premier bloc, que l'émulateur est déja en train de brouter le header du second.
change tes 4mhz en entrée par 3.8mhz, et teste à nouveau last mission et dit moi ce que ça donne.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
Ce que je pige pas, c'est que le premier bloc de 263 octets est suivi d'une pause de 40ms, ensuite y a le bloc de 779 octets, contenant le code en lui-même du loader, puis le CPC éxecute le loader en question, et il y a un temps pendant lequel le z80 du CPC peut traiter, une pause de 6805ms avant d'arriver au bloc du programme principal d'une taille de 64608 octets (65ko quoi).
Les bloc standard sont suivit par un trailer (32 bit à 1), que le firware ignore lorsqu'il lit un de ces bloc. Il arrete le moteur juste après avoir lu le crc. Sur emulateur, comme l’inertie du moteur n'est pas gérée, les bits du trailer sont lu lorsqu'on remet le moteur en marche. Un simple délais entre la commande du moteur et son effet devrais résoudre le problème.
Par contre, si tu peux me transmettre un wav (binaire) de mask, le cdt/csw ne passe pas sur mon 464 après conversion.
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Gerald a écrit :
dlfrsilver a écrit :
Ce que je pige pas, c'est que le premier bloc de 263 octets est suivi d'une pause de 40ms, ensuite y a le bloc de 779 octets, contenant le code en lui-même du loader, puis le CPC éxecute le loader en question, et il y a un temps pendant lequel le z80 du CPC peut traiter, une pause de 6805ms avant d'arriver au bloc du programme principal d'une taille de 64608 octets (65ko quoi).
Les bloc standard sont suivit par un trailer (32 bit à 1), que le firware ignore lorsqu'il lit un de ces bloc. Il arrete le moteur juste après avoir lu le crc. Sur emulateur, comme l’inertie du moteur n'est pas gérée, les bits du trailer sont lu lorsqu'on remet le moteur en marche. Un simple délais entre la commande du moteur et son effet devrais résoudre le problème.
Par contre, si tu peux me transmettre un wav (binaire) de mask, le cdt/csw ne passe pas sur mon 464 après conversion.
Oui je peux te transmettre le WAV binaire de mask. Par contre, la je vais te parler d'un autre problème :
C'est le volume sonore à utiliser sur le PC pour être sur que les données du jeu soient bien perçues par le CPC 464 ou + à l'arrive.
Sur goldwave, j'ai un niveau de son en sortie de 50%, vitesse 1.00, niveau de balance 0% ;
coté windows, le son est poussée sur la sortie haut parleur à 100% (le max quoi).
Une chose très importante : dans les propriétés de "speakers", tu dois aller sur l'onglet "Améliorations" et désactiver toutes les améliorations, c'est à dire le booster de basse, l'effet surround virtuel, la correction de pièce, et l'égalisation du niveau sonore.
ça modifie le son joué, et le déglingue complètement. Ensuite sur l'onglet "niveaux", tu mets le curseur à 98%.
PS : et surtout un grand classique, comme tu vas jouer le WAV depuis ton PC, tu ne fais aucune opération générant du son, c'est à dire mettre et retirer une clé USB, aller sur Youtube pour écouter de la musique, bref, tu laisses le jeu se charger. Par contre autre chose : le playback d'un WAV de jeu CPC, faut vraiment éviter depuis un PC portable, les cartes sons de ces machines sont juste merdiques. Il faut utiliser une vraie bonne carte son sur un PC desktop.
Enfin côté CPC 464, tu baisse totalement la molette de réglage du son sur le côté droit de l'ordi.
Mask doit se charger sans péter les couilles (n'oublie pas de mettre la lecture du WAV en pause quand le chargement des différentes parties s'arrête).
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
je cite tiré du driver amstrad CPC de mame :
"/* la clock actuelle du CPU est de 4 MHz, mais elle est ralentie par les accès mémoire. Un HALT est utilisé pour chaque accès mémoire par le CPU. Celà allonge les timings des opcodes, et donne une vitesse effective de 3.8 MHz
Considérer que le émulateur doivent émuler le Z80 a 3.8MHz, c'est ne rien comprendre au fonctionnement d'un CPC. De 1 : HALT est une instruction Z80, et n'est pas utilisé pour chaque accès mémoire par le CPU. Un WAIT peu être, voir point 2 De 2 : le Z80 se voit appliqué un WAIT 3 cycles d'horloge sur 4 (oui, les 3/4 du temps, le bus mémoire lui est interdit), qu'il y accède ou pas. Ça a pour effet de rallonger le temps effectif cycle constituant les instruction à des multiples de 4. Une gestion des wait state dans l’émulation est indispensable pour une émulation a 100%. Dire que le Z80 tourne a 3.14MHz, c'est une valeur sortie du chapeau et dépend entièrement des instruction utilisé.
dlfrsilver a écrit :
Est-ce que cet effet est bien émulé ?
/* Info au sujet de la structure ci-dessous: L'Amstrad possède un CPU qui tourne à 4 MHz, ralenti par les wait states. J'ai mesuré 19968 instructions NOP par frame, ce qui donne 50.08 fps en taux de rafraichissement tv. Il y a 312 lines sur un écran PAL, donnant 64us par ligne. Il y a seulement 50us de visible par ligne, et 35*8 lignes visibles à l'écran. C'est la raison pour laquelle la zone affichée n'est pas la même que la zone visible. */
Ca c'est vrai uniquement pour l’écran tel que configuré par le firmware au démarrage. Le CRTC étant complétement configurable. Rien n’empêche d'avoir 311 lignes ou 350 ... Et certain jeux sont très loin de respecter ces 312 lignes a 50.08fps.
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
C'est le volume sonore à utiliser sur le PC pour être sur que les données du jeu soient bien perçues par le CPC 464 ou + à l'arrive.
Sur goldwave, j'ai un niveau de son en sortie de 50%, vitesse 1.00, niveau de balance 0% ;
coté windows, le son est poussée sur la sortie haut parleur à 100% (le max quoi).
Une chose très importante : dans les propriétés de "speakers", tu dois aller sur l'onglet "Améliorations" et désactiver toutes les améliorations, c'est à dire le booster de basse, l'effet surround virtuel, la correction de pièce, et l'égalisation du niveau sonore.
ça modifie le son joué, et le déglingue complètement. Ensuite sur l'onglet "niveaux", tu mets le curseur à 98%.
Ça dépend vraiment du PC, chez moi je suis obligé de réduire le volume sinon ça sature avec tout les effets qui vont avec.
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Gerald a écrit :
dlfrsilver a écrit :
C'est le volume sonore à utiliser sur le PC pour être sur que les données du jeu soient bien perçues par le CPC 464 ou + à l'arrive.
Sur goldwave, j'ai un niveau de son en sortie de 50%, vitesse 1.00, niveau de balance 0% ;
coté windows, le son est poussée sur la sortie haut parleur à 100% (le max quoi).
Une chose très importante : dans les propriétés de "speakers", tu dois aller sur l'onglet "Améliorations" et désactiver toutes les améliorations, c'est à dire le booster de basse, l'effet surround virtuel, la correction de pièce, et l'égalisation du niveau sonore.
ça modifie le son joué, et le déglingue complètement. Ensuite sur l'onglet "niveaux", tu mets le curseur à 98%.
Ça dépend vraiment du PC, chez moi je suis obligé de réduire le volume sinon ça sature avec tout les effets qui vont avec.
C'est un sacré souci, tu utilises un PC portable ? Si c'est le cas, cherche même pas, le résultat est proprement dégueulasse :/
Il faut donc que tu mettes le niveau sonore au maximum du possible sur ton PC afin que le CPC ne rate pas une miette de données.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Je confirme que ca dépends du CPC, en faite, de la carte son, pour ma part, si je dépasse les 15%... c'est la cata.
Pour Mask perso après une demi-journée de test sur wav, Impossible à le faire fonctionner sur mon CPC464 J'ai tout essayé ou presque, que dalle.
par contre, j'ai remarqué quelque chose intéressant, si on modifie le facteur de vitesse sous goldwave (qui donc a 1.00 normalement) Ca joue énormément sur le compteur qui est affiché sur l'écran de chargement (sur le cpc donc). Par exemple, voila ce que ca a donné chez moi.
Normalement, à 1.10s il devrait etre a 0 à l'ecran et afficher une page du jeux. Sauf que... chez moi, BOOM, reboot Comme indiqué sur le petit tableau, ca plante a x minute selon la modification que je fait sur le facteur de vitesse de lecture. Sais pas trop si ca fait avancer le chmiblique mais bon.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Quelques resultat de test en live qu'on fait avec denis.
Chargement de Last_Mission_F_loriciel.wav (donné plus haut) sur un CPC464 via goldwave et lecteur K7 elect.
Marche pas...Peu importe le volume de son de mon PC j'ai tjs un décalagé de l'image au chargement et a la fin, click du relais mais ecran noir.
SAUF QUE, maintenant, si on modifie le facteur de vitesse de goldwave disons a 2.00 au lieu de 1.00 (donc 2 fois plus vite) Re-chargement du jeux et...
BIM, ecran bien centrée et le jeux se charge ET se lance.
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Giants a écrit :
Quelques resultat de test en live qu'on fait avec denis.
Chargement de Last_Mission_F_loriciel.wav (donné plus haut) sur un CPC464 via goldwave et lecteur K7 elect.
Marche pas...Peu importe le volume de son de mon PC j'ai tjs un décalagé de l'image au chargement et a la fin, click du relais mais ecran noir.
SAUF QUE, maintenant, si on modifie le facteur de vitesse de goldwave disons a 2.00 au lieu de 1.00 (donc 2 fois plus vite) Re-chargement du jeux et...
BIM, ecran bien centrée et le jeux se charge ET se lance.
Le truc super bizarre, c'est que sur mon PC sous goldwave en vitesse 1.00, Last Mission se charge.......
question, qui peut à l'aide de Goldwave tester le WAV via une cassette digitale ?
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
Le truc super bizarre, c'est que sur mon PC sous goldwave en vitesse 1.00, Last Mission se charge.......
question, qui peut à l'aide de Goldwave tester le WAV via une cassette digitale ?
Last mission passe chez moi avec un wav derivé du cdt avec tzx2wav. Volume principal a 50%, wave (avec Audacity) a 50% Avec un volume plus faible, ça ne passe pas : écran décalé
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Gerald a écrit :
dlfrsilver a écrit :
Le truc super bizarre, c'est que sur mon PC sous goldwave en vitesse 1.00, Last Mission se charge.......
question, qui peut à l'aide de Goldwave tester le WAV via une cassette digitale ?
Last mission passe chez moi avec un wav derivé du cdt avec tzx2wav. Volume principal a 50%, wave (avec Audacity) a 50% Avec un volume plus faible, ça ne passe pas : écran décalé
tu n'as pas utilisé le WAV de last mission que j'ai mis en PJ ?
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
Gerald a écrit :
dlfrsilver a écrit :
Le truc super bizarre, c'est que sur mon PC sous goldwave en vitesse 1.00, Last Mission se charge.......
question, qui peut à l'aide de Goldwave tester le WAV via une cassette digitale ?
Last mission passe chez moi avec un wav derivé du cdt avec tzx2wav. Volume principal a 50%, wave (avec Audacity) a 50% Avec un volume plus faible, ça ne passe pas : écran décalé
tu n'as pas utilisé le WAV de last mission que j'ai mis en PJ ?
On discute tellement que j'ai pris les premier fichiers rencontré (dct/csw) . Je viens de le repéré page 65 !
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
teste le et dis-moi ce que ça donne chez toi
Il passe aussi, dans les même condition.
Avec un volume identique au test de LastMission : Le Wav que tu a fournis plante des le début du premier bloc Avec un wav tiré du cdt avec Tapir, le plantage se fait à la fin du premier bloc (en fait au début du second), il manque un sous block.
Je vais regarder le loader pour voir ce qu'il attend
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 17 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
) qui émule tout à 1Mhz ! pourquoi cette approche, parce qu'elle est basée sur une approche de performance et pas forcément sur l'exactitude du hardware !
. 