[Thomson TO8/9/9+] PRA/DDRA CRA et port manettes ?

[Daniel]

Ne vous fiez pas trop à dcmoto pour la lecture du clavier. La gestion du clavier TO8 est un domaine complexe que je ne maîtrise pas totalement, il y a peut-être des différences de comportement par rapport à la vraie machine.

[6502man]

SAm: voici une version FD :

TEST.zip

(182 octets) Téléchargé 110 fois

Daniel : j'ai le même comportement sur machine réel TO8D !!!

[Daniel]

Alors ton malheur fait mon bonheur : ça veut dire que dcmoto n'est pas trop mauvais dans l'émulation du clavier. C'est une sorte de miracle, car c'est vraiment très complexe.

Je pense que le problème doit venir de bits de masquage des interruptions clavier dans le registre d'état composite et le registre de contrôle périphérique port C du 6846. Mais je ne peux pas t'expliquer car je n'ai pas tout compris.

Ton programme doit bien fonctionner sur TO7/70. Au contraire du TO8, les machines de première génération gèrent directement le clavier et réagissent beaucoup plus vite. Sur TO8/TO8D/TO9+ les manettes sont obligatoires pour tous les jeux d'action, alors que sur MO5 et TO7/70 il y a souvent une option de jeu au clavier. C'est certainement lié au problème que tu viens de mettre en évidence.

[Edit]
J'ai trouvé le problème : remplace BCC par BEQ et ça marchera nettement mieux
Comme quoi le manuel technique n'est pas exempt d'erreurs. Mieux vaut aller voir la ROM pour connaître la vérité. C'est ce que je viens de faire.

[__sam__]

Daniel : j'ai le même comportement sur machine réel TO8D !!!

Je suis perdu tu as le même comportement en émulation TO8D et sur vrai TO8D ? Mais ce comportement c'est quoi: clavier anémique ou clavier ok (chez moi en emul le clavier me semble OK.)

Daniel a mis au jour un bug dans la doc car la carry n'est pas forcément positionnée à 1 semble-til. Moi aussi ce BCC m'avait fait tiquer, car j'utilise BEQ, mais comme la doc indique que C est positionné, je me suis dit que ton code devrait être correct. J'avoue que GETC qui retourne C ne me dit franchement rien, mais comme à l'inverse une expérience récente sur MO5 m'a montrée que KTST sur MO5 positionne B, pourquoi est-ce que GETC sur TO ne positiionnerait il pas Carry ?

En tout cas la bonne approche qui marche sans soucis (et qui est plus rapide car GETC est lent) est d'appeller KTST en premier. Si la carry est positiionnée alors GETC retournera un caractère. Sinon on peu boucler sur les KTST.

[6502man]

Ah oui c'est carrément mieux

Si même la doc technique si met, je vais avoir besoin de courage

merci Daniel.

Sam: j'avais pensé aussi à cette solution mais je trouvais un peu "lourd" de devoir passer par 2 routines moniteur pour n'attendre que l'appuie d'une touche

[6502man]

D'après la DOC technique en page 229 il est indiqué une plage d'indirection en RAM des routines moniteur.

Je ne suis pas sur d'avoir compris si cette indirection est faite avant ou après exécution des routines moniteur ?

[__sam__]

Fais gaffe avec le GETC.. il est méchamment lent sur certaines machines.

Mon player de musique rammait grave avec DCMOTO en mode TO7 par rapport au même code sur TO8 ou TO9... J'avais soumis le bug à Daniel qui a tout de suite compris que la lenteur n'était pas dans l'émulation, mais dans la routine moniteur. En effet il scanne l'ensemble des lignes du clavier une à une pour trouver les touches enfoncées. Pour KTST il est bien plus rapide: il active toutes les lignes en sortie et lit la valeur du port en entrée. Si une touche (ou plusieurs) sont enfoncées en entrée on trouve un truc non nul. Bref KTST est vraiment bien plus rapide que GETC.

Sinon pour les jeux c'est en partie liée à ca. Dans les jeux il est important de pouvoir utiliser les diagonales, c'est à dire l'appui simultané sur eux touches. Sur TO7 c'est assez facile à détecter, mais sur TO9 le clavier est géré par un CPU séparé qui fait lui même la routine de scan et envoie directement par liaison série le code de la touche lue. Je dis bien la car sur TO9 on ne peut pas détecter l'appui sur deux touches simultanément. Je présume que sur les machines suivantes (TO9+ et TO8) c'est le même topo. Du coup les jeux ayant besoin des diagonales ne peuvent utiliser que le joystick sur TO9 et TO8.

Je pense que sur MO6 ils ont gardés la même technologie que sur TO7/MO5 et du coup on peut détecter l'appui simultané sur plusieurs touches. Par exemple M O 6 (à faire appuyer sur le menu par ceux qui ne connaissent pas.. ca fait toujours son petit effet un easter-egg pareil sur du 8bit ).

Pour l'indirection c'est avant. Ca permet de remplacer l'appel à GETC par son propre code. Dans la version de Capitaine Blood que j'avais hackée étant jeune je l'avais détournée pour utiliser le joystick en lieu et place du clavier. (le clavier est pénible, l'auto-repeat n'est pas immédiat, et il est relativement lent. Avec une routine qui remappe le joystick sur une direction clavier on a plus ces problèmes).

[Daniel]

Pour revenir sur le choix entre BCC et BEQ après GETC :
- Le bit Z du code condition indique qu'il n'y a pas de touche en attente. S'il y a une touche en attente le bit Z est à zéro.
- Le bit C du code condition indique que le buffer clavier a débordé. Si le buffer n'est pas plein le bit C est à zéro

En utilisant BCC, on boucle tant que le buffer n'a pas débordé. C'est pourquoi il faut lourdement insister sur le clavier.

En utilisant BEQ, on boucle tant que le buffer est vide, et on sort de la boucle dès qu'une touche est détectée.

[__sam__]

Ah! Tout est clair à présent. Merci Daniel.

Dans la pratique, je me demande quel peut être l'intérêt de savoir que le buffer a débordé. Cette info sert à quoi au juste ?

[EDIT] c'est quant même curieux que ni le manuel technique TO7 ni celui du TO8/9/9+ ne mentionne le rôle de Z et C en retour de GETC. Tout juste C est il indiqué dans le manuel tech du TO8, mais sens indiquer ce qu'il signifie.

[Daniel]

Les codes ASCII des touches frappées sont stockés dans un buffer circulaire dont l'adresse est en $6079 et la taille en $607B (par défaut 4 caractères). Si les touches ne sont pas traitées par le programme, le buffer circulaire se mord la queue, on perd donc une ou plusieurs frappes. C'est intéressant de le savoir, mais on ne peut pas faire grand chose car les touches perdues ne sont pas récupérables.

Je crois qu'on peut définir un buffer plus grand en modifiant $6079-$607B, mais je n'ai jamais essayé.

Cette gestion du clavier est totalement différente dans les machines de première génération et dans le MO6 : elles n'ont pas de buffer, le programme peut tester à tout moment chaque contact. La routine GETC scrute successivement tous les contacts, c'est donc relativement long et rarement nécessaire dans les jeux d'action. Il est plus astucieux de ne pas utiliser GETC et de scruter uniquement les touches qui nous intéressent, par exemple les quatre flèches et la barre d'espacement. C'est au moins dix fois plus rapide.

[6502man]

Merci pour ces précisions tout est beaucoup plus clair une fois que Daniel l'explique

Oui il est certain que pour les jeux on ne va pas utiliser la routine système
Mais dans le cas présent c'était juste pour faire un bête test avec appuie sur une touche quelconque en séquence.

Pour les indirections ça peut être très pratique pour certains cas

[6502man]

Je viens d'essayer une indirection sur PUTC $6008 c'est très simple à mettre en place

[6502man]

J'ai essayé de faire fonctionner un module électronique connecté au port joystick mais cela ne fonctionne pas, car c'est du côté du module que cela n'est pas aussi simple que je l'aurais cru, et j'ai était un peu présomptueux de mes capacité en la matière


C'est pas grave, du coup je viens juste de me lancer sur un autre bricolage et cela devrait fonctionner pour la visu ( je fait monter le suspens) ....