FTL Parser 2004 - Page 5

Non.
1. Il faut récupérer ça: http://members.chello.at/gerhard.kofler/kevin/ti89prog/libfargo.zip et dézipper fargo.a dans le répertoire Lib pour que le target apparaisse. Et pourtant, je le rappelle à chaque fois qu'une nouvelle bêta sort. 2. Si c'est du C, il y a du boulot à faire pour les déclarations. Tu peux repiquer une partie sur mon portage de Backgammon. Si c'est de l'assembleur, il faut inclure les headers livrés avec Fargo (mais le linker de TIGCC 0.95 fonctionne pour linker), et il peut là aussi avoir un portage à faire.

Ah bon ?! Je ne savais pas que c'était si compliqué ! En fait il n'y a pas beaucoup de monde qui le fait, parce-que dans les sources je ne vois personne qui programme pour Ti92 quasiment.

PKoi le parser sur 92+ serait plus rapide que sur 89 ?

Ah tu as la ma page ! Alors en fait c'est tout simple ça vient de l'écran : sur Ti92+ vu que l'écran est plus grand il y a plus de caractères par ligne et donc moins de lignes à afficher... pour le parser c'est la même chose parce-que chaque ligne et même chaque paramètres maintenant sont allouées dynamiquement. Donc sur Ti92+ il y a moins de malloc à faire mais c'est en parti compenser par la longeur de la barre de chargement qui prend plus de temps . Et comme il y a moins de ligne ça consomme moins de mémoire aussi.
Sinon pour l'affichage sur 92+ c'est assez lent mais ça ne gêne pas trop et même bien au contraire... mais il y a un truc que j'avais pas vû c'est la lenteur de l'éditeur de texte Ti : on peux rien faire avec !

Faut en faire un petit WYSIWYG sur ti ... ca peut etre sympa

Ouais c'est clair mais ça doit être assez chaud quand même !

Sinon pour l'affichage sur 92+ c'est assez lent mais ça ne gêne pas trop et même bien au contraire... mais il y a un truc que j'avais pas vû c'est la lenteur de l'éditeur de texte Ti : on peux rien faire avec !

Ah bon? C'est bizarre, ça, en tous cas sur 89 je trouve que c'est assez rapide (à part le scrolling parfois)

Oui sur Ti89 c'est rapide mais sur TI92+ c'est horrible : lors de l'affichage on voit le texte s'afficher ligne par ligne quasiment avec VTI.

Par contre là j'ai eu un petit souci en essayant de diminuer la consommation de mémoire du programme.
Voilà les structures utilisées :

typedef struct
{

unsigned char stick_char:2;
unsigned char color:2;
unsigned char center:1;
unsigned char under_line:1;
unsigned char on_line:3;
unsigned char font:2;
unsigned char animate:2;
unsigned char left:2;
unsigned char right:2;
unsigned char inter_line:2;
unsigned char br:2;
unsigned char frame:1;
short x:13;

}Str_Mode;

typedef struct
{
unsigned char *str;
Str_Mode *param;


}Text;

Text *TEXT=malloc(2048*sizeof(Text));
memset(TEXT,0,sizeof(Text)*2048);

En fait chaque ligne du texte comporte le texte lui même et les paramètres. Alors jusqu'à maintenant j'allouais de la mémoire pour les paramètres à chaque ligne même si les précédentes comportaient les mêmes paramètres :

TEXT[nb_str].param=malloc(sizeof(Str_Mode)); // première ligne
memset(TEXT[nb_str].param,0,sizeof(Str_Mode));
temp_param = TEXT[nb_str].param;
...
TEXT[nb_str].param=malloc(sizeof(Str_Mode)); // ligne suivante contenant les même paramètres que la ligne précédente
memset(TEXT[nb_str].param,0,sizeof(Str_Mode));
*TEXT[nb_str].param = *temp_param;

A la fin je libère le tout en faisant comme cela :
Text *temp = &TEXT[0];
for(ligne=0;ligne<nb_str;ligne++)
{
free(temp->str);
free(temp->param);
*temp++;

}
free(TEXT);

Donc je voulais essayer de ne pas allouer de mémoire pour les les paramètres des lignes ayant les mêmes paramètres que les précédente mais plutôt de pointer vers la première ligne (celle qui a été alloué pour contenir les paramètres).
En fait si un morceau de texte qui fait 10 lignes contient les mêmes paramètres à chaque lignes, seul la strcuture de la première ligne est allouées et les paramètres des 9 lignes suivantes pointent vers la première.

Alors j'ai remplacer

TEXT[nb_str].param=malloc(sizeof(Str_Mode)); // ligne suivante contenant les même paramètres que la ligne précédente
memset(TEXT[nb_str].param,0,sizeof(Str_Mode));
*TEXT[nb_str].param = *temp_param;

par ça :

TEXT[nb_str].param = temp_param;

Et avec ça le programme se lance et s'affiche bien correctement mais c'est au moment de libérer la mémoire que j'ai un problème : je ne sais pas comment distinguer les paramètres allouées et ceux qui sont de simple pointeur.
Il est évidant que si je laisse le même code qu'avant comme avant c'est à dire

Text *temp = &TEXT[0];
for(ligne=0;ligne<nb_str;ligne++)
{
free(temp->chaine);
free(temp->param);
*temp++;

}
free(TEXT);

Ca ne va pas marcher vu que les paramètres qui sont des pointeurs ne doivent pas être libérés.
Vous avez une idée de comment je peux faire pour libérer juste la mémoire des paramètres qui ont été alloués et non ceux qui pointent vers la mémoire ?

Raphaël
: Vous avez une idée de comment je peux faire pour libérer juste la mémoire des paramètres qui ont été alloués et non ceux qui pointent vers la mémoire ?

Oui:

TEXT[nb_str].param = (void*)temp_param+0x40000;
...
 Text *temp = &TEXT[0];
            for(ligne=0;ligne<nb_str;ligne++)             
           {
       	       free(temp->chaine);
        	       if (temp->param<(void*)0x40000) free(temp->param);
        	      *temp++;
       	        
            }
            free(TEXT);

Et tu peux utiliser le pointeur comme un pointeur normal, pas la peine de soustraire 0x40000. J'utilise l'espace fantôme.

Oui:
TEXT[nb_str].param = (void*)temp_param+0x40000;
...
Text *temp = &TEXT[0];
for(ligne=0;ligne<nb_str;ligne++)
{
free(temp->chaine);
if (temp->param<(void*)0x40000) free(temp->param);
*temp++;

}
free(TEXT);
Et tu peux utiliser le pointeur comme un pointeur normal, pas la peine de soustraire 0x40000. J'utilise l'espace fantôme.

J'avais déjà essayer avec le void mais pas le 0x40000. D'ailleurs ça représente quoi ?
J'ai trouvé une solution qui est de rajouté un élément à la structure text pour indiquer si les paramètres ont été allouées ou non et ça marche mais par contre on perd un octet par ligne, bon c'est pas énorme c'est vrai , mais le programme grossit un peu vu qu'il faut indiquer quand on alloue de la mémoire.
Je vais essayer le truc que tu m'a donné. En tout cas c'est sûr je n'aurais pas pû le trouver tout seul. Merci Kevin !

Ca marche très bien sauf qu'à ce niveau là : if (temp->param<(void*)0x40000|), | représente le curseur lors de la compilation, il y a un warning : Comparaison of distinct of pointeur types lacks a cast.
Il faut faire quoi pour y remédier ?

if ((void*)temp->param<(void*)0x40000)
Ou alors tu remplaces void* à droite par le type qu'il y a à gauche (probablement char* vu que ce sont des chaînes de caractères).

En fait il faut mettre (void*) aux deux parce-que sinon il y a un warning "Comparaison between pointer and integer".
Donc la première solution est la bonne.

Non, il n'y a certainement pas "Comparaison between pointer and integer" si tu as compris ma deuxième suggestion, ce qui n'est apparemment pas le cas.

En fait ça doit venir du fait que temp->param n'est pas un pointeur vers un char mais vers la structure des paramètre que j'ai cité dans un post plus haut, mais bon c'est pas grave ça marche. Par contre j'ai encore rien compris ce que c'était l'espace fanôme. J'ai regardé dans la doc de TIGCC mais je ne vois pas à quoi ça correspond. Si on met une autre valeur que celle-ci ça ne marchera pas ? Et sinon ça a quelles autres utilités ?

Raphaël
: Par contre j'ai encore rien compris ce que c'était l'espace fanôme. J'ai regardé dans la doc de TIGCC mais je ne vois pas à quoi ça correspond.

C'est un "mirage" des vraies adresses. Le décodage des adresses ignore certains bits, ce qui fait que l'adresse effective soit la même qu'on les mette ou non.

Si on met une autre valeur que celle-ci ça ne marchera pas ?

Ça marchera aussi avec 0x80000, 0xC0000, 0x100000, 0x140000, 0x180000, 0x1000000, 0x1040000, 0x1080000, 0x10C0000, 0x1100000, 0x1140000, 0x1180000, 0x2000000, 0x2040000, 0x2080000, 0x20C0000, 0x2100000, 0x2140000, 0x2180000, ..., 0xFF000000, 0xFF040000, 0xFF080000, 0xFF0C0000, 0xFF100000, 0xFF140000 et 0xFF180000. J'ai pris la plus petite avec laquelle ça marche.

Mouais enfin 0xAB000000 n'est pas vraiment un "mirage" : au niveau du bus, c'est exactement la même chose que 0x00000000... (les adresses ne sont que sur 24 [en fait, 23] bits)

En effet, et ça ne sert à rien pour passer outre les protections par exemple. Mais pour marquer des pointeurs comme "spéciaux", ça va aussi.

Oui, j'utilisais ça assez intensivement dans GT-Basic...

Bon là j'ai pris pas mal de retard mais j'ai fait pas mal de correction qui étaient nécessaire.
Avec preos il y avait deux trois petits crash mais maintenant il n'y a plus rien l'air d'avoir... enfin c'est à vérifié parce-que des fois ça plante au bout de la 15ème fois sans trop savoir pourquoi.
Mais par contre avec le tictex c'est la catastrophe ! Ca plante tout le temps de manière très sévère.
Alors je me demandais si le fait d'ouvir tout les programmes du répertoire main avec Hlock était une bonne idée ? ... sinon à part ça je ne vois pas trop ce qui serait à l'origine de tout ces crash.

Voilà comment je fais : SYM_Ptr = SymFindFirst (SYMSTR ("main"),FO_SINGLE_FOLDER);           while(SYM_Ptr)           {                   if((Current_File = HLock(SYM_Ptr->handle)+5)) // Ouvre le fichier courant                   {                          sub_str(0,tag_len,Current_File,TAG_File); // copie le tag.                         if(!strcmp(TAG_File,Tag))                         {                                  nb_files++;                                   List_Files[nb_files]=SYM_Ptr->name                         }                        HeapUnlock(SYM_Ptr->handle);                    }                   SYM_Ptr=SymFindNext(); // Passe au fichier suivant.

Il y a peut-être un truc qui n'est pas fait comme il faut là-dedans ?

En ce moment j'essaye de réduire au maximum la consommation des piles mais je ne sais pas si c'est si valable que ça avec les niveaux de gris. Est-ce que quelqu'un sait quel est la fréquence de l'interruption des niveaux de gris ?
E si je fais une fonction gray_idle comme ceci :

void gray_idle(void)
{
pokeIO(0x600005,0b10111);
pokeIO(0x600005,0b10111);
pokeIO(0x600005,0b10111);
pokeIO(0x600005,0b10111);
}

Ce n'est pas trop exagéré ?
Sinon j'ai rajouté un paramètre qui permettra de cacher du texte (on ne le verra pas apparaître dans le viewer à moins de maintenir appuyer une touche déterminée)... avis aux tricheurs !

Raphaël
: Est-ce que quelqu'un sait quel est la fréquence de l'interruption des niveaux de gris ?

The speed of OSC2 can be calculated using this formula (assuming the APD
time is the default):
  HW1: OSC2 speed = 242,688,000 / APD_seconds
  HW2: OSC2 speed = 162,816,000 / APD_seconds
APD_seconds should be somewhere in the range 300-360 seconds.  If the APD
time is way longer than 400 seconds on a HW2, the HW1 formula should be used
instead.  This will happen if, for example, an ignorant game reprograms the
HW2 timer with the HW1 settings.
[...]
Level 1:
  Triggered at a fixed rate: OSC2/2^11.  See $600015:7/1.

Et seulement environ une interruption sur 4 (exactement une sur 4 sur HW1, synchro avec l'écran sur HW2) est utilisée, de manière à avoir une fréquence de 90 Hz comme le LCD.

Ah ouais, donc le proc ne reste pas très longtemps en idle. Et ça ne bouffe pas plus de pile de l'arrêté et de le redémarré sur une aussi courte durée ?
Et puis sinon pour la première fois j'ai essayé la rom 2.08... avant j'avais la 2.05 et ça m'a fait un choc : les niveaux de gris sont quasiment parfait alors qu'avant il fallait choisir entre voir la différence entre pas voir la différence entre le gris foncé et le noir pour voir le gris clair ou voir le gris clair et ne pas voir la différence entre le gris fondé et le noir. Je rêve ou quoi ?

oui

Ah bon, bah mince alors. En fait avant je n'arrivais jamais à bien régler le contrast et là il n'y a plus de souci. J'hésitais à laisser la couleur gris clair dans le programme parce-qu'avec un constraste pas trop foncé on ne la voyais pas.

Bon voilà, j'ai enfin pû tester FTL Parser avec Pedrom... je crois que je vais faire un tuto sur ma page pour installer facilement Pedrom et puis comment envoyer un programme parce-qu'en les logiciels de transfert qui ne marche pas et puis les programmes qu'ils faut pour installer Pedrom c'est pas évidant !
Et il est 100 % compatible !
Par contre je me posais une question : est-ce que Pedrom gère les 3 types de fontes et possèdent une routine DrawChar (en utilisant la rom call à partir de DrawChar() de TIGCC ?).
Parce-que je pourrais alléger pas mal le programme si c'était le cas et faire une version spéciale pour Pedrom.

C'est une bonne chose que FTL Parser soit compatible avec Pedrom.

C'est une bonne chose que FTL Parser soit compatible avec Pedrom.

Ok, bah voilà c'est fait.
Par contre ce qu'il faudrait c'est un éditeur de texte parce-que sinon ça n'a pas beaucoup d'intérêt d'utiliser mon programme sous PedRom à moins d'utiliser des fichiers texte tout fait comme des cours mais pour l'instant on en est par encore là.

Par contre c'est même pas la peine de répndre à ma question : tinyX utilise Drawchar() pour loader les fonts donc ça va être possible de faire une version qui utilise le DrawChar de Pedrom (ça fera un programme plus léger et puis il n'y aura pas de code inutile).
Je fais confience à Pphd pour la rapidité de la routine DrawChar.

Par contre ce qu'il faudrait c'est un éditeur de texte

bah, il y a SIDE d'intégré à pedrom !

bah, il y a SIDE d'intégré à pedrom !

Ah d'accord je ne savais pas. Bon bah c'est parfait alors.

Ah d'accord je ne savais pas.

RTFM