Utilisation de la ligne de commande - Page 2

Oui, mais ça plante.
Donc pour moi, ça ne marche pas.

Ca plante...
Mais est-il possible d'ajouter $40000 juste avant NG_execute ?? Quelle serait la solution, a part faire sa propre routine d'execution (ie relocation et tout, ce qui prend un max de place dans mon prog) ?

Intercepter le trap #$B et faire comme h220xTSR. (Mais le programme principal doit être dans l'espace fantôme pour que ça marche!)
C'est la seule manière d'utiliser NG_execute sans plantage.

Le problème avec NG_execute, c'est que:
1. Au lancement du programme "lançeur", AMS déprotège l'espace d'exécution de ce programme.
2. NG_execute déprotège l'espace d'exécution du programme "lancé".
Jusque là, tout se passe bien, mais:
3. Au retour du programme "lancé" vers le programme "lanceur", c'est toujours l'espace d'exécution du programme "lancé" qui est déprotégé. Donc il est possible (même assez probable) que l'espace d'exécution du programme "lanceur" sera protégé et que ça plantera.

Tu te demanderas probablement: En quoi intercepter le trap #$b aiderait-il?
Si on fait comme h220xTSR, on intercepte ce trap et quand AMS l'appelle pour déprotéger un endroit de la mémoire, on refuse de le faire, et à la place, on reloge le programme à lancer vers l'espace fantôme et on ajoute $40000 à son adresse. Donc AMS le lancera dans l'espace fantôme. Évidemment, ceci présuppose que l'espace fantôme est déprotégé (h220xTSR le fait lors de l'installation) - et pour l'utilisation de enter_ghost_space, les avertissements de mes messages précédents s'appliquent. Le mieux est d'utiliser ExePack qui s'en occupe pour nous.
[edit]Edité par Kevin Kofler le 19-09-2001 à 20:26:35[/edit]

Une solution bien plus simple :
Tu installes hw2patch. (Tu peux le lancer directement de ton prog s'il le faut).

>Au retour du programme "lancé" vers le programme "lanceur", c'est toujours l'espace d'exécution du programme "lancé" qui est déprotégé. Donc il est possible (même assez probable) que l'espace d'exécution du programme "lanceur" sera protégé et que ça plantera.

Je considere ceci comme un bug d'AMS et il faudrait avertir TI pour qu'ils puissent faire quelque chose.

>PpHd:
>Une solution bien plus simple :
>Tu installes hw2patch. (Tu peux le lancer directement de ton prog s'il le faut

En quoi est-ce plus simple qu'utiliser ExePack et appeler le programme directement en ajoutant 0x40000 à l'adresse?

Et tu ne vas pas lancer le HW2Patch à chaque lancement du programme.

Et puis:
* soit tu distribues le HW2Patch avec ton programme:
- C'est illégal sans la permission explicite de JM.
- Si le HW2Patch est mis à jour, soit tu refais l'archive, soit tes utilisateurs auront une ancienne version.
* soit tu ne le fais pas:
L'utilisateur devra alors le télécharger à part, donc ce n'est pas pratique.

>Nitro: Je considere ceci comme un bug d'AMS et il faudrait avertir TI pour qu'ils puissent faire quelque chose.

Oui, c'est un bogue. Mais TI ne pense qu'à renforcer sa protection, pas l'affaiblir, même si ça serait la chose à faire ici. Je pense d'ailleurs que c'est fait exprès puisque pouvoir faire tourner 2 programmes en assembleur "en même temps" implique pouvoir faire tourner des TSRs, et donc une difficulté en moins pour installer des applications Flash en RAM, ce que TI veut éviter à tout prix.

"C'est illégal sans la permission explicite de JM"

lol
C'est pas la peine de me dire de telles choses :]
Bon a ce que je vois, il n'y a rien de tres simple dans tout cela

J'estimes que Hw2patch est un produit finis.
Il a un but simple, et il y arrive tres bien.
Et il suffit de lancer hw2patch une fois.

oué.
me dites pas que vs changez de ROM tous les jours

Ca use trop de pile!

>PpHd: Et il suffit de lancer hw2patch une fois.

Justement.
Si on le lance dans le programme, on le lance à chaque fois.

Une solution serait d'inclure mon h220xTSR dans le programme. (Ça suffit pour pouvoir utiliser NG_execute, et c'est fait pour l'inclusion dans les programmes, et ma licence le permet explicitement.)
En assembleur, il suffit de ne pas utiliser jsr ou jmp pour les labels de ton programme (mais bsr ou bra).
En C:
* il faut reloger le programme vers l'espace fantôme après usage de ma fonction (en fait c'est nécessaire après le premier usage seulement). C'est fait dans les sources de TICT Explorer (après enter_ghost_space - et h220xTSR = enter_ghost_space + un TSR pour détourner les traps 4 et $b).
* il ne faut pas utiliser SAVE_SCREEN, ni RETURN_VALUE, et il faut utiliser NO_EXIT_SUPPORT.
* il faut appeler ma fonction dans _main (pas dans une sous-fonction).

Sinon, il reste la solution enter_ghost_space + appel direct.
Les règles d'usage sont les mêmes que pour h220xTSR. La différence est que enter_ghost_space n'installe pas de TSR sur les traps et qu'on ne peut pas utiliser NG_execute pour appeler un programme en assembleur ou C après enter_ghost_space (sauf si on aime les plantages), alors que c'est possible après h220xTSR.
[edit]Edité par Kevin Kofler le 21-09-2001 à 20:05:32[/edit]

Je peux faire un patch qui met h220xTSR à jour automatiquement. (Mais je n'ai pas le temps avant décembre.) Et je pourrais éventuellement étendre ce patch à tout genre de fonction de librairie statique (par exemple à enter_ghost_space).

Entretemps, effectivement, Greg Dietsche et moi, nous recompilons nos TSRs après chaque mise à jour de h220xTSR.

Ok Kevin, je vais inclure h220xTSR, si ca resoud entierement le probleme.
A savoir que mon prog, dans ce cas, sera lui aussi recompile a chaque mise a jour de ce programme.

Ah autre chose Kevin, que j'ai oublie de te demander (je te pose bcp de question, mais on a l'impression que tu aimes ca ) :
Est-ce que ton prog casse la limite des 8/24Ko ?

La limite matérielle oui et non: oui, mais à condition d'utiliser NG_execute (que h220xTSR intercepte) ou d'ajouter 0x40000 à l'adresse pour les appels directs. L'espace RAM "normal" (non fantôme) reste protégé.

La limite logicielle non, il faut IPR de Paxal (qui supprime non seulement "ASAP or Exec string too long", mais aussi le "Invalid Program Reference" quand on utilise un programme en assembleur dans une expression).

Ok.
Bon, je viens de flasher ma 89, histoire de ne plus avoir HW2Patch.

Surprise : mon programme, meme sans ton tsr, fonctionne a merveille. Par contre, qd j'inclus ton .bin au debut de mon programme, j'ai droit a la barre noire au dessus de l'ecran
D'ou cela vient-il ?
Et autre chose : l'IDE de TIGCC ne semble pas accepter l'inclusion de .bin (incbin).
Es-tu deja arriver a en inclure ??

>l'IDE de TIGCC ne semble pas accepter l'inclusion de .bin (incbin)

C'est toujours le meme probleme de path, l'IDE de TIGCC ne fait pas en sorte que les paths relatifs aux fichiers soient fonctionnels, donc ça ne marche pas.

Nitro --> alors pk ca marche avec les types de fichiers geres par tigcc, tels les .h, .asm, .c etc... ??


Kevin, il n'y aurait pas un bug dans ton tsr ?

 cmp.l #$200000,$ac ;check if trap #$b points to the ROM
 bcs already ;if no, it is already installed
 cmp.l #$200000,$90 ;check if trap #4 points to the ROM
 bcs trap4_already ;if no, it is already hooked

Sur 92+, ce n'est pas #$400000 ??

Même sur 92+, on peut lire la rom à partir de $200000

Et si la routine était en ram, elle serait de toute façon à une adresse inférieure à $200000.
[edit]Edité par ExtendeD le 25-09-2001 à 19:32:11[/edit]

>alors pk ca marche avec les types de fichiers geres par tigcc, tels les .h, .asm, .c etc... ??

Ben non ça marche pas justement, en tout cas chez moi, quand je fais #include "file.c" ça n'a jamais marché. L'IDE ne prend en considération que les fichiers qui appartiennent au projet.

Mais bon, ça remonte à longtemps, c'est peut-etre corrigé depuis. Moi je n'installe meme plus l'IDE tellement il ne me sert à rien
[edit]Edité par Nitro le 25-09-2001 à 18:45:10[/edit]

>FlashZ:
>Surprise : mon programme, meme sans ton tsr, fonctionne a merveille. Par contre, qd j'inclus ton .bin au debut de mon programme, j'ai droit a la barre noire au dessus de l'ecran
>D'ou cela vient-il ?

Utilises-tu des jsr vers des routines à l'intérieur de ton programme?

>Et autre chose : l'IDE de TIGCC ne semble pas accepter l'inclusion de .bin (incbin).
>Es-tu deja arriver a en inclure ??

Utilise la version source.
TIGCC IDE n'aime pas les .bin. J'en avais déjà parlé une fois à Sebastian, il faudrait peut-être que je relance le sujet.

>Kevin, il n'y aurait pas un bug dans ton tsr ?
>
> cmp.l #$200000,$ac ;check if trap #$b points to the ROM
> bcs already ;if no, it is already installed
> cmp.l #$200000,$90 ;check if trap #4 points to the ROM
> bcs trap4_already ;if no, it is already hooked
>
>Sur 92+, ce n'est pas #$400000 ??

Non.

Si le code est en RAM, adresse<$200000.

S'il est en ROM:
Sur TI-89, $200000<=adresse<$400000.
Sur TI-92, $400000<=adresse<$600000
Donc dans les 2 cas, adresse>=$200000.

Donc, mon test est correct.

>Nitro:

>Ben non ça marche pas justement, en tout cas chez moi, quand je fais #include "file.c" ça n'a jamais marché. L'IDE ne prend en considération que les fichiers qui appartiennent au projet.

Et de plus, les fichiers .c ne peuvent pas être des headers, il faut les renommer en .h.

>Mais bon, ça remonte à longtemps, c'est peut-etre corrigé depuis. Moi je n'installe meme plus l'IDE tellement il ne me sert à rien

Non, ce n'est pas corrigé puisque ce n'est pas un bogue. Il faudrait juste accepter les fichiers .bin comme "A68k binary header files". Pour les "include fichier.c", je considère cela comme une erreur du programmeur, pas de l'IDE. Un fichier inclus est un header et doit donc logiquement porter l'extension .h. TIGCC IDE n'est pas la seule IDE qui présuppose cela.

Kevin : je n'utilise pas de JSR a part pour les ROM_CALLs. Si tu veux voir mon source, il n'y a aucun probleme.

Nitro : >>alors pk ca marche avec les types de fichiers geres par tigcc, tels les .h, .asm, .c etc... ??
>Ben non ça marche pas justement, en tout cas chez moi, quand je fais #include "file.c" ça n'a jamais marché. L'IDE ne prend en considération que les fichiers qui appartiennent au projet.

L'histoire des chemins relatifs ne marche que si le fichier inclus est dans le meme repertoire. Dans le cas de mon .bin, il est aussi dans le meme repertoire, donc ce n'est pas du tout le meme probleme je pense !


En gros, les bugs de TIGCC :
- les fichiers includes (headers) doivent obligatoirement avoir l'extension .h (et non .asm ou .c)
- le programme ne gere pas les .bin
- il ne gere pas non plus les fichiers inclus dans un autre repertoire, en l'occurence qd on lui precise un chemin RELATIF
- la syntaxe highlighting est ultre lente (en particulier qd il y a une fenetre ouverte devant la fenetre de TIGCC)

Mais pourquoi pas de Hw2patch ?

parce que moi j'ai pas de patch HW2 sur ma tyi!

T'as une HW1 donc ?

lol
Des tas de newbies croient que HW2Patch bousille leur calc, et n'installent pas de kernel rien que pour ca (je te montrerai des exemples de mails...)

Installer un TSR semble donc indispensable

Perso j'utiliserai tjrs HW2Patch, mais bon je suis bien oblige d'adapter tous mes progs, etant donne que de plus en plus de monde n'utilise pas de kernel
A force, si je reste en mode Kernel, je ne ferai des progs plus que pour moi

Hey sinon PpHd tu m'autorisera a distribuer RunC avec mon prog ?
Autre detail concernant ton mail : ---> 15.5 fps

>>Autre detail concernant ton mail : ---> 15.5 fps
félicitations (si c bien pour ce que je crois)

Oui oui c'est bien ca

Ok, pour Runc.
Je pourrais t'aider plus si tu m'aides plus sur ce que tu as fait.

Comment je dois comprendre le "plus" ?
En ce qui concerne le support de RunC, il est totalement termine, et marche a merveille