1

yop
quelques questions :

1.
quand on a :
    HANDLE handle;
    char *ptrFILE;
    SYM_ENTRY *sym;
    handle = HeapAlloc(16);
    if (!handle)   return;
    sym = DerefSym(SymAdd(SYM_STR("tuto")));
    if (!sym)  {HeapFree(handle);       return;}
    
    sym->handle = handle;
    ptrFILE = HeapDeref(handle);
    *(short*)ptrFILE = 14;
    ptrFILE[10] = 0;
    strcpy(ptrFILE+11,"TUT");
    ptrFILE[15]=OTH_TAG;


(tuto de Benji sur TI-Gen)
Une fois le fichier crée, on a bien 8 octets disponibles pour écrire quelque chose ?

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-----------+------+
|  0 |  1 |  2 | 3 |  4 |  5 |  6 | 7  | 8 |  9 | 10|11 |12| 13|14 |   15        |16    |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-----------+------+
| taille   |      données                           |  0 | T  | U |  T |  0 |OTH_TAG| 0(?) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-----------+------+
|     2    |               8                              |  1 |        3      |  1 |      1       |   1    |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-----------+------+





2. Je veux créer un fichier qui stockera les données des sprites que j'utilise :
le fichier est sous cette forme :
       taille : 2 octets
       nombre de données à lire par sprite (lignes) : 1 octet
       données : s octets
       autres : 0 // SPR // 0 // OTH_TAG // 0 (?) : 7 octets

soit :
+---+---+---+---+---+---+---+---+-----+------+------+----+------+------+-----+-----------+------+
|  0 |  1 |  2 | 3 |  4 |  ...            | s+1|  s+2 | s+3 |s+4 | s+5 | s+6 | s+7 | s+8        | s+9  |
+---+---+---+---+---+---+---+---+-----+------+------+---- +-----+------+------+-----------+------+
| taille   |     |            données                     |  0    | T     | U    |  T    |  0     |OTH_TAG| 0(?) |
+---+---+---+---+---+---+---+---+-----+------+------+---+---+---+-----+------+-----------+------+
|     2    | 1  |                    s                         |  1     |        3      |  1    |   1   |       1     |     1   |
+---+---+---+---+---+---+---+---+-----+------+------+---+---+---+---+--------+------+---+-------+



La taille du fichier est donc bien de s+9 octets ?
J'ai essayé ce code

SYM_ENTRY *sym = SymFindPtr(SYM_STR("spr",0);

if (!sym)
{
    HANDLE handle;
    char *ptrFILE;
    handle = HeapAlloc(s+9);
    if (!handle)   return;
    sym = DerefSym(SymAdd(SYM_STR("spr")));
    if (!sym)  {HeapFree(handle);       return;}
    
    sym->handle = handle;
    ptrFILE = HeapDeref(handle);
    *(short*)ptrFILE = s+7;
    ptrFILE[s+3] = 0;
    strcpy(ptrFILE+s+4,"TUT");
    ptrFILE[s+8]=OTH_TAG;
}

... //écriture des données ici, c'est un tableau de [i]char[/i]

mais ça me donne des résultats bizarres dans le Var-Link...




3.Comment créer un tableau de char à dimension s, s étant une variable de type short ?
comme ça :
char *spr = (char*) malloc(s*sizeof(char));

?

et une fois le tableau crée, comment pouvoir récupérer les données avec memcpy() ?
parce que
... //suite du code précédent
memcpy(spr, ptrFILE + 4, ptrFILE + 3);


ne me donne pas les bonnes données ; sinon, y a toujours moyen de le faire avec une boucle for, "à la main", mais j'préfère éviter


voilà voilà, merci pour les éventuelles réponses ^^



(désolé pour le décalage pour les tableaux ....)
programmeur sur TI ^^

mon blog sur les TI => clic

mon (p'tit) fofo sur les TI => clic

2

tama (./1) :
Une fois le fichier crée, on a bien 8 octets disponibles pour écrire quelque chose ?

Oui.
La taille du fichier est donc bien de s+9 octets ?

Oui.
mais ça me donne des résultats bizarres dans le Var-Link...

Je ne comprends pas trop, parce qu'à première vue d'œil, je ne vois pas d'erreur dans ce code.
3.Comment créer un tableau de char à dimension s, s étant une variable de type short ?
comme ça :
char *spr = (char*) malloc(s*sizeof(char));
?

Oui, mais comme sizeof(char)==1, le *sizeof(char) est redondant. smile
et une fois le tableau crée, comment pouvoir récupérer les données avec memcpy() ?
parce que
... //suite du code précédent
memcpy(spr, ptrFILE + 4, ptrFILE + 3);

ne me donne pas les bonnes données

C'est normal, tu essaies de passer un pointeur en troisième argument à la place de la longueur qu'il faut. (Tu devrais d'ailleurs avoir reçu un avertissement du compilateur pour ça!)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

3

effectivement, je n'avais pas remarqué ça...
il faut donc remplacer "ptrFILE + 3" par ptrFILE[3] ?

EDIT : pour le 2ème code, erreur de frappe, c'est bon c'est résolu smile
programmeur sur TI ^^

mon blog sur les TI => clic

mon (p'tit) fofo sur les TI => clic

4

Non [EDIT: enfin si, j'ai écrit ça avant de lire ton edit], par un entier. Peut-être ptrFILE[3] est ce que tu cherches, mais attention, tu ne lis qu'un char là, il te faut plutôt ((unsigned short*)ptrFILE)[1] (qui peut aussi s'écrire 1[(unsigned short*)ptrFILE] à cause de la manière dont est définie l'arithmétique de pointeurs et de tableaux en C et qui correspond à *(unsigned short*)(ptrFILE+2) (tu préfèreras peut-être cette écriture)).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

5

hmm j'avais écrit
ptrFILE[3]


mais j'avais oublié les balises, donc il l'a pas capté, d'où la couleur verte
ok ok, j'ai compris, j'vais utiliser la dernière écriture : *(unsigned short*)(ptrFILE+2)
programmeur sur TI ^^

mon blog sur les TI => clic

mon (p'tit) fofo sur les TI => clic

6

Kevin Kofler (./2) :
Oui, mais comme sizeof(char)==1, le *sizeof(char) est redondant. smile

Pas partout (demande à Ximoon grin), donc vu que ça ne coute rien autant le mettre et conserver un code un peu plus portable.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7

Zephyr (./6) :

Pas partout (demande à Ximoon biggrin.gif ), donc vu que ça ne coute rien autant le mettre et conserver un code un peu plus portable.

Si, si partout.
sizeof (char) == 1 (Cf la norme). C'est même l'unité de sizeof.
Ensuite, 1 'sizeof' peut être équivalent à 4 octets derrière.

8

Le fameux c4x. sick
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

9

Toujours est-il que ça ne coûte rien de laisser le sizeof, je sais que tu n'es pas partisan de la lisibilité du code Kevin, mais franchement, autant le laisser oui

(Et j'étais effectivement tombé sur un C5x pour lequel sizeof(char) == sizeof(short) == 1, le char étant sur 16 bits)
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

10

Pour moi, le code illisible, c'est le code bourré d'opérations redondantes qui reviennent à faire du *1, du +0 ou du !=false.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

11

Le but du code lisible, c'est justement que d'autres que toi puissent le lire, donc ton avis... tongue
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

12

13

hmm...petit problème : j'ai bien le fichier comme il faut, mais dans le Var-Link ça apparait sous l'extension "EXPR" avec la taille 2...

voilà la source (c'est programmé avec GTC oncalc) #include <tigcclib.h> void _main() {         SYM_ENTRY *sym;         sym = SymFindPtr(SYMSTR("font"),0);         HANDLE handle;         char *ptrFILE;                  static char data[]=         {                5,    //nombre de lignes                                 0b01110000,     //0                 0b10001000,                 0b10001000,                 0b10001000,                 0b01110000,                 0b00100000,     //1                 0b01100000,                 0b10100000,                 0b00100000,                 0b11111000,                 0b11110000,      //2                 0b00001000,                 0b01110000,                 0b10000000,                 0b11111000,                 0b11110000,      //3                 0b00001000,                 0b01110000,                 0b00001000,                 0b11110000,                 0b10000000,       //4                 0b10010000,                 0b10010000,                 0b11111000,                 0b00010000,                 0b11111000,       //5                 0b10000000,                 0b11110000,                 0b00001000,                 0b11110000,                 0b01111000,        //6                 0b10000000,                 0b11110000,                 0b10001000,                 0b01110000,                  0b11111000,        //7                 0b00001000,                 0b00010000,                 0b00100000,                 0b00100000,                 0b01110000,         //8                 0b10001000,                 0b01110000,                 0b10001000,                 0b01110000,                 0b01110000,                 0b10001000,                 0b01111000,                 0b00001000,                 0b11110000,         };    short size = sizeof(data)/sizeof(char); //oui, je sais que ça fait 1     handle = HeapAlloc(size+9);            if (!handle)    return; if (!sym) {  //création du fichier           sym = DerefSym(SymAdd(SYMSTR("font")));    if (!sym)    {HeapFree(handle);  return;}  //inutile ?         sym->handle = handle;         ptrFILE = HeapDeref(handle);         *(short*)ptrFILE = size+7 //l'erreur serait ici ?         ptrFILE[size+3] = 0;         strcpy(ptrFILE+size+4,"FNT");         ptrFILE[size+8] = OTH_TAG; //copie des données          memcpy(ptrFILE+2,data,size); } else {          sym->handle = handle;          ptrFILE = HeapDeref(handle); } short s=ptrFILE[3]; short chs = 0; char *spr = (char *)malloc(s*sizeof(char)); memcpy(spr,data+s*chs+1,s); Sprite8(80,80,s,spr,LCD_MEM,1); HeapFree(handle); }        

je précise qu'au lancement du programme, le fichier "FONT" n'est pas présent...

EDIT : oublié un ";" à la ligne "*(short *) ptrFILE = size + 7" dans la source.
elle y est bien dans le programme que j'ai fait
programmeur sur TI ^^

mon blog sur les TI => clic

mon (p'tit) fofo sur les TI => clic

14

Bon, la bonne nouvelle, c'est que ton code compile sans modifications avec TIGCC. gni

La mauvaise nouvelle, c'est que je vois au moins 2 bogues dans ton code:
1. Le pointeur sym retourné par SymFindPtr n'est plus valide après un HeapAlloc. Ton if (!sym) passera toujours (un pointeur nul reste un pointeur nul), mais dans ton cas else, ton sym->handle = handle; ne passe pas. D'ailleurs, je ne vois pas pourquoi tu alloues un nouveau handle quand le fichier existe déjà au lieu de réallouer celui qui existe déjà avec HeapRealloc.
2. Tu libères ton handle avec HeapFree à la fin. Tu n'as pas le droit de faire ça ici! Le handle appartient au fichier que tu viens de créer, il ne faut pas t'étonner que tu corromps ton fichier si tu lui supprimes son handle!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

15

Ben il compile aussi avec GTC. Et ce que tu dis est effectivement une bonne nouvelle, je suis d'accord : ça montre que TIGCC et GTC sont compatibles (j'ai constaté la même chose en compilant plusieurs sources, dont TiCon45, TIChess, Einstein et d'autres codes).
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

16

Ben voyons, pas un pour rattraper l'autre... Si c'était pas qu'ils en aient déjà par-dessus la tête de ce troll récurrent, je ferais bien un appel des modos habituels...

Puisque tu n'es pas capable (pas plus que Kevin) de présenter les choses correctement - à savoir que tu as testé avec une vieille version - je te demande d'arrêter purement et simplement d'utiliser TI-Chess comme exemple de compatibilité de GTC avec TIGCC.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

17

Les incompatibilités de la dernière version ne sont pas dues au code C je crois. Donc je continuerai à le citer parmi d'autres programmes C compatibles wink

Tu essaies de programmer quoi tama ?
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

18

Tu pourrais faire preuve d'intelligence, de temps en temps ?
Ca peut déclencher quoi, à ton avis, ta réaction de persister dans ton tort ? Que quelqu'un ait une réaction aussi stupide que la tienne et participe à creuser plus profond tous ensemble dans le bac à sable, en corrigeant ta désinformation à chaque fois qu'elle est postée ?
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

19

Peut-être le problème vient-il de toi. Si on parle de compatibilité du code C, le test de TiCon45 dans sa version C-only est parfaitement valable.
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

20

la "discussion" GTC vs TIGCC, en gros tout le monde la connaît, et à peu près tout le monde en a assez, je crois... Vous voudriez pas régler ça entre vous, genre par mini-messages ?
(ou même ne pas le régler, vu que vous serez jamais d'accord, parti comme c'est... mais si c'est entre vous, le résultat compte peu, tant que ça arrête d'en repasser 36 couches dans 36 topics...)

merci smile

21

alors

Bon, la bonne nouvelle, c'est que ton code compile sans modifications avec TIGCC.


oui, j'ai aussi remarqué ça

La mauvaise nouvelle, c'est que je vois au moins 2 bogues dans ton code:
1. Le pointeur sym retourné par SymFindPtr n'est plus valide après un HeapAlloc. Ton if (!sym) passera toujours (un pointeur nul reste un pointeur nul), mais dans ton cas else, ton sym->handle = handle; ne passe pas. D'ailleurs, je ne vois pas pourquoi tu alloues un nouveau handle quand le fichier existe déjà au lieu de réallouer celui qui existe déjà avec HeapRealloc.


Oui, je m'en suis aussi rendu compte, j'ai supprimé ces lignes, ça marche maintenant
(précaution par rapport à l'ASM z80 qui crée un fichier même si un fichier de même nom existe déjà, qui est inutile ici)

2. Tu libères ton handle avec HeapFree à la fin. Tu n'as pas le droit de faire ça ici! Le handle appartient au fichier que tu viens de créer, il ne faut pas t'étonner que tu corromps ton fichier si tu lui supprimes son handle!


Pareil, je l'ai enlevé et ça marche maintenant
mais j'me pose une question : le fait de ne pas libérer le Handle ne provoque t-il pas de perte de mémoire ?

Thibaut>je reprends un jeu que j'avais commencé à programmer il y a longtemps de cela ^^

sinon, simple curiosité :
#include <tigcclib.h>

void _main()
{
        long o = 100000;
        long p = 1;
        long result = o * p;
        printf("%ld",result);
}


pourquoi ça affiche 34464 (sachant que 100000 - 34464 = 65536) ?
pourtant 100000 rentre bien dans un long ?
et si je remplace o par 1000 et p par 100 ça marche (i.e ça affiche 100000)

programmeur sur TI ^^

mon blog sur les TI => clic

mon (p'tit) fofo sur les TI => clic

22

tama (./21) :
mais j'me pose une question : le fait de ne pas libérer le Handle ne provoque t-il pas de perte de mémoire ?

La mémoire n'est pas perdue parce qu'elle appartient au fichier.
tama (./21) :
pourquoi ça affiche 34464 (sachant que 100000 - 34464 = 65536) ?

Parce que ton compilateur est bogué, TIGCC donne le bon résultat.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

23

Ce que tu peux essayer, c'est écrire 100000L au lieu de 100000, mais d'après le standard C, ça ne devrait pas être nécessaire (une constante qui ne rentre pas dans un int est automatiquement un long).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

24

Kevin Kofler (./22) :
tama (./21) :
mais j'me pose une question : le fait de ne pas libérer le Handle ne provoque t-il pas de perte de mémoire ?

La mémoire n'est pas perdue parce qu'elle appartient au fichier.


ok
tama (./21) :
pourquoi ça affiche 34464 (sachant que 100000 - 34464 = 65536) ?

Parce que ton compilateur est bogué, TIGCC donne le bon résultat.


=/
bon, pas grave j'ai trouvé un autre moyen de toute façon

programmeur sur TI ^^

mon blog sur les TI => clic

mon (p'tit) fofo sur les TI => clic

25

!call Pollux
--- Call : Pollux appelé(e) sur ce topic ...
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

26

Oula oui c'est un énorme bug... C'est corrigé, en attendant tu peux faire o*(short)p au lieu de o*p et ça devrait renvoyer 100000 ^^

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

27

Ah, c'est pas à l'assignation qu'il y avait l'erreur ? Ben merci pour ta rapidité smile Tu penses ajouter les licences un jour et publier GTC ou tu laisses tomber ?
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

28

Je les ajouterai un jour, par contre je sais pas si je m'embêterai à trouver un workaround pour les flashapps que TI ne veut apparemment plus signer...

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

29

Est-ce que GTC utilise beaucoup les features des FlashApps pour se hooker à divers endroits du système ou redéfinir des trucs ?
(Le portage direct sur PedroM nécessiterait d'avoir le système d'événements complet dans PedroM, donc c'est pas pour tout de suite...)
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

30

Pollux répondra mieux que moi, mais là j'ai rien à faire alors je vais essayer de réfléchir un peu :

Je pense que les hooks ne sont pas utiles pour un compilateur, et je ne pense pas qu'il soit nécessaire de redéfinir des valeurs ou autre. Un compilateur fait uniquement du traitement de données, et de façon autonome. Il n'a pas besoin du système si ce n'est pour lire la source et écrire le résultat.

Et puis de telles utilisations de l'OS compliqueraient le portage DOS-TIOS.
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.