21:22 < dnanar> quelqu'un pourrait m'aider svp je suis en train de me débattre avec l'exemple (finalement trouvé, j'ai du installé l'exe de tigcc avec wine -_-) concernant TextEdit.h ?
21:30 < dnanar> en fait la compilation ce passe parfaitement mais dès que j'essaye d'executer la .v2z sur Ti Emu j'obtiens une "Line 111 Emulator", sous vrai Ti j'obtiens une "Illegal Instruction" (je dois
faire un hard reset). Après quelques tests il semble que ca soit l'instruction "EV_eventLoop ();" qui plante. Mais impossible d'en savoir plus: lorsque j'essaye de mettre des messages de
debogage dans la fonction qui ressoit les evenements, Ti Emu ouvre le debugger (que je ne sais pas utliser -_-) sans même afficher un message d'erreur, la vrai TI plante (rectangle noir en
haut de l'ecran sans AUCUN message d'erreur habituel). Voici mon code avec les petits messages d'erreurs: http://rafb.net/p/NlSg3w98.html Avec ce code, l'émulateur/vrai TI ne plante qu'après
avoir affiché "In TRY".... Donc, svp, quelqu'un aurait une petite idée ? :D
21:31 < dnanar> Ce que me semble plus bizarre c'est que ce code est donné avec TIGCC et qu'il est buggé -_-
21:31 < dnanar> enfin, justement je veux dire : ce qu'il me semble bizzare c'est qu'il puisse être boggé :D
21:32 < dnanar> l'AMS utilisé (Ti Emu/vrai V200) est la version 3.10
21:35 < Martial> dnanar:
21:35 < Martial> salut
21:36 < Martial> EV_eventLoop() n'est pas une instruction
21:36 < Martial> c'est la fonction principale de la partie évènementielle du TIOS.
21:36 < Martial> et j'ai pas compris ton pépin avec wine, KTIGCC marche impec et compile tout chez moi.
21:36 < Martial> (fc6)
21:37 < Martial> le code des exemples de TIGCC est vieux, il utilise des define alors qu'il faut maintenant utiliserles options de compilation dans la boite de dialogue prévue à cet effet.
21:38 < Martial> je me demande si on ne peut pas trouvert les exemples sur le SVN de TIGCC, je vais voir
21:39 < dnanar> ok merci
21:40 < dnanar> il utilise des define > oO c'est pas bon d'utiliser des define ? -_-
21:40 < Martial> http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/tigcc/examples/
21:40 < Martial> non, si tu compiles avec une IDE, vas dans project/options.
21:40 < Martial> c'est là qu'il faut totu régler.
21:41 < dnanar> j'ai pas compris ton pépin avec wine > aaarf quel idiot j'avais pas pensé a regarder les repertoires d'exemle de KTIGCC --_-
21:41 < Martial> c'est pas un svn, mais un cvs ><
21:42 < dnanar> Martial: il n'y a aucune difference entre le .c du cvs et celui posté sur rafb non ?
21:42 < Martial> pour info, le LINE 1111 emulator est un handler d'interruption appelé quand le proc doit éxécuter une instruction commençant par les 4 bits 0xFx
21:42 < Martial> rafb?
21:42 < dnanar> ah ok pour les options. Je vais voir un peu pour la ligne de commande
21:43 < dnanar> oui le pastebin que j'ai donné :)
21:43 < Martial> j'étais pas là :P
21:43 < dnanar> pour le Line 1111: ah ok :)
21:43 < dnanar> ah ok =)
21:43 < dnanar> http://rafb.net/p/NlSg3w98.html c'est le code utilisé pour faire le programme qui plante
21:43 < dnanar> mais il n'y a aucune difference entre ce code et celui du svn nan ?
21:44 < Martial> et donc AMS>=2.04 a un handler de f-line qui permet d'appeler les ROM calls en deux octets (0xf800 + ROMCALL*4)
21:44 < Martial> normalement non, un cvs sert à ça hein ^^
21:44 < dnanar> arf oui mais le .c du cvs est pas à jour depuis 2 ans -_-
21:45 < dnanar> un handler de f-line ?
21:45 < Martial> donc si tu cherches à éxécuter du code qui contient des appels de ROM call en f-line, tu dois cocher cette option dans le projet pour avoir un handler de f-line installé au début de ton
programme. sinon, ça va essayer de l'éxécuter, le TIOS va l'intercepter, et là plantage.
21:45 < dnanar> en fait ce qui me semble encore plus bizarre c'est que j'obtiens pas la même erreur sous TI que sous TI Emu -_-
21:46 < dnanar> ah ok
21:46 < Martial> normal, is tu codes en nostub, le code de démarrage de TIGCC se comporte comme un embedded-kernel qui est totalement dépendant de la plateforme.
21:46 < dnanar> ah ok
21:47 < Martial> http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/tigcc/archive/startup/
21:47 < Martial> tous le code de démarrage avec lequel TIGCC peut compiler.
21:47 < dnanar> tu dois cocher cette option dans le projet > et tu ne saurais pas quelle est l'option en ligne de commande ?
21:48 < dnanar> http://[snip] oula
21:49 < Martial> cf doc ^^
21:49 < Martial> je connais pas par coeur, désolé.
21:49 < dnanar> heureusement =)
21:49 < Martial> surtotu que j'utilise KTIGCC, que je programme en assembleur, en mode kernel et non nostub, et quand je fais du nostub, je réécris mon propre handler de f-line qui est plus petit et plus
rapide que celui de TIGCC ^^
21:52 < dnanar> arf ok =)
21:53 < dnanar> et tout ca pour faire quoi ? :)
21:57 < dnanar> et dis moi ou se trouve l'option dans ktigcc pour avoir un handler de f-line ?
21:59 < Martial> project/options/compilation/program options/reloc format => f-line (very small calls, no stub, but slow)
22:00 < dnanar> ahhhhh ok
22:00 < Martial> c'est lent si tu fait un jeu à très haute vitesse (à vue de nez, ça prend dans les 80 cycles au lien d'une dizaine pour un appel relogé)
22:00 < Martial> donc rien de grave, sauf dans du code vraiment très critique.
22:00 < dnanar> pour alors on peut faire ca a la vieille methode avec un #define USE_INTERNAL_FLINE_EMULATOR
22:01 < Martial> je ne sais rien de la compatiblité actuelle des define avec l'API actuelle de la lib.
22:01 < dnanar> donc rien de grave, sauf dans du code vraiment très critique. > on peut faire certaine parties qui utilise le handler f-line du programme, d'autres du TIOS ?
22:01 < Martial> je pense qu'il y aurait plutôt une option de compilation à définir en ligne de commande, mais je ne sais pas trop.
22:01 < Martial> totu à fait.