interruption clavier et voyage 200 - Page 1

Bonjour !

Tout d'abord merci à tous pour les excellents posts que l'on peut trouver ici !
J'ai commencé un projet en assembleur pour ma TI V200 (AMS 3.01) et je suis en pleine période de frustration aigüe .
Pour tester mon programme j'utilise vti avec une ROM de TI 92+ AMS 2.04. En effet, j'avais essayé tiemu qui m'avait permis d'utiliser la ROM de ma propre V200 mais depuis une mise à jour du paquet (je suis sous linux) je ne peux plus utiliser le soft (problème de dépendances avec des libs).
Bref, j'en viens à mon problème.
Je cherche à placer un handler perso au niveau de l'autoint2 pour gérer le clavier dans un jeu.
Je place des rte pour les autoint1, 4 5 et 6 et mon handler perso sur la 2.
Au début du prog je masque les int avec 011 (jusque niveau 2 inclus donc), je démasque ensuite le tout avant ma boucle de jeu avec 001 (j'ai aussi essayé avec 000 mais pas de différence notable, je ne sais pas vraiment quelle devrait être la différence entre les deux).
Je réapplique à nouveau 011 après la boucle de jeu jusqu'à la fin du programme où je rétablis tout comme je l'ai trouvé au début.
Pour le moment la boucle de jeu se présente comme ça:

...
boucle:
bra boucle
fin:
...

L'handler que je place au niveau de l'autoint2 dessine sur l'écran en fonction des touches appuyées. Si l'on appuie sur la touche hand, je change l'adresse de retour du handler au label fin de sorte à quitter.
Tout ceci fonctionne très bien sur vti.

Mais ça freeze complètement ma V200 ! Du coup j'ai essayé de placer le même handler sur l'autoint1 au lieu du 2, et ça fonctionne, mais ça ne me paraît pas propre et je voudrais utiliser l'autoint 2. Je ne comprends pas pourquoi ça ne marche pas sur ma V200 . Pour info je place mon vecteur en $40068.

J'espère fortement que vous pourrez m'aider ou me donner des pistes.

PS: j'ai préféré ne pas mettre de code pour le moment car je me dis que peut-être une particularité de la V200 est déjà connue là-dessus. Bien sûr, je peux poster des bouts de code.

Salut!

Merci beaucoup Folco pour tes réponses!
Alors je ferais donc mieux de me satisfaire de l'int1.
J'ai téléchargé J89hw.txt mais je ne suis pas sûr que ce soit la dernière version. En tout cas merci de l'info!
Merci aussi pour le lien vers le code! Je n'ai fait que jeté un oeil très très rapide je regarderai plus tard.

Pour info, je programme en nostub, j'aurais dû le préciser.

Folco (./3) :

bode_sephiroth (./1) :
Pour info je place mon vecteur en $40068

hum... l'int 1 est à $64, donc là c'est la 2.

En effet c'est bien la 2, je voulais dire que je place mon vecteur là dans le cas où ça ne marche pas.

Folco (./3) :
Ton masque alakhon marcgait sur les hw1 (ghostspace), mais t'es baisé sur les hw2+. La version correcte pour écrire un vecteur est de mettre à zéro $600001:2, écrire le vecteur, puis remettre le bit à 1. Ton hack ne marche que sur les tous premiers HWs...

En fait comme tu le verras plus bas je fais ça aussi. Je pensais cependant utiliser les masques aussi pour pouvoir contrôler à quel moment mon handler devient actif et à quel moment je l'inhibe. En effet, comme je change l'adresse de retour si appui sur 'hand', ça fout la merde si mon handler intervient en dehors de la boucle de jeu (et c'est pas beau si ça arrive).
Sinon pour la différence 000 ou 001, il y en a vraiment une?

Folco (./3) :

bode_sephiroth (./1) :
PS: j'ai préféré ne pas mettre de code pour le moment car je me dis que peut-être une particularité de la V200 est déjà connue là-dessus. Bien sûr, je peux poster des bouts de code.

Heu, ici, on est plutôt d genre généreux, et le code est passé de l'un à l'autre pour la bonne cause, t'inquiète pas de ce que adviendras ce que tu as écris si c'est ça qui te fait peur

Pas de problème pour le code! C'est juste que j'avais peur que fasse lourd et en plus je me disais que ce n'était peut-être pas nécessaire. Mais c'est sûr que c'est toujours mieux d'avoir le code sous les yeux, alors voilà les parties intéressantes:
(j'ai coupé des morceaux pour plus de clarté)

	include "OS.h"
	xdef _nostub
	xdef _ti92plus

;------------------------------------------------------------------------
;--masquage des interruptions

	trap #12

	;tester la valeur du masque avant modif
	;et la sauvegarder pour restauration à la fin

	clr.l d0
	btst.w #8,SR
	beq masque_neuf
	addq.b #%1,d0
masque_neuf:
	btst.w #9,SR
	beq masque_dix
	addq.b #%10,d0
masque_dix:
	btst.w #10,SR
	beq masque_ok
	addq.b #%100,d0
masque_ok:
	move.b d0,-(a7)

	ori.w #%0000001100000000,SR
	;            ^^^ 
	;on masque jusqu'a trois pour eviter des probs en debut de prog

;------------------------------------------------------------------------
;	on déroute les interruptions suivantes:
;       int1: barre en bas de l'écran entre autres
;       int2: clavier...
;	int5: timer programmable
;	int4: port I/O
;	int6: appui sur ON
;	RQ: il faut garder int3 : c'est le timer de la clock...
;

	bclr.b #2,($600001) ;on enlève la protection en écriture
     
	;déroutage int1
	move.l #$40064,a0
	lea Int1(pc),a1
	move.l (a0),(a1)
	lea fake_int(pc),a1
	move.l a1,(a0)

	;déroutage int2
	move.l #$40068,a0
	lea Int2(pc),a1
	move.l (a0),(a1)
	lea clavier(pc),a1
	move.l a1,(a0)

	;déroutage int4
	move.l #$40070,a0
	lea Int4(pc),a1
	move.l (a0),(a1)
	lea fake_int(pc),a1
	move.l a1,(a0)
	
	;déroutage int5
	move.l #$40074,a0
	lea Int5(pc),a1
	move.l (a0),(a1)
	lea fake_int(pc),a1
	move.l a1,(a0)

	;déroutage int6
	move.l #$40078,a0
	lea Int6(pc),a1
	move.l (a0),(a1)
	lea fake_int(pc),a1
	move.l a1,(a0)
	
	bset.b #2,($600001)
	andi.w #%1101111111111111,SR ;on remet à 0 le bit superviseur


;------------------------------------------------------------------------

[...sauvegarde et effacement de l'écran, allocations de mémoire...]

;------------------------------------------------------------------------

[...affichage d'un dessin et d'un sprite avec des macros persos. Je l'ai ai vérifiées elles fonctionnent pas de problème ici...]


	trap #12
	andi.w #%1101100111111111,SR
	;             ^^^
	;on demasque les int et on repasse en user
boucle:

	bra boucle
;--fin de boucle------------------------

fin:
	trap #12  ;passage en superviseur
	ori.w #%0000001100000000,SR
	;            ^^^ 
	;on remasque les int pour eviter des ennuis...
	andi.w #%1101111111111111,SR ;on remet à 0 le bit superviseur


;------------------------------------------------------------------------

[...restauration de la mémoire allouée et de l'écran...]

;------------------------------------------------------------------------
;--remise en place des interruptions déroutées

	trap #12  ;passage en superviseur
	bclr.b #2,($600001)
     
	;remise en place de int1
	move.l #$40064,a0
	lea Int1(pc),a1
	move.l (a1),(a0)
	
	;remise en place de int2
	move.l #$40068,a0
	lea Int2(pc),a1
	move.l (a1),(a0)

	;remise en place de int4
	move.l #$40070,a0
	lea Int4(pc),a1
	move.l (a1),(a0)
	
	;remise en place de int5
	move.l #$40074,a0
	lea Int5(pc),a1
	move.l (a1),(a0)

	;remise en place de int6
	move.l #$40078,a0
	lea Int6(pc),a1
	move.l (a1),(a0)
     
	bset.b #2,($600001)
	;andi.w #%1101111111111111,SR ;on remet à 0 le bit superviseur
					;on repasse donc en utilisateur

;------------------------------------------------------------------------
;--démasquage des interruptions

[...on remet en place le masque trouvé au début du programme...]

;------------------------------------------------------------------------
;--fin du prog

	rts

			;--------------------------!
			;--------------------------!

;------------------------------------------------------------------------
;--fake handler
fake_int:
	rte


clavier:	

	move.b #%11111110,$600019
	nop
	nop
	nop 
	nop
	move.b $60001b,d0     ;lecture du byte de sortie du port
	                        ;correspond aux colonnes

	tst.b d0
	beq fin_clavier
	btst #6,d0    ;flèche droite? (droite)
	beq droit
	btst #4,d0    ;flèche gauche? (gauche)
	beq gauche
	btst #7,d0    ;flèche bas? (descente rapide)
	beq bas
	btst #5,d0    ;flèche haut? (descente instantannée)
	beq haut

	btst #3,d0    ;hand? (quitter)
	beq sortie
	bra fin_clavier

;--flèche droite-----------------------
droit:

[...on deplace le sprite correctement...]

	bra fin_clavier
;--fin droite---------------------------

[...de même pour les trois autres directions...]
	
fin_clavier:
	rte
sortie:
	;on va changer l'adresse de retour
	;on va revenir au label fin, apres la boucle de jeu
	;l'adresse est à mettre après un
	;word sur la pile qui est une sauvegarde du SR avant int je crois
	lea.l fin(pc),a0
	move.l a0,2(a7)	;on écrit donc la new adresse en 2(a7)
	rte


;-----------------------------------------------------------------------!
;				SECTION DATA				!
;-----------------------------------------------------------------------!
	section ".data"

	Int1: dc.l 0
	Int2: dc.l 0
	Int4: dc.l 0
	Int5: dc.l 0
	Int6: dc.l 0
[...et d'autres trucs dont le sprite...]

Je vois bien que tu programmes pour ta V200... mais au cas où tu voudrais étendre ce programme aux autres modèles: l'utilisation des adresses à 0x40000 fonctionne sur V200 et antérieures, mais pas sur 89T.

Salut!

A vrai dire je n'avais pas vraiment encore songé au problème de savoir sur quels modèles le programme pourrait tourner, ni même vraiment à sa distribution. C'est en fait mon premier programme assembleur et mon but principal est donc surtout de faire de l'assembleur.
Mais ça pourrait être intéressant de le distribuer si je le finis, encore que ça doit déjà exister en pas mal de versions (je veux faire un tetris).
J'en profite donc pour te demander deux trucs :
-comment détecter le modèle de calculatrice sur lequel le programme tourne?
-comment fait-on sur hardware3 (c'est bien le cas de la 89T ?) pour placer ses propres handler?
ah et aussi quelle différence entre les masques 000 et 001 pour les interruptions?

-comment détecter le modèle de calculatrice sur lequel le programme tourne?

Traditionnellement, on utilise par exemple:
* ROM_base, qui est actuellement l'adresse de la table des ROM_CALLs AND 0xE00000 (move.l 0xC8.w,dn; and.l #0xE00000,dn). Vaut 0x200000 sur 89 et V200, 0x400000 sur 92+ et 0x800000 sur 89T. ROM_base est utilisée dans les lanceurs spécifiques pour programmes compressés générés par TIGCC (pstarters) et le lanceur générique ttstart.

* le Hardware Parameter Block (voir FL_getHardwareParmBlock et HARDWARE_PARM_BLOCK dans la doc), dont le field hardwareID donne le modèle. De mémoire (la doc de TIGCC, six ans après la sortie de la V200 et quatre ans après celle de la 89T, ne contient pas l'info), les valeurs de ces 32 bits pour V200 et 89T sont respectivement 8 et 9.

On peut aussi vouloir détecter VTI spécifiquement, pour s'accomoder de ses manques (routines de grayscale) ou pour rendre plus difficile à un utilisateur de VTI le reverse-engineering (XPand et HW3Patch - ces deux-là ne sont pas fournis avec le source, parce que mal utilisé, le source est dangereux). TIEmu n'a ni le bug qui permet de détecter VTI, ni les bugs de VTI qui rendent plus difficile le reverse engineering de XPand et HW3Patch.

-comment fait-on sur hardware3 (c'est bien le cas de la 89T ?) pour placer ses propres handler?

Depuis 2004, sur tous les modèles (parce que c'est plus petit de faire comme ça que de détecter si on est sur 89T ou pas), TIGCC désactive et active la protection en écriture ('Protected Memory Violation', AUTO_INT_7) de la zone 0x0-0x11F (table des vecteurs):
#define SetIntVec(i,h) ({asm volatile ("bclr.b #2,0x600001");(void) (*(INT_HANDLER*)(i) = (h));asm volatile ("bset.b #2,0x600001");})

ah et aussi quelle différence entre les masques 000 et 001 pour les interruptions?

000 = toutes les interruptions activées.
001 = toutes les interruptions sauf AUTO_INT_1.
006 = toutes les interruptions désactivées, y compris la touche ON (AUTO_INT_6). Même si en fait, la touche ON est un peu plus compliquée que ça, voir j89hw.txt.
007 = dans les faits, pareil qu'AUTO_INT_6, parce qu'AUTO_INT_7 (protection de la table des vecteurs) est une Non Maskable Interrupt sur un 68000.

Et sinon, je conseille d'utiliser plutôt GNU as, parce que A68k pourrait bientôt disparaître de TIGCC pour des raisons de licence. Il sera toujours possible de le télécharger séparément, mais il n'est pas prévu d'y apporter des améliorations de fonctionnalités. À la limite des corrections de bogues, mais je suis limité par la compatibilité antérieure, par exemple pas mal de sources s'attendent à ce que A68k accepte des instructions inexistantes comme MOVEQ.W (il interprète ça comme un MOVEQ.L, la seule taille valide pour un MOVEQ). Et puis franchement, le fait que la syntaxe de A68k dépend de l'indentation est lourd.

Mais arrete avec ça... Personne n'en veut du GNU ass et sa syntaxe inchiable et inhabituelle. Tu crois que les gens vont changer leurs habitudes et s'y mettre du jour au lendemain? On s'en BLC des licenses dans un monde si restreint d'amateurisme, personne ne viendra nous embêter, et c'est surtout bête de se prendre la tête à cause d'un si petit "problème de licence".

Je ne dis pas que tu as tort, mais tu n'étais pas obligé de répondre au flamebait de Kevin, onur

onur (./9) :
Mais arrete avec ça... Personne n'en veut du GNU ass et sa syntaxe inchiable et inhabituelle.

Si ce sont les % devant les noms de registres qui te dérangent, cf. --register-prefix-optional. Mais je conseille plutôt de vous habituer à ces %, ils sont nécessaires pour distinguer les registres des variables C de même nom!

À part ça, je ne vois pas ce qui serait "inchiable" dans la syntaxe de GNU as. Inhabituel, je veux bien, mais une habitude, ça se prend avec le temps, une fois habitués à GNU as, ce sera la syntaxe de A68k qui va vous paraître inhabituelle (je parle d'expérience là), voire peut-être "inchiable" comme tu dis (je veux pouvoir écrire mes instructions dans la colonne 1! )...

GNU as a déjà des avantages, par exemple il permet d'écrire une différence entre 2 labels dans des fichiers objet différents (et différents de celui qui contient la différence, aussi), A68k n'a aucun moyen de représenter ça, le support pour les différences d'adresses dans A68k est un hack affreux (qui passe par des variables globales parce que rajouter des paramètres dans les fonctions était essentiellement infaisable, le code est bordélique et il y a énormément de trucs codés en dur) et il m'a été impossible de rajouter ça. Il n'y a pas que la licence à être problématique dans A68k, il y a aussi la (non-)maintenabilité.

Tu crois que les gens vont changer leurs habitudes et s'y mettre du jour au lendemain?

C'est bien pour ça que A68k est déprécié dès maintenant, mais si les gens l'ignorent, devoir changer leurs habitudes du jour au lendemain, ça sera exactement ce qui va se passer le jour où A68k est supprimé de TIGCC. C'est bien pour fournir une période de transition que je dis dès maintenant que A68k va être supprimé à terme.

bah je vais te dire moi, quand tu vas supprimer a68k, les gens vont continuer à le DL parce que malgré ses défauts, beaucoup de gens le préfèrent à gnu as.
Du moins, j'en ai l'impression.

onur (./12) :
bah je vais te dire moi, quand tu vas supprimer a68k, les gens vont continuer à le DL parce que malgré ses défauts, beaucoup de gens le préfèrent à gnu as.

Je prends ça comme une suggestion de supprimer tous les liens de téléchargement officiels et de demander la suppression de toutes les archives qui le permettent, je vais y réfléchir.

Je pourrais aussi supprimer le support des IDEs, compiler ld-tigcc sans le support AmigaOS etc.

Et ne pas pouvoir profiter de tous les correctifs que je vais rajouter, certainement mélangés avec des fonctionnalités GNU as only qui cassent complètement A68k dans un seul commit...