retour de variables - Page 1

Euh, juste une question stupide (peut-etre):
Peut on renvoyer un tableau d'un programme: directement à l'ecran ou dans une variable tibasic, par la pile (PUSH_blabla)?
Ca m'etonnerais, mais je voudrais etre certain.

Qu'appelles tu un tableau d'un programme?

erf le tableau asm doit etre convertit au format matrix (la c'est chian a faire..) puis apres on peu l renvoye....
Je te deconseil fortement d'essaye de le faire, car c'est tres chian a faire avec les tags...

Moi je pense qu'avec une routine avec des for for ça marche nickel, le seul pb étant le choix de l'espace mémoire à allouer

ouai, c'est bien ce que je pensait (

Et puis pour le retour de valeurs, pour l'instant ça ne marche que si on appelle le programme dans l'écran HOME sans l'utiliser dans une expression (il faut le lancer tout seul, puis récupérer ans(1) si on a besoin de la valeur dans une expression) ou alors si on a un kernel installé (pour l'instant ce sont les seuls TSRs qui permettent cela, mais ça peut changer).

Kel kernel?

Une version récente de Universal OS ou DoorsOS II.

Et y a forcément besoin de passer par les TSR? Ou tigcc nostub suffit?

Alors:
* Si tu veux juste retourner une valeur vers l'écran HOME (qui peut être réutilisée avec ans(1)), pas besoin de kernel ni de TSR.
* Si tu veux pouvoir l'utiliser dans une expression (même du type fonction()->a), alors sous AMS 2, il te faut un TSR qui vire l'erreur "invalid Program Reference" générée par AMS. Pour l'instant, il n'y a aucun TSR indépendant pour le faire et il faut un kernel récent.

Tu connais le principe ou pas? Moi ca m'interesse, je vais jeter un coup d'oeil aux sources de Doors.

Si tu nous fais ça, tu rendras un grand service à tous les pro-_nostub du monde.

Le principe: intercepter le Line 1010 Emulator, tester s'il y a le code "Invalid Program Reference", faire aussi certains tests du contexte, et si c'est bon, ne pas appeler l'ancienne interruption. Ce n'est pas plus compliqué que ça, mais moi, j'ai déjà trop de projets non commencés.

N'oublie pas d'ajouter $40000 à l'adresse de ce que tu installes pour la compatibilité avec h220xTSR.

apparement les kernels (enfin doors) fait juste une affectation mémoire dans a7 pour palier à ce pb..., je vais regarder encore

Regardez ce prog:

	include	"OS.h"
	xdef		_main
	xdef		_nostub
	xdef		_ti89

;-------------------------------------------------------------
; Program made with Fargo Program Editor v2.0
; Benoit SCHERRER - p.c.scherrer@wanadoo.fr
;-------------------------------------------------------------

;***************** Start of FARGO II Program ******************
_main:
	move.l		($C8),a4
	add.l		#top_estack*4,a4
	move.l		(a4),a4
	addq.l		#1,(a4)
	move.l		(a4),a4
	move.b		#LIST_TAG,(a4)

	move.l		(a7)+,a0
	move.w		#4,d0
	cmp.w		#$21EE,(a0)
	bne		filtrage
	move.w		#6,d0
filtrage:
	add.l		d0,a0
	jmp		(a0)

	rts
;********************** End of Program ************************
	end

Je l'ai utilisé dans une fonction AMS 2.05 et pas de problèmes...

>apparement les kernels (enfin doors) fait juste une affectation mémoire dans a7 pour palier à ce pb..., je vais regarder encore

Oui, c'est pour sauter l'instruction dc.w $Axxx qui produit l'erreur.

>Je l'ai utilisé dans une fonction AMS 2.05 et pas de problèmes...

Désinstalle tous tes kernels, appelle ton programme dans une expression, genre:
foncasm()+1
ou:
foncasm()->a
et tu vas voir...

^KK> OK

KK> c'est pas un TSR mais un détournement de Trap

Un détournement de trap est un TSR (ou une partie de TSR dans le cas des kernels).

Dès qu'un programme détourne quelque chose et ne le remet pas avant de rendre le contrôle à l'écran Home, c'est un TSR.

Et puis, ce n'est pas un trap, mais une exception Line 1010 Emulator.
[edit]Edité par Kevin Kofler le 08-07-2001 à 22:33:12[/edit]

ah, pardon. je croyais que tsr étaient seulement des hooks. j'avais pas élevé les trap au rang de tsr, paske c plus facile de détourner une trap que de faire un hook

J'ai fait une routine mais elle marche pas avec les 92+ AMS 2 apparement. Pourtant, c'est la routine de doors recopiée...
http://sirryl.multimania.com/beta/ipr.zip

Déjà vire-nous le test de la version de ROM dans la partie résidente en mémoire:

	lea	ROM_VER(pc),a1
	move.l	(a1),d0
	and.l	#$FFF,d0
	cmp.l	#$200,d0
	blt	nopb

Fais ce test dans la partie installation s'il te plaît et refuse l'installation sous AMS 1.

D'ailleurs, il suffit de comparer le nombre de ROM calls avec 1000 pour tester si c'est AMS 1 ou AMS 2:

 move.l $c8,a0
 cmp.l #1000,-4(a0) ;check if more than 1000 entries
 bcs ams1 ;if no, it is AMS 1.xx

Cela te permet de supprimer tout le tableau d'adresses, et d'être compatible avec des versions de AMS exotiques genre 2.00 ou 2.02.
[edit]Edité par Kevin Kofler le 09-07-2001 à 20:23:26[/edit]

Mais encore...

Ah! Je me suis trompé dans l'adresse! C'est $28 (du moins ça marche comme ça...)

J'ai testé le prog sous TI89 2.05 et TI92 2.05, et ça marche

Bravo. Je viens d'essayer sur ma TI-92+ AMS 2.04 (je n'ai toujours pas mis la 2.05...) sans kernel et sans HW2Patch, mais avec h220xTSR, et ça marche.

Un conseil: mets un programme de désinstallation. (Il suffit de désallouer le bloc et de remettre la valeur de $412088+$28 ou $212088+$28 selon le modèle à $28.)

Aussi, puis-je annoncer ton programme sur les forums internationaux qui attendaient un tel programme depuis longtemps ou as-tu encore des corrections/améliorations à faire avant la version finale?

bah j'ai rien à faire, mais je suis pas d'accord pour le prog de desinstall, un reset suffit . Il faut savoir aussi que le prog écrase l'ancienne trap user s'il y en a une.

Une solution qui sauvegarde et appelle l'ancienne interruption serait plus propre à mon avis (et plus rapide que de vérifier le type de la calculatrice à chaque fois), mais ta solution marche aussi, donc à toi de décider.

Et quelle que soit la solution choisie, un programme de désinstallation ne serait pas trop dur à faire.

Laisse moi y réflechir, mais je pense que je peux facilement garder les autres interruptions.

Au fait, mon prog gere aussi ASAP String too long...

Genial

Au lieu d'avoir un kernel qui gere tout, on va maintenant avoir plein de petit progs qui font les fonctions des kernel une a une (h220xTSR, ce truc là, les lanceur de nostub pour HW2+ROM 2.0x, l'anti-crash, ...)

C'est genial, ca, les newbies vont s'y retrouver sans problemes, et on va surement gagner plein de place grace au mode _nostub

Pour tous sauf h220xTSR, l'avantage est que l'on n'est pas obligé de les utiliser. Par exemple, si on ne veut pas utiliser ipr, on peut lancer la fonction tout seul et récupérer son résultat avec ans(1). L'anti-crash aussi n'est pas obligatoire. Pour les lanceurs, on peut aussi utiliser TICT Explorer ou alors un seul lanceur en ligne de commande pour tous les programmes. Si le programme n'est pas compressé, on peut même utiliser ipr, voire un kernel. (Pour les programmes compressés, il faut un décompresseur même pour ceux en mode kernel (runc), et c'est logique.)

Pour h220xTSR, l'avantage est qu'il peut être inclus dans les programmes. (D'ailleurs, je trouve que Paxal devrait le faire, mais c'est son programme.) Moi, je l'inclus dans mes TSRs et donc, pour les newbies, il y a un seul programme à installer. Et puis h220xTSR n'est pas du tout en compétition avec les kernels, mais avec le HW2Patch. (D'ailleurs, avec le HW2Patch, il y a toujours le bogue du changement des piles. Dans h220xTSR 1.03, ce bogue appartient au passé.)

Et puis, pour les lanceurs, il y a aussi l'avantage qu'il y a un lanceur personnalisé pour chaque programme, donc un programme spécifique à lancer à chaque fois. Avant de dire que c'est du gaspillage de place, lis le premier paragraphe: tu peux utiliser un seul lanceur pour tout si tu le préfères. Il y a même un TSR appelé ASH qui appelle le lanceur tout seul quand tu essayes d'exécuter un programme compressé (avec ExePack, pas avec RUNC) directement.
[edit]Edité par Kevin Kofler le 10-07-2001 à 00:11:15[/edit]