CC Compilateur C on-calc - Page 5

meuh non

ben si

comment faire pour restaurer l'écran après l'avoir effacé dans prog ?
j'utilise ça :

char ecran[3840];
memcpy(ecran,0x4c00,3840);
...
...
memcpy(0x4c00,ecran,3840);

mais ça ne marche pas...


Et aussi, si je déclare une chaine comme ceci :

char *chaine;
int a=5;
...
sprintf(chaine,"%d",a);

au moment du sprintf, le prog s'arrête et il y a une boite de dialogue qui m'affiche "Protected memory violation"
[edit]Edité par jackiechan91 le 07-03-2002 à 16:41:16[/edit]

Faut peut-être penser à allouer de la mémoire et y faire pointer chaine avant toute chose...

Pour ton pb avec memcpy, c'est à cause de CC qui n'accepte pas les prototypes de fonctions paramétrés.
Appelle la fonction de cette façon : memcpy(ecran, 0x4c00L, 3840L). Le L précise au compilateur (CC) qu'il doit interpréter le nombre sur 32 bits, donc "bouffer" 4 octets sur la pile en le poussant. Pour être clair, l'écriture est parfaitement équivalente à memcpy(ecran, (unsigned long)0x4c00, (unsigned long)3840).

Ou alors tu utilises un fichier "d'en-tête" screen_h défini ainsi :

 [2]:/*
 :Fonctions de manipulations d'ecrans
 :Copyright ZdRUbAl :D 2002
 :*/[/2]
 :typedef unsigned char LCD_BUFFER[3840];
 :
 :void *LCD_MEM = 0x4C00;
 :
 :unsigned long LCD_SIZE=3840;
 :
 :typedef enum Couleurs {BLACK,WHITE} COLOR;
 :LCD_save(ecran) LCD_BUFFER ecran;
 :{
 : memcpy(ecran,LCD_MEM,LCD_SIZE);
 :}
 :LCD_restore(ecran) LCD_BUFFER ecran;
 :{
 : memcpy(LCD_MEM,ecran,LCD_SIZE);
 :}
 :ScreenFill()
 :{
 : memset(LCD_MEM,(short)0xFF,LCD_SIZE);
 :}
 :LCD_BUFFER_Fill(scr,couleur) LCD_BUFFER scr; COLOR couleur;
 :{
 : if(!couleur) memset(scr,(short)0xFF,LCD_SIZE);
 : else memset(scr,(short)0x00,LCD_SIZE);
 :}
 :[2]/* Fin screen.h */[/2]

Que tu utilise ainsi dans csrc :

#include "screen_h"
main()
{
 LCD_BUFFER ecran;
 LCD_save(ecran);
 clrscr();
 ngetchx();
 LCD_restore(ecran);
}

En supposant que tu ait bien défini les décalages pour les différents ROM_CALLs dans ams_c.

Merci à vous deux, Thibaut et Zdrubal...

j'ai un autre pb...

quand je compile mon prog, je n'ai aucune erreur, mais quand je le lance, la status line est effaçée, ainsi que toutes les infos se trouvant en dessous et la barre de saisie de l'écran HOME (là où on tape les calcul, quoi). puis le chiffre en bas à droite (qui indique combien de calculs peuvent être stockés dans home) passe de x/99 à 0/30, et l'indicateur FUNC s'affiche (même si j'étais en POLAR ou PARAM).
Au niveau de l'écran HOME, c'est comme si on avait fait [F1]+[8]. Il n'y a pas le nom de mon prog suivi de DONE...
J'ai un peu regardé ma source, mais je ne trouve pas le pb. Vous pensez qu'il pourrait venir d'où (pour savoir où il faut que je regarde mieux) ?

Aurais-tu oublié de faire un PortRestore après un PortSet?

Non, je n'utilise pas de PortSet, de toutes façons...
Mais en fait c'est bon, ça remarche. J'ai reprogrammé certaines parties du prog et ça marche maintenant. J'ai changé plein de trucs, donc je ne sais pas lequel avait fait foirer...

finalement, j'ai à nouveau rencontré ce bug en réécrivant mon prog, mais je n'arrive pas à trouver d'où il vient... (au fait, le bug réinitialise le contraste aussi).
Je pense que j'ai trouvé d'où vient l'erreur : c'est quand on met 2 DrawStr à la suite...
[edit]Edité par jackiechan91 le 09-03-2002 à 13:53:24[/edit]

bon ben g testé mais y a un blem....
les fichier a inclure faut les taper snif!
(4 ou 5 page!)
connaissait po un prog qui converti les text en 89t?

y'en a sur ticalc...
sinon, y'a le TIGL

txt289, sur ticalc....

ou alors copier coller dans txtedit

oué, ou copier coller dans l'editeur de "donnée" du graphlink....
[edit]Edité par misato le 10-03-2002 à 12:23:30[/edit]

merci pour txt289, mais bon c po la peine d'etre aussi agressif ct juste une question, c'est tellement l'usine a gaz sur ticalc

qui est agressif ici ?

bon oki revenons au sujet.....
toutes les lib de tigcc sont compatible?

Bien sûr que non
La librairie gray.h, déjà, sera dure à implémenter, je pense (on ne peut pas faire d'asm-inline).
Ensuite, comme cc ne supporte pas encore les #define, beaucoup de macro-commandes sont à revoir

>connaissait po un prog qui converti les text en 89t?

Il y a txt2ti.exe dans cc.zip (répertoire as/example).

>on ne peut pas faire d'asm-inline

Si on peut... tu dois pas avoir la derniere version.

Avec #asm et #endasm je crois

> Nitro
Oui, la mienne date. Merci de me prévenir, je vais me mettre à jour

bon ben comme on peut po inclur de lib deja existante, on peut rien faire......
ou alors faut tout reecrire

-
[edit]Edité par Thibaut le 10-03-2002 à 16:14:04[/edit]

Je fais remonter ce topic, beaucoup de personnes utilisent encore CC

Au fait, j'ai l'impression que CC ne gère pas bien les double ni les float.
À la compilation, dans la source en assembleur, j'obtiens des erreurs de syntaxe à chaque affectation d'une variable de type double ou float.
La ligne concerné est : move.l #,-4(a6)
Je n'y connais rien en ASM, mais je crois que l'erreur vient du fait qu'il n'y ait aucune valeur après le #. (au fait, je ne sais pas si ça peut changer qq chose, mais je précise que mes variables sont locales)

Et aussi, je n'arrive pas à utiliser la fonction HeapAllocPtr...
Je l'utilise comme ça :
unsigned char *ecran;
ecran=(unsigned char *)HeapAllocPtr((unsigned long)3840);
HeapFreePtr((unsigned char *)ecran);
Mais j'obtiens une erreur au niveau de la deuxième ligne : A cast from short to pointer is dangerous.

Et sinon, est-ce que c'est possible de caster un long en short ?
Par ex : long a=5;short b;b=(short)a;
(mais cet exemple ne marche pas, sous prétexte qu'il ne faut pas caster avec un type plus petit).

>Au fait, j'ai l'impression que CC ne gère pas bien les double ni les float.

Oui, les nombres en virgule flottante ne sont pas supportés du tout par CC. Ça a été lourd pour TIGCC à cause du format bien particulier utilisé par TI, et Nitro m'a dit que ce sera encore plus lourd pour CC, donc ça ne sera probablement pas pour bientôt.

>Et aussi, je n'arrive pas à utiliser la fonction HeapAllocPtr...
>Je l'utilise comme ça :
>unsigned char *ecran;
>ecran=(unsigned char *)HeapAllocPtr((unsigned long)3840);
>HeapFreePtr((unsigned char *)ecran);
>Mais j'obtiens une erreur au niveau de la deuxième ligne : A cast from short to pointer is dangerous.

Bon, déjà, il y a un bogue de CC là: un warning empêche la création de asmsrc, ce qui ne devrait pas être le cas.
Ensuite, il y a en effet un problème: sans prototype, le type de HeapAllocPtr est présupposé comme short. La solution: mettre un prototype sans arguments (les prototypes complets ne sont pas supportés par CC). Donc:

unsigned char *HeapAllocPtr();

main()
{
 unsigned char *ecran; 
 ecran=(unsigned char *)HeapAllocPtr((unsigned long)3840); 
 HeapFreePtr((unsigned char *)ecran);
}

Avec ça, CC ne râle plus.

Malheureusement, ça ne marche toujours pas: CC attend la valeur de retour en d0 alors que c'est un pointeur et qu'elle est donc en a0. C'est un bogue.