Programmer des applis .g3a sur graph 90+E

[Nemhardy]

Tu as donc fait disparaître les erreurs qui posaient problème au début ? En mettant à jour la dll dans quel SDK (l'ancien ou ma tentative plus récente) ? Donc plus de soucis de SDK ?

Qu'appelles-tu «anciens programmes» ? Du code peut ne pas marcher car il contient des erreurs même si il est publié ; il peut aussi utiliser des headers dont la version est différente de la tienne, il faut parfois adapter un peu. Les erreurs ici ne me semblent pas dépendre de la norme C utilisée a priori, et de toute manière GCC te permet de choisir celle utilisée. Sans plus de code je ne pourrai pas vraiment t'aider plus que ça.

[Ti64CLi++]

J'ai l'impression qu'il a mit a jour la dll de cygwin, et non du SDK

[Nemhardy]

Vu qu'il n'y a pas à installer Cygwin pour utiliser le SDK, en tout cas il n'y avait pas sur les anciennes versions de Windows, je suppose que celui-ci embarque plus ou moins une version de Cygwin.

[Lionel Debroux]

Des erreurs comme

implicit declaration of function 'Bdisp_AllClr_VRAM'

indiquent soit que tu n'inclus pas les headers qui contiennent cette fonction, soit que cette fonction a disparu des headers et que tu dois adapter ton code.

[xavdark17]

Merci pour vos réponses !
J'ai mis à jour le fichier cygwin1.dll dans l'ancien SDK (l')

[xavdark17]

Désolé petite erreur...
"(Le nouveau ne fonctionnant pas)
Il est possible de mettre n'importe quelle norme C dans le makefile ? ou du C++?(je ne suis pas trop au point là dessus)

Pour les "anciens programmes" je parle des sources que je trouve sur différents sites que je n'arrive pas à compiler, je me demandais si ils étaient écrits dans une autre "norme C"
Ce code par exemple a une particularité ?:

Code: Select all

#include <fxcg/display.h>
#include <fxcg/keyboard.h>
static void getStrn(int x,int y,int n,char*buffer){
    int start = 0; // Used for scrolling left and right
    int cursor = 0; // Cursor position
    buffer[0] = '\0'; // This sets the first character to \0, also represented by "", an empty string
    DisplayMBString((unsigned char*)buffer, start, cursor, x, y); // Last to parameters are X,Y coords (not in pixels)
    int key;
    while(1){
        GetKey(&key); // Blocking is GOOD.  This gets standard keys processed and, possibly, powers down the CPU while waiting
        if(key == KEY_CTRL_EXE){
            // Ok
            break;
        }else if(key == KEY_CTRL_EXIT){
            // Aborted
            break;
        }
        if(key && key < 30000){
            cursor = EditMBStringChar((unsigned char*)buffer, n, cursor, key);
            DisplayMBString((unsigned char*)buffer, start, cursor, x,y);
        }else{
            EditMBStringCtrl((unsigned char*)buffer, n, &start, &cursor, &key, x, y);
        }
    }
}
static void askQ(const char*msg,char*buf,int n){
    //Clear areas from old question.
    struct display_fill fill;
    fill.x1=0;
    fill.x2=383;
    fill.y1=144;
    fill.y2=168;
    fill.mode=0;
    Bdisp_AreaClr(&fill,1,0);
    PrintXY(1,6,msg,0,0);
    getStrn(1,7,n,buf);
}
void main(void){
    int x,y;
    char buf[1024];//In this example nothing is done with the buffer, I leave it as an exercise to the reader to do something with the inputted text.
    Bdisp_EnableColor(0);
    Bdisp_AllClr_VRAM();
    //Print the "explanation"
    PrintXY(1,1,"  Stop!",0,0);
    x=0;
    y=32;
    PrintMini(&x,&y,"Who would cross the Bridge of Death",0,0xFFFFFFFF,0,0,0,0xFFFF,1,0);
    x=0;
    y=56;
    PrintMini(&x,&y,"must answer me these questions three,",0,0xFFFFFFFF,0,0,0,0xFFFF,1,0);
    x=0;
    y=80;
    PrintMini(&x,&y,"ere the other side he see.",0,0xFFFFFFFF,0,0,0,0xFFFF,1,0);
    PrintXY(1,5,"  What... is",0,0);
    for(;;){
        askQ("  your name?",buf,1024);
        askQ("  your quest?",buf,1024);
        askQ("  your favorite color?",buf,1024);//The text fits by using American spelling. Yes I know Monty Python is a British show.
    }
}

[Nemhardy]

D'accord pour le SDK, si ça marche pour toi c'est déjà bien je suppose.

Il n'y a rien qui me saute aux yeux ici vis à vis d'un problème de norme ; tu as accès au «réglage» de la normes prise en compte par GCC dans la Makefile : normalement est définie une variable CFLAGS, dans laquelle tu peux ajouter l'option `-std=c99` pour que la norme ambiente soit celle du C99, mais le réglage par défaut convient en général à ce niveau là.

Ici les erreurs viennent de headers qui ne devaient pas être les même que ceux que tu as toi ; les erreurs sont assez explicites, cherche dans quel headers de ton SDK sont définies les constantes qui correspondants aux touches (KEY_CTRL_EXE, etc), et dans quel header la structure display_fill est définie, et inclue-les, je pense que ça devrait suffire.

[critor]

Code: Select all

unsigned short*VRAM = (unsigned short*)0xA8000000;

Qui correspond tout simplement à coder en dur l'adresse de la mémoire vidéo : sur les anciens modèles, celle-ci ne changeait jamais et donc ça n'avait jamais vraiment posé de soucis, mais maintenant ça ne marche plus. Mais ce n'est pas vraiment un problème puisqu'on dispose d'une fonction GetVRAMAddress qui permet de s'adapater aux différents modèles sans avoir rien à coder en dur.
Il faudrait donc remplacer la ligne qui posait problème plus haut par :

Code: Select all

unsigned short*VRAM = (unsigned short*)GetVRAMAddress();

J'ai retéléchargé le SDK sur le lien que tu as donné :
http://jonimoose.net/calcstuff/prizm/PrizmSDK-0.3.zip

Mon programme utilisant GetVRAMAddress ne compile pas.

mire.c:(.text.startup+0x1c): undefined reference to `_GetVRAMAddress'

Le lien que tu donnes dit d'inclure fxcg/display.h :
http://prizm.cemetech.net/index.php/GetVRAMAddress

Mais je ne vois aucune trace de cette fonction dans le fichier display.h que j'ai en local.
Et pas davantage dans sa version en ligne, donc je ne comprends vraiment pas ce qui se passe :
https://github.com/Jonimoose/libfxcg/bl ... /display.h
J'ai bien mis un #include <display.h> mais de toutes façons je ne vois aucune trace de cette fonction

[Nemhardy]

Alors, encore une fois, c'est là que le bazar de ces SDK rentre en jeu… ^^'

Il est vrai que j'ai été un peu elliptique à ce niveau là dans mon message : la fonction GetVRAMAddress n'est pas disponible par défaut dans le SDK dont j'ai fourni le lien (je n'en suis pas certain mais plutôt convaincu et ce que tu décris va dans ce sens). Le lien du wiki se réfère à la dernière version de la libfxcg, qui n'est pas celle livrée avec le SDK (bien plus vieille…).
Cependant, étant donné que cela reste un syscall élémentaire, la plupart des programmes l'utilisant et construits avec ce SDK l'implémentent en quelques lignes dans le code de leurs projet, de la manière suivante :

Code: Select all

void* GetVRAMAddress()
{
   __asm__("mov.l syscall_adress, r2\n"
       "mov.l getVRAM, r0\n"
       "jmp @r2\n"
       "nop\n"
       "syscall_adress: .long 0x80020070\n"
       "getVRAM: .long 0x01E6");
}

(Il s'agit simplement d'appeler le syscall 0x01E6.)

Mais encore une fois ça démontre que… c'est le bazar et tout et tout…

Il s'avère que je suis en vacances et chez moi (c'est à dire avec un windows sous la main assez simplement) ; sans rien promettre (fêtes et examens par ci par là à gérer aussi… ^^'), je peux essayer de packager un nouveau truc, incluant la dernière version de la libfxcg, et donc plus fournie et notamment cohérente avec le Wiki.

D'ailleurs si tu n'en vois pas trace de la fonction dans la version en ligne, c'est que le fichier d'en-tête précisé par le wiki est bien fxcg/display.h (ici) et pas simplement display.h.

[critor]

Merci beaucoup à toi, ça marche avec ton astuce de définir GetVRAMAddress() dans le projet.

N'y aurait-il pas un moyen de refaire des wiki+tutos sur Planète Casio ?
Vu que les informations communiquées sur le wiki Cemetech semblent incomplètes/inexactes (c'est très loin d'être le seul exemple de problème que j'ai rencontré en me basant sur ce wiki) et plus maintenues depuis des années.

En passant, ce serait l'occasion de rafraîchir les infos dans le contexte de la nouvelle Graph 90+E.