Par où commencer pour s'y mettre - Page 1

Bonjour.

Voila, Je voudrais me mettre au C sur ma 89 titanium (HW3, OS v .10), mais je sais pas par où commencer.

Je suis plutot confirmé en TI-basic, je connais un peu le C sur pc, et je cherche des tutos pour m'y mettre.
Seul problème : Les tutos que j'ai trouvé ne parlent pas de la titanium (que de la 89, 92+, V200), et apparament, il faut faire gaffe à la version de machine sur laquelle on programme...
Quelqu'un connait il un tuto pour titanium?

Et aussi, j'ai vu que GTC n'était plus distribué, y-a-t-il une alternative pour programmer directement sur sa machine?

Merci d'avance.

Si tu utilises TIGCC 0.96 Beta 8, tant que tu passes par les fonctions documentées de TIGCCLIB (genre SetIntVec pour régler une interruption, pas de bidouillage à la *(void**)0x40064=...), ton programme marchera automatiquement sur Titanium.

je vais essayer tout ça, merci!

GTC n'a plus été distribué pendant une période, mais il l'est de nouveau depuis plusieurs mois: http://gtc.ti-fr.com/
Il n'y a aucune bonne alternative pour la programmation directe on-calc.

tobymac (./1) :
Seul problème : Les tutos que j'ai trouvé ne parlent pas de la titanium (que de la 89, 92+, V200), et apparament, il faut faire gaffe à la version de machine sur laquelle on programme...

Le kernel (PreOS en l'occurence, le seul à jour), fournit une couche d'abstraction matérielle et logicielle intéressante pour éviter tous ces problèmes.

En théorie oui, en pratique, il crée plus de problèmes de compatibilité (avec divers RAM_CALLs obsolètes) qu'il ne résout.

Si tu utilises un compilateur C à jour, il s'occupe déjà de tous ces problèmes, donc ça ne sert à rien de passer par un kernel.

d'accord, merci, je vais tenter tout ça!

en pratique, il crée plus de problèmes de compatibilité (avec divers RAM_CALLs obsolètes) qu'il ne résout.

A nuancer par le fait est qu'en pratique, l'obsolète txtrider - fait avant la V200 et la 89T - fonctionne toujours (pas mieux, pas moins bien), sans avoir dû être recompilé pour tourner sur V200 et 89T, contrairement aux programmes AMS native de même époque

Si tu utilises un compilateur C à jour, il s'occupe déjà de tous ces problèmes

J'allais le dire pour txtrider, vu que c'est peut-être le programme TI le plus utilisé depuis toujours, c'est l'exemple le plus emblématique à mon sens, de la future compatibilité apportée par le kernel pour un programme bien codé. En pratique maintenant, faut avouer que comme il ne devrait plus y avoir de nouveaux HW et AMS, l'intérêt est en effet perdu de ce côté-là. Mais beaucoup d'avantages subsistent, par exemple en ce qui concernent le support des librairies dynamiques, et les libs conditionnelles, les pack-archives, tous les ramcalls non obsolètes etc...

Pour info, jai téléchargé cette semaine divers jeux "tunnel", grand classique, dans les archives de ticalc. Pas un seul que j'ai vu ne marche aujourd'hui sur 89ti et 92 par exemple. On croit avoir une grande bibliothèque, mais au niveau de la compatibilité, faut avouer qu'elle est finalement assez réduite...

"TxtRider" et "bien codé" dans la même phrase? C'est un des programmes les plus bogués qui existent!

Un programme peut être tout à la fois bien codé et bugué, ça n'a pas forcément un rapport direct

Pour moi, un programme bogué est un programme mal codé.

Avec cette définition, la grande majorité des logiciels que nous utilisons tous, tous les jours, quelle que soit la façon dont ils sont codés (bonne architecture globale et détaillée ou pas - c'est à ce genre de critères plus objectifs que Ximoon doit faire référence) et quelle que soit leur licence (ça n'a rien à voir avec la qualité), sont buggés...

Kevin Kofler (./12) :
Pour moi, un programme bogué est un programme mal codé.

Alors Linux, KDE, TiEmu et TiLP sont des grosses merdes.

Et W1nd0w$$$ (W1nd4ub3, je veux dire) de M1cr0$$0f7, qu'est-ce que tu en fais, HEIN ???!!





On est off-topic, les gars