Daniel a écrit :On peut dire que la faisabilité est démontrée, en ce sens que l'on peut déplacer le curseur où on le souhaite et cliquer. Au cours actuel de l'Arduino Pro Mini (1,70 €) + un connecteur DB9 + un connecteur PS/2 + quelques fils et de la soudure, ça fait une interface à moins de 3€, largement compétitive par rapports aux modèles Atari et Amiga du commerce
C'est un des gros avantage de cette solution, et c'est pour cela que je voulais la proposer
Daniel a écrit :Ceci dit, il faut étudier scientifiquement la durée et le décalage des pulsations, sinon la mise au point par essais empiriques risque de durer des mois. Dans la version actuelle les déplacements du curseur sont irréalistes. Ils ne sont pas proportionnels aux déplacements de la souris et ne réagissent pas bien aux changements de vitesse.
Oui tout à fait il fait réussir à être le plus réaliste possible par rapport aux comportements de la vraie souris THOMSON.
C'est pour ca que je ne publie pas encore le code,..
Daniel a écrit :Il y a aussi un point que je n'explique pas : les déplacement latéraux (sens des X) sont presque bons, par contre les déplacements verticaux (sens des Y) sont très mauvais : très rapides si la souris va lentement, mais le curseur se bloque (ou pire : revient en haut de l'écran) si on accélère. Pourtant les mêmes axes, les mêmes roues et les mêmes détecteurs sont utilisés pour les deux axes, les signaux devraient être identiques. Il y a peut-être un problème soft, selon que l'on donne priorité au déplacement en X ou en Y. Il ne faut pas privilégier l'un par rapport à l'autre, en particulier pour permettre des déplacements "en diagonale", et pas en "escalier".
Alors j'ai constaté que le comportement des déplacements en Y avec le montage nécessité de rallonger les délais par rapport au axe X, mais je ne sais pas pourquoi.
par contre je ne comprenais pas au départ pourquoi les diagonales se faisait en "escaliers", mais cette après midi en y repensant j'ai compris (je pense) et c'est tout bête: en modifiant le code pour gérer la vitesse de déplacements j'ai mis des boucle de répétitions, mais le problème c'est que j'envoi XX fois Xa et Xb et après XX fois Ya et Yb, mais il faudrait plutot envoyer XX fois en cadence Xa,Xb,Ya,Yb , non ?
Et je pense que ca va résoudre les problèmes de vitesse aussi
Daniel a écrit :Autre point : la résolution de la souris PS/2. Elle peut varier d'un modèle à l'autre, en particulier les modèles optiques modernes ont souvent une meilleure résolution que les modèles à boule plus anciens. Je ne sais pas si la librairie Arduino prend en compte ce paramètre. Si ce n'est pas le cas, il faudrait l'ajouter dans le programme.
Si tu regarde dans le code dans la partie Setup, j'ai rajouté toute la partie configuration avec la fixation à 200 échantillons par secondes et 8 counts/mm , juste après la détection du type de souris (2 / 3 boutons)
Daniel a écrit : J'ai une idée pour le mode Turbo : pas besoin de faire compliqué, il suffit de doubler le nombre de pulsations et de diminuer leur durée de moitié. Le troisième bouton de la souris n'étant pas exploitable par l'ordinateur Thomson, on pourrait l'utiliser pour basculer du mode normal au mode turbo et inversement.
Au départ j'y avait pensé, mais si jamais on utilise une souris 2 boutons ou si plus tard on veux gérer le 3eme boutons on est bloqué ?
Après on peut l’implémenter comme ca pour faire simple, par rapport à ce que j'ai implémenté !!!