Lancer un programme à partir d'un autre prog - Page 1

Y'a t il moyen avec AS de lancer un programme depuis un autre?

kernel::exec ne marchera malheureusement pas sous AS vu qu'il s'agit de nostub

Y a il la source de kernel: :exec dans "tios.h" ?

Luigi
a écrit : Y'a t il moyen avec AS de lancer un programme depuis un autre?

Oui, mais c'est très compliqué à faire correctement (surtout sans l'aide du code de démarrage de TIGCC).

Pourquoi tous les débutants veulent-ils toujours absolument commencer par lancer un autre programme??? C'est une des choses les plus compliquées de la programmation TI-89/92+/V200 (à cause des protections HW2/AMS 2)!

Il faut:
1. déprotéger l'espace fantôme (cf. enter_ghost_space dans les sources de TIGCCLIB)
2. ne pas utiliser jsr pour appeler des fonctions à l'intérieur du programme lanceur! (Sinon, il faut reloger le programme lanceur lui-même comme le fait EXECUTE_IN_GHOST_SPACE de TIGCC.)
3. ajouter $40000 à l'adresse du programme à lancer
4. reloger le programme à lancer avec EX_patch. Les deux paramètres de EX_patch doivent être dans l'espace fantôme (c'est-à-dire qu'il faut avoir ajouté $40000 aux deux, pas qu'à une seule).
5. lancer le programme directement par un jsr (an).

pkoi il existe pas une fonction exec pour le C (j'en profite même si c'est pas dans la partie C), c'est trop dure a mettre en oeuvre ???

il existe kernel_exec en C aussi. Il faut inclure "kernel.h" de" PreOS et compiler en kernel

oui, mais pour le NoStub ???

Ça n'a peut être rien avoir, mais je suis en train de faire un loader qui met certain code en RAM (dans un handle alloué) et puis y saute (je n'en ai pas encore arrivé à ce point là). Est-ce que j'aurai le même problème avec la protection HW?

> oui, mais pour le NoStub ???
Arretes de programmer dans un mode de prog dépassé

> Ça n'a peut être rien avoir, mais je suis en train de faire un loader qui met certain code en RAM (dans un handle alloué) et puis y saute (je n'en ai pas encore arrivé à ce point là). Est-ce que j'aurai le même problème avec la protection HW?
Certainement, je crois qu'il te faudra utiliser EX_PATCH. mais mieux vaut attendre la réponse de quelqu'un de plus compétent que moi.

auto-réponse: j'ai fait:

	move.w	#$4e75,0(a0)
	jsr	0(a0)

.
où a0 pointe vers un espace alloué avec HeapAllocHigh, et ça a marché. Donc, empiriquement, ça marche :^)

il me semble que ca doit marcher sur HW1, et HW2 non ROM2.0x
sur HW2 rom2.0x sans hw2patch ou equivalent, il me semble qu'il fo faire ce que Kevin disait plus haut
(du moins, il me semble que c ce qu'il m'avait dit une fois)

squale92 a écrit :
il me semble que ca doit marcher sur HW1, et HW2 non ROM2.0x
sur HW2 rom2.0x sans hw2patch ou equivalent, il me semble qu'il fo faire ce que Kevin disait plus haut (du moins, il me semble que c ce qu'il m'avait dit une fois)

Ah ouais maintenant que je tombe, j'ai testé sur VTI ce qui ne veut absolument rien dire, car si ma mémoire est bonne, il n'émule pas la protection HW :^(

Merci de vor réponses, mais je crois de toute facon que l'asm pour moi, c'est fini. Ca me prend la tete. C'est complique et je ne comprend jamais mes erreurs
( 1) je ne sais pas me servir d'un debugguer, et je ne veux pas de prog alpha sur ma calc, quitte à ne rien prendre
2) Mon but était de comprendre mes erreurs pour ne pas les recommencer, et non passer mon temps à debugguer. Mais apparemment, c'est impossible)
)

bah, la programmation, c'est complique, en particilier au debut...
au bout d'un an de galere, pa contre, on commence a vraiment se faire plaisir

Ouais mais (je vais encore etre obligé de pleurer ) ca commence à faire beaucoup maintenant, et je suis peut etre celui qui poste le plus de code pour se faire aider.
Sans forum, je suis rien

Je vais me mettre au simulateur de 68k

Merci d'avoir supporté mes lamentations
(pleurer ca fait du bien, ca soulage)

Merci Kevin de ta réponse, si par hasard je m'en sort avec mes débuts, je m'y mettrais

PiNGoO
a écrit : oui, mais pour le NoStub ???

Sous TIGCC, tu as #define EXECUTE_IN_GHOST_SPACE, et puis quelques lignes à recopier d'un exemple de la FAQ:
http://tigcc.ticalc.org/doc/faq.html#49
(supprime l'appel à enter_ghost_space();, cette fonction est remplacée par EXECUTE_IN_GHOST_SPACE qui élimine tout risque d'erreurs).

boogerman
a écrit : Ça n'a peut être rien avoir, mais je suis en train de faire un loader qui met certain code en RAM (dans un handle alloué) et puis y saute (je n'en ai pas encore arrivé à ce point là). Est-ce que j'aurai le même problème avec la protection HW?

Oui. Mais comme tu es en mode kernel (chose qui d'ailleurs serait à changer - tu n'utilises pas de librairies du kernel de toute façon, donc tu pourrais gagner 3 KO de mémoire en passant en _nostub), tu peux présupposer que h220xTSR (ou HW2Patch) est installé, donc le code de démarrage de EXECUTE_IN_GHOST_SPACE n'est pas nécessaire. Mais tout le reste est exactement pareil qu'en _nostub

Uther Lightbringer a écrit :
> oui, mais pour le NoStub ???
Arretes de programmer dans un mode de prog dépassé

Arrête de raconter n'importe quoi!
C'est AS qui est préhistorique, pas le mode _nostub. Avec TIGCC, c'est très simple.

As est préhistorique, mais malheureusement, c'est le seul compilo qui fonctionne on calc

D'où la nécessité de cross-compiler/cross-assembler à partir d'un PC si on veut programmer sérieusement.

Arrête de raconter n'importe quoi! C'est AS qui est préhistorique, pas le mode _nostub. Avec TIGCC, c'est très simple.

Je parlais de programmation C pas de AS avec lequel de toute facon on ne peut pas programmer en mode kernel. En ce qui concerne le problème, je ne comprends pas pourquoi vous n'avez pas fait l'équivalent d'un kernel::exec dans TIGCCLIB.

Kevin Kofler a écrit :
Oui. Mais comme tu es en mode kernel (chose qui d'ailleurs serait à changer - tu n'utilises pas de librairies du kernel de toute façon, donc tu pourrais gagner 3 KO de mémoire en passant en _nostub), tu peux présupposer que h220xTSR (ou HW2Patch) est installé, donc le code de démarrage de EXECUTE_IN_GHOST_SPACE n'est pas nécessaire. Mais tout le reste est exactement pareil qu'en _nostub

Eh ben, comme il falait tout récopier/réecrire j'ai passé au _nostub (parenthèse: ton tuto est vraiment bien, et le link pour remplacer les 2 où 3 RAM calls ça ma aidé aussi). Cela ne veut pas dire que je soie contre le mode kernel, mais plutôt que comme je ne m'en sers (presque) pas, ça ne vaut pas le gaspillage de RAM (en plus cette nouvelle version en bouffe tellement!).

En tout cas, merci des infos, je crois avoir compris (n'empêche que ce serait quand même bien que VTI émule la protection, comme ça on n'aurait pas a essayer sur la calc un truc de ce genre!)

boogerman
a écrit : (n'empêche que ce serait quand même bien que VTI émule la protection, comme ça on n'aurait pas a essayer sur la calc un truc de ce genre!)

Un jour peut etre.... (VTI 3 qui est sortit mais qui fait que des TI Z80 )

boogerman
a écrit : Eh ben, comme il falait tout récopier/réecrire j'ai passé au _nostub

Bon, va jeter un coup d'œil à tipatch.lib, il y a le code de EXECUTE_IN_GHOST_SPACE là-dedans. Ou alors attends TIGCC 0.95, qui te permettra d'importer ça dans un programme en assembleur sans aucune difficulté. (Parce que si tu ne mets pas le code de EXECUTE_IN_GHOST_SPACE, il faudra avoir h220xTSR ou HW2Patch installés pour que ça fonctionne.)

Uther Lightbringer
a écrit : Je parlais de programmation C pas de AS avec lequel de toute facon on ne peut pas programmer en mode kernel.

Ben, avec TIGCC, ce n'est pas si dur que ça depuis qu'il y a EXECUTE_IN_GHOST_SPACE.

En ce qui concerne le problème, je ne comprends pas pourquoi vous n'avez pas fait l'équivalent d'un kernel::exec dans TIGCCLIB.

Parce que le lancement d'un autre programme n'est pas vraiment une tâche très importante, et que le code nécessaire est de toute façon dans la FAQ. Je ne comprends pas du tout pourquoi tout le monde veut absolument faire ça. On ne va quand-même pas voir sortir le 32768^ème shell?!? Comme si 32767 shells ne suffisaient pas...

c'est quand même une fonction relativement utile et si je trouve qu'elle devrait être incluse a TIGCCLIB c'est justement pour le pas être obligé de faire un copier coller violent de code que la pluspart ne comprends pas.

godzil: j'ai envoyé toute une liste de suggestions à Corey Taylor qui s'occupe de VTI...
Il va d'ailleurs falloir que je lui renvoie un truc assez rapidement (je ne peux pas en dire plus)...

Uther> pour le code, vu tel quel dans la doc, le code est absolumen imbouffable :/
La seule fois ou je l'ai testé g fait copier coller sans chercher a comprendre, il est assé "immonde"...

boogerman
a écrit : (n'empêche que ce serait quand même bien que VTI émule la protection, comme ça on n'aurait pas a essayer sur la calc un truc de ce genre!)

A propos, l'émulateur de TI Flash Studio émule la protection et la déprotection, mais n'émule pas le bug exploité par EXECUTE_IN_GHOST_SPACE bien sûr.

Moi, j'appelle ça un bogue de leur émulateur.

Kevin Kofler
a écrit : Moi, j'appelle ça un bogue de leur émulateur.

Je pense plutôt qu'ils essayent que le moins de gens possible se rendent compte du bug du HW (à moins qu'il ne le connaisent pas eux-mêmes et qu'ils soient vraiment convaincus d'avoir fait l'ému à l'image du HW ).