forum.system-cfg.com

Merci pour cette nouvelle version.

par contre les manettes ne fonctionnent pas ou j'ai pas compris comment ( jolie la petite fenêtre "manettes" )
Testé en mode TO8D green beret et MO5 krakout / green beret ?

C'est un autre sujet, pour des fonctions encore non documentées dans cette version provisoire (clavier et manettes graphiques).
Je viens de tester la boîte de dialogue "Manettes" avec la version disquette TO8 de Green Beret. Chez moi tout fonctionne bien : clic sur Action de la manette 0 (bouton jaune à droite) pour démarrer le jeu, clic sur les directions pour avancer, sauter, s'accroupir, etc...

Curieux chez moi ca ne fonctionne pas

Bon c'est un autre sujet donc nous n'allons pas polluer ce fils de discussions ....

Ca a l'air mieux. En mode TO8 j'ai un pic mesuré à 2.741khz, pour un pic théorique de 1000000/181/2=2.762khz. Donc ok pour le TO8.

Bizarrement en mode TO7 le pic mesuré est à 1.804khz avec le même code! Etrange.... KO pour le TO7. Tu as une idée de la différence entre TO7 et TO8 ? C'est du code partagé entre les deux coeurs d'emuls ou pas ?

Sinon concernant l'affichage d'un crayon optique comme souris windows, c'est bien quand on a choisi le crayon optique dans les prefs du TO8, mais si on a choisi que la souris remplace le crayon optique dans les prefs thomson (bit 7 de $6073 à 1), je me serais plus attendu à voir une icône de souris (ou un truc tout léger style simple croix/réticule) plutôt qu'un crayon optique.

C'était donc bien lié à la non remise à zéro du bit CSR0. Merci pour la confirmation
La modification a été faite pour TO8/TO8D/TO9+, mais pas encore pour les autres TO. Le 6846 est câblé de façon différente selon les machines, et chacune utilise un code spécifique. C'est encore faux pour le TO7, le TO7/70 et le TO9 : ces machines ont toujours le bit CSR0 à 1. Je vais réparer cela dans les jours prochains.

L'émulateur n'affiche plus de curseur pour la souris, puisque l'ordinateur Thomson affiche le sien. C'est pour éviter de mélanger les deux curseurs, à la demande de 6502man pour le jeu Secte Noire. Pour supprimer le curseur du crayon optique, il suffit de le désactiver dans les options de dcmoto. Je ne peux pas me fier au choix de la souris, car elle n'existe pas pour les machines de première génération.

Sur la vraie machine on voit le crayon optique placé devant l'écran, même s'il n'est pas sélectionné. Pour ne plus le voir il faut le placer hors des limites de l'écran ou le déconnecter et le ranger dans sa boîte. Avec dcmoto c'est pareil, il disparaît s'il pointe en dehors de l'écran ou si on le désactive dans Options/Paramètres.

Daniel a écrit :C'était donc bien lié à la non remise à zéro du bit CSR0. Merci pour la confirmation
La modification a été faite pour TO8/TO8D/TO9+, mais pas encore pour les autres TO. Le 6846 est câblé de façon différente selon les machines, et chacune utilise un code spécifique. C'est encore faux pour le TO7, le TO7/70 et le TO9 : ces machines ont toujours le bit CSR0 à 1. Je vais réparer cela dans les jours prochains.

C'est surprenant que sur TO7 le CSR0 soit toujours à 1, car la fréquence entendue serait bien supérieure à 1.8khz. Or sur TO7 la D7 de test jointe à un message précédent joue de façon beaucoup plus "grave" (1.804khz mesuré) que le TO8 quand ce dernier avait aussi le CSR0 à 1.

Sur la vraie machine on voit le crayon optique placé devant l'écran, même s'il n'est pas sélectionné. Pour ne plus le voir il faut le placer hors des limites de l'écran ou le déconnecter et le ranger dans sa boîte. Avec dcmoto c'est pareil, il disparaît s'il pointe en dehors de l'écran ou si on le désactive dans Options/Paramètres.

Pourquoi pas effectivement. Il faut s'habituer au changement.

Nouvelle version provisoire de dcmoto, avec correction du bit CSR0 (interruption timer) pour tous les TO :
http://dcmoto.free.fr/emulateur/prog/dc ... 140706.zip

Les versions provisoires 20140703, 20140704 et 20140705 ont été supprimées (les liens des posts précédents ne fonctionnent plus).

oui ca a l'air parfait pour mon prog de test (ci-joint).

Il positionne le timer à 64*13µs, ce qui correspond exactement à 13 lignes d'écran. Or 13 est un diviseur exact des 312 lignes verticales. Du coup on doit voir des barres colorées stables sur le tour, et entendre une note à 601Hz (= 1000000/(2*64*13))

Ce test permet en outre de différencier les émulateurs émulant le tour au niveau ligne à ligne ou au niveau image complète.

A partir de la version 2017.07 (et toutes les versions suivantes) le problème est réapparu, les lignes ne sont plus fixes mais avancent avec le code de sam.
Sur les versions 2015.05 et 2015.06 ça fonctionne.

Une idée ?

J'ai une petite idée, mais sans aucune preuve car je n'ai pas encore regardé.

A l'époque, en 2014, je n'ai pas trouvé la cause exacte du problème et j'ai triché dans le décompte du timer pour qu'il n'y ait plus de décalage dans le programme de __sam__.

Ensuite il y a eu des dizaines de versions successives de dcmoto, avec en particulier une refonte partielle de l'émulation du 6846 et la correction du nombre de cycles de l'instruction CMPX indexé. Il est possible que le bug de départ ait été corrigé par ces modifications, et c'est le correctif de la version 20140706 qui provoque l'erreur. Il suffit peut-être de le supprimer.

Mais ce n'est qu'une supposition, je vais vérifier...

ça me semble être une bonne piste en effet, bonne idée.
Si j'utilise la nouvelle fonction comptage de cycles entre points d'arrêt et que je positionne ce point d'arrêt sur la fonction branchée sur l'IRQ pour un timer positionné à 19944/8 (prescale à 0), on a un IRQ qui branche tous les 19900, 19976, 19962, 19969 cycles. ça fluctue entre ces 4 valeurs avec une dominante à 19969 cycles.

Je viens de "survoler" la datasheet du 6846 ... c'est effectivement pas simple.
D'ailleurs ça m'a permis de comprendre pourquoi dans le code de sam la valeur de timer n'était pas divisée par 8 quand il la renseigne:
Il paramètre le registre timer ($E7C5) avec le prescale à 1 (bit2) ce qui divise la fréquence du timer par 8.

Je n'ai pas forcement compris tous les modes dispo ... il y a peut être des choses à faire avec.
Pour le moment tout ce qui m'intéresse c'est d'avoir un IRQ stable et calé sur chaque rafraichissement d'écran.
Pour ça, le timer doit être positionné à 312*64-24 (lignes*cycles_par_ligne-nombre_mystere)
Il me reste juste à comprendre a quoi correspond ce nombre mystère ...

Mon intuition, pour une fois, a été bonne. Voici l'histoire :

En 2012, Tomix a découvert un décalage de 8 cycles dans le comptage du timer : https://forum.system-cfg.com/viewtopic.php?t=4184

Dans dcmoto, en appliquant ce décalage de 8 cycles, il y avait encore une petite différence de fréquence. A l'époque je n'ai pas trouvé pourquoi, alors j'ai corrigé par essais successifs. J'ai finalement mis un décalage de 18 cycles pour obtenir la bonne fréquence.

Quelques années plus tard j'ai fait une refonte complète de l'émulation du 6846, et je l'ai améliorée au fil des versions jusqu'en 2021. Très récemment j'ai corrigé aussi une erreur d'émulation du 6809, le nombre de cycles de l'instruction indexée CMPX était faux, je l'ai passé de 4+ à 6+. Et je n'ai pas modifié le décalage du timer, qui est resté à 18 jusqu'à la version 2021.03.12. C'est ça l'erreur.

A l'instant je viens de recompiler avec un décalage de 8 cycles et les bandes latérales du programme de __sam__ ne bougent plus. Je prépare la nouvelle version 2021.03.16 de dcmoto pour la mettre en ligne dans la journée à http://dcmoto.free.fr/emulateur/index.html

Merci à Bentoc d'avoir trouvé et signalé ce bug !

Je suis toujours impressionné par la vitesse à laquelle les bogues sont corrigés. En une matinée c’est réglé...Bravo Daniel. Et ça fait un patch en moins dans la code, c’est toujours ça de pris

Merci Daniel, c'est une très bonne nouvelle