Appels de ROM - Page 1

Comment afficher une chaine de caractere (avec les caracteres de la ti), ailleurs que sur la memoire LCD?

Lorsqu'on utilise ROM_CALL DrawStrXY, le texte s'affiche toujours sur la memoire de l'ecran...

Utile la fonction SetPort et je pense que ton problème serat réglé.

PortSet plutôt

Je l'utilise jamais. J'aurais dû vérifier avant de poster.

Et d'ailleurs, le vrai nom du ROM_CALL qui affiche les chaînes de caractères est DrawStr, pas DrawStrXY. doorsos.h définit DrawStrXY pour des raisons de compatibilité antérieure seulement, os.h (que tu es censé utiliser, le mode kernel étant dépassé) ne le définit plus du tout.

En fait, j'aimerais creer mes propres boites de dialogue. J'ai donc besoin de caracteres (ceux de la ti), mais je ne sais pas comment les afficher ailleurs que sur l'ecran de 30 octets de large.

C'est quoi PortSet ? (je programme 100% ASM)

KK > Tu dis q'en utilisant _nostub, on a plus besoin de kernel. Or meme en incluant os.h et _nostub (comme tu le fais), sans kernel, le programme ne se lance pas.

Galmiza a écrit :
En fait, j'aimerais creer mes propres boites de dialogue. J'ai donc besoin de caracteres (ceux de la ti), mais je ne sais pas comment les afficher ailleurs que sur l'ecran de 30 octets de large.
C'est quoi PortSet ? (je programme 100% ASM)

http://tigcc.ticalc.org/doc/graph.html#PortSet

KK > Tu dis q'en utilisant _nostub, on a plus besoin de kernel. Or meme en incluant os.h et _nostub (comme tu le fais), sans kernel, le programme ne se lance pas.

Il dépasse 24 KO? Dans ce cas, il te faut un lanceur. Le plus simple est d'utiliser la compression automatique de TIGCC, qui te donnera un lanceur-décompresseur. (Et: Oui, ça marche sans problèmes avec les programmes 100% ASM. Va voir mon programme XtraKeys sur mon site pour un exemple.)

OFF TOPIC
(désolé)

Kevin Kofler a écrit :
Et d'ailleurs, le vrai nom du ROM_CALL qui affiche les chaînes de caractères est DrawStr, pas DrawStrXY. doorsos.h définit DrawStrXY pour des raisons de compatibilité antérieure seulement, os.h (que tu es censé utiliser, le mode kernel étant dépassé) ne le définit plus du tout.

Note: je ne veux pas lancer de débat, je fais juste une remarque...
C'est ce genre de petites phrases fausses et déplacées qui font que les débutants croient effectivement que le mode kernel est dépassé, alors que cette phrase ne veux rien dire en soit. pas la peine de me répondre svp le topic Kernel vs _nostub est là pour ça

Désolé, mais je ne me ferai pas silencer par toi. J'ai mon droit à la parole, donc ton "pas la peine de me répondre svp", tu le gardes pour toi.

Cette phrase n'est pas fausse ni déplacée, c'est un fait. L'idée de kernel date de quand les calculatrices TI n'avaient pas encore de support natif pour l'assembleur. Maintenant, elles en ont un, donc les kernels ne servent plus à rien.

je demandais juste de ne pas répondre dans ce topic dont ça n'est pas le sujet, pas de ne pas répondre du tout...
Et puis tes arguments ont tous été cassés ailleurs donc le débat est clos.

J'utilise os.h, sans _nostub, avec preos.
Je n'utilise pas tios car pour allouer de la memoire, c'est plutot chiant.
Aucun de mes programmes depasse 24ko (max 15ko).

J'ai toujours rien compris a PortSet, KK > le lien est bourré de code en C ... et j'y connais rien en C.

Sinon comment comprimer des fichiers qui sont decomprimés au lancement du programme? Seuls les fichier externes sont comprimés, non?

Je travaille sous Bloc-note, n'y a-t-il pas mieux?
J'ai tenté de compiler un de mes programme avec TIGCC, mais, meme avec un kernel, le programme ne se lancait pas.
TIGCC a l'air plus conviviale que Bloc-note, facilite-t-il l'utilisation d'appels de ROM?

Rappel: je programme 100% ASM.

Galmiza
a écrit : J'utilise os.h, sans _nostub

Tu te contredis. Tu venais de dire "Or meme en incluant os.h et _nostub (comme tu le fais), sans kernel, le programme ne se lance pas.". As-tu mis xdef _nostub comme il faut? Je suppose que non.

Je n'utilise pas tios car pour allouer de la memoire, c'est plutot chiant.

J'ai toujours rien compris a PortSet, KK > le lien est bourré de code en C ... et j'y connais rien en C.

http://tigcc.ticalc.org/doc/asminfo.html

Sinon comment comprimer des fichiers qui sont decomprimés au lancement du programme? Seuls les fichier externes sont comprimés, non?

La compression automatique comprime seulement le programme lui-même. Si tu veux comprimer des fichiers externes, il faudra le faire à la main. (Va voir du côté de ttpack de la TIGCC Tools Suite et de UnpackBuffer dans extgraph.a.)

Je travaille sous Bloc-note, n'y a-t-il pas mieux?

Si, TIGCC IDE.

J'ai tenté de compiler un de mes programme avec TIGCC, mais, meme avec un kernel, le programme ne se lancait pas.

Là, je ne comprends pas... Tu as dû faire une bêtise quelque part.

TIGCC a l'air plus conviviale que Bloc-note, facilite-t-il l'utilisation d'appels de ROM?

Non. L'assembleur reste de l'assembleur. Si tu veux des ROM_CALLs plus "faciles", programme en C.

Rappel: je programme 100% ASM.

Je sais, tu l'as déjà dit, pas la peine de le répéter.
Pas mal de mes programmes à moi sont également 100% ASM, et j'utilise toujours TIGCC.

mieux que le bloc note et tigcc y'a Ultra Edit

et context

non context c'est de la merde

TIGCC IDE est beaucoup plus adapté à la programmation TI-89/92+/V200 que ces éditeurs généralistes et inadaptés à la situation.

Ultra Edit est très bien adapté, tu peux même faire des macris pour compiler

Note: je ne veux pas lancer de débat, je fais juste une remarque... C'est ce genre de petites phrases fausses et déplacées qui font que les débutants croient effectivement que le mode kernel est dépassé, alors que cette phrase ne veux rien dire en soit. pas la peine de me répondre svp le topic Kernel vs _nostub est là pour ça

Pour de plus ample information sur le débat fleuve kernel vs nostub c'est ici: topics/19238-kernel-vs-nostub .

J'utilise os.h, sans _nostub, avec preos. Je n'utilise pas tios car pour allouer de la memoire, c'est plutot chiant.

Je vois pas de diférence notables

Aucun de mes programmes depasse 24ko (max 15ko).

Sons AMS <2.04 la limite est à 8ko.

J'ai toujours rien compris a PortSet, KK > le lien est bourré de code en C ... et j'y connais rien en C.

les argument entre parentèse sont placés sur la pile: long-> 4octets, short -> 2octets, char -> 1octet, *char/*long/*short/*... ->4octets(pointeurs)

Je travaille sous Bloc-note, n'y a-t-il pas mieux?

dans mon ordre de préférence a moi:
vi, TIGCC-IDE, Ultra-Edit(bien mais shareware), Context, Emacs.

J'ai tenté de compiler un de mes programme avec TIGCC, mais, meme avec un kernel, le programme ne se lancait pas.

utilise tios.h ca ira sans doute mieux.

TIGCC a l'air plus conviviale que Bloc-note, facilite-t-il l'utilisation d'appels de ROM?

disont que tout le romcalls connus sont dans la documentation mais sinon il ne rends pas quoi que ce soit de plus facile.

Vark a écrit :
Ultra Edit est très bien adapté, tu peux même faire des macris pour compiler

Mais dans TIGCC IDE, tout est déjà préconfiguré pour toi! C'est prévu dès le départ pour ce pour quoi on veut l'utiliser, ce n'est pas un éditeur générique auquel tu as rajouté le minimum nécessaire pour pouvoir l'utiliser avec TIGCC. Il y a des fonctionnalités de TIGCC IDE comme l'envoi automatique à VTI ou à une vraie calculatrice (très pratique pour tester!) qui sont inégalées.

Uther Lightbringer
a écrit : utilise tios.h ca ira sans doute mieux.

tios.h n'existe pas sous TIGCC! Le vrai nom de ce header est doorsos.h.

Sous TIGCC, quand j'essaie de compiler un programme qui marche parfaitement, on m'annonce 7 erreurs (2 differentes):

- INCLUDE file cannot be opened
- relocatability error

Or, moi, entre un truc qui marche et un truc qui marche pas, je n'hesite pas trop longtemps...

un probleme de TIGCC, c'est qu'il ne permet pas de definir les options de compilation pour chaque fichier, independamment des autres : on est oblige de faire un .bat et de le lancer a la main
(ou alors, j'ai pas trouve l'option permettant de definir les options pour chaque fichier)

Moi j'utilise le tios.h fourni avec PreOS. C'est l'idéal pour faire de la prog en ASM. Copie ce fichier dans le repertoire include/asm/ de tigcc.

tios.h n'existe pas sous TIGCC! Le vrai nom de ce header est doorsos.h.

Le headers fournis avec TIGCC ne sont pas pratique pour la prog kernel, il vaut mieux récupérer les fichiers inclus dans PreOS

Galmiza
a écrit : - INCLUDE file cannot be opened

2 solutions possibles:
* soit tu as inclus tios.h. Ce header n'existe pas sous TIGCC. Utilise doorsos.h comme (presque) tout le monde.
* soit tu as inclus des headers à toi, ou des headers d'une librairie non-standard comme genlib, sans les rajouter à ton projet. Il faut rajouter tous les headers non-système (c'est-à-dire tous sauf compat.h, doorsos.h, filelib.h, graphlib.h, gray4lib.h, gray7lib.h, hexlib.h, hufflib.h, linelib.h, os.h, userlib.h, util.h, ziplib.h) que tu inclus à ton projet!

- relocatability error

Conséquence directe de la première erreur: les constantes non définies sont vues comme des variables, ce qui te donne des expressions non-relogeables.

Uther Lightbringer
a écrit : Moi j'utilise le tios.h fourni avec PreOS. C'est l'idéal pour faire de la prog en ASM. Copie ce fichier dans le repertoire include/asm/ de tigcc.

Attention, le fonctionnement de ce header avec TIGCC n'est pas du tout garanti! Il est prévu pour l'utilisation avec le linker livré avec PreOs, pas avec notre système de linking. Par exemple, certaines directives du linker (celles pour mettre les flags du style "pas de sauvegarde de l'écran") ne sont pas les mêmes, parce que PpHd n'a pas suivi le standard fixé par JM. tios.h utilise les flags du linker de PreOs. Bref, utilisez le doorsos.h qu'on met à votre disposition, et pas autre chose.

Le headers fournis avec TIGCC ne sont pas pratique pour la prog kernel, il vaut mieux récupérer les fichiers inclus dans PreOS

C'est faux.

Attention, le fonctionnement de ce header avec TIGCC n'est pas du tout garanti! Il est prévu pour l'utilisation avec le linker livré avec PreOs, pas avec notre système de linking. Par exemple, certaines directives du linker (celles pour mettre les flags du style "pas de sauvegarde de l'écran") ne sont pas les mêmes, parce que PpHd n'a pas suivi le standard fixé par JM. tios.h utilise les flags du linker de PreOs. Bref, utilisez le doorsos.h qu'on met à votre disposition, et pas autre chose.

Si tu n'utilise pas ces directive ca marche très bien sous TIGCC, et il donne accès aux nouveaux RAM-CALL qui peuvent être très utiles(pas pour toi je sais mais bon penses aux autres) et une utilisation optimale des libs de preOS.

C'est faux.

C'est vrai si tu veux utiliser ton kernel au mieux même si ca peut provoquer des incompatibilité avec des kernel qui auraient du disparaitre des archives il y a bien longtemps.

> > J'ai toujours rien compris a PortSet, KK > le lien est bourré de code en C ... et j'y connais rien en C.
> les argument entre parentèse sont placés sur la pile: long-> 4octets, short -> 2octets, char -> 1octet, *char/*long/*short/*... ->4octets(pointeurs)

heu, pour les char, c'est pas plutot 2 octets (comme pour les words) ?
parceque ca rique de faire un address error, ca

et puis on place les arguments dur la pile en commencant par le dernier argument entre parentheses (on le splace en sens inverse quoi..)

Kevin Kofler a écrit :
Mais dans TIGCC IDE, tout est déjà préconfiguré pour toi! C'est prévu dès le départ pour ce pour quoi on veut l'utiliser, ce n'est pas un éditeur générique auquel tu as rajouté le minimum nécessaire pour pouvoir l'utiliser avec TIGCC. Il y a des fonctionnalités de TIGCC IDE comme l'envoi automatique à VTI ou à une vraie calculatrice (très pratique pour tester!) qui sont inégalées.

c justement parce-que c pré-configuré que c limité
et l'envois auto je trouve ça trop lent alors j'envois tjrs manuellement (et on peut faire une macro pour le faire en auto avec ultra edit aussi je pense)

Kevin Kofler a écrit :
Il y a des fonctionnalités de TIGCC IDE comme l'envoi automatique à VTI ou à une vraie calculatrice (très pratique pour tester!) qui sont inégalées.

Heu... Moi j'aurais évité d'utiliser cet argument, puisque les keystrokes foirent une fois sur deux, et que de toute façon vu la vitesse de compilation avec l'IDE il vaut mieux s'en passer

Vark
a écrit : et l'envois auto je trouve ça trop lent

Pas moi.

alors j'envois tjrs manuellement (et on peut faire une macro pour le faire en auto avec ultra edit aussi je pense)

Je ne pense pas. Je pense qu'il te faudra faire un programme à part entière pour la communication avec VTI. Il y a pas mal de code réservé à ça dans TIGCC IDE.

Vertyos
a écrit : Heu... Moi j'aurais évité d'utiliser cet argument, puisque les keystrokes foirent une fois sur deux,

Chez moi, ils marchent toujours, sauf si j'ai cliqué sur quelque chose au lieu d'attendre (ce qui est une erreur de l'utilisateur, pas un bogue de l'envoi automatique). Il ne faut pas toucher à l'ordinateur entre le click sur "Run" et le début de l'exécution sous VTI.

et que de toute façon vu la vitesse de compilation avec l'IDE il vaut mieux s'en passer

Je trouve que la vitesse de compilation dans l'IDE est tout à fait acceptable.

Ah nan franchement c'est lent :/