Merci fvirtman pour ton retour, cela me touche de ta part, sachant que suis qu un apprenti et toi le maître. J ai lu tous tes tutos notamment sur les collisions qui sont extrêmement bien fait.

La mémoire vidéo du CPC464 est effectivement pas facile à comprendre, car comme tu l'as dit est entrelacé, et qu en plus on a 3 mode vidéo qui compliqué la donne. J'ai choisi qu un seul mode graphique qui permet d afficher 4 couleurs pour une définition correcte 320x200 .

Ceci dit étant juste un néophyte sur la question je m'intéresse à mes amours de jeunesse que sont ces premiers micro ordinateur avec lesquels j ai grandi. Le CPC464, j avais pas les moyens..... Mais mon premier micro fut le spectrum48k. Aujourd'hui j ai les 2. Avec le cpc j ai une carte connecté sur mon bus qui me permet d'y brancher une clé usb. Cela me permet de pouvoir programmer en C sur mon PC, et pouvoir l'exécuter sur mon cpc... J'attends d avoir mon Spectrum next pour faire de même..... 

Ensuite j'ai toujours un soucis de configurer code::bloc avec SDCC, j ai du loupé quelque chose...... Compiler avec. bat s'est pas terrible pour chercher les erreurs à la compilation 

Merci pour ces compliments !

Le spectrum est intéressant aussi ! Alors que l'Amstrad utilise 16 Ko pour le graphique, le spectrum en utilise un peu plus de 6, une matrice de pixels comme les monochromes, et ensuite pour la couleur, 2 couleurs par bloc de 8x8 ce qui était un vrai casse tête pour les graphistes de l'époque, mais certains ont fait des merveilles !

http://www.breakintoprogram.co.uk/computers/zx-spectrum/screen-memory-layout

Après, désolé pour Code::Blocks, je ne l'ai jamais utilisé. J'utilise surtout Visual Studio, mais je ne sais pas s'il sait faire des choses pour l'Amstrad.

@Dark-linux : As-tu résolu ton problème de passage de paramètres ?

À supposer que non, j'aurais quelques questions :

1- la page https://gist.github.com/Konamiman/af5645b9998c802753023cf1be8a2970  (indiquée par White Crow, un précédent intervenant) explique clairement ce qu'il faut faire dans ton cas mais c'est en anglais. Du coup, si c'est pas ta langue préférée, dis-nous où ça coince... Quoiqu'un traducteur automatique peut aider...

2- As-tu compris les exemples de code qui y sont proposés ? Dans ton message un peu plus haut, tu donnes le code qui contient au moins trois erreurs :

• iy n'est pas initialisé et contient donc une valeur inconnue
• l'instruction "LD DE,iy" (ligne 34) semble avoir été confondue avec "LD DE,(iy)" (qui n'existe pas) : la première transfère (copie) le contenu de iy dans DE alors que la deuxième transférerait le contenu de l'emplacement pointé par iy (et iy+1)  dans DE d'où les parenthèses autour de iy. Ce genre de transfert 16 bit ne semble pas exister sur le Z80, il faut donc le faire octet par octet.
• l'instruction "LD HL,1(iy)" (ligne 35) est décalée d'un rang : si le transfert précédent avait fonctionné, DE aurait récupéré 2 octets et l'instruction devrait donc être "LD HL,2(iy)" mais là aussi, il semble qu'il faut faire octet par octet (le compilateur devrait tiquer d'ailleurs...)
• ne pas mettre __naked à la fin de la définition de fonction ajoutera un RET supplémentaire à celui que tu as déjà mis. Ce RET ne sera jamais exécuté puisque celui qui le précède (le tiens donc) fera le retour avant. Ton programme sera donc plus long d'un octet (par __naked omis) mais le fonctionnement sera le même.

Ton code devrait donc ressembler à ça :

void plot (unsigned int x, unsigned int y) __naked
{
    (void) x;   // pour éviter les messages (Warning)
    (void) y;   // sur les paramètres non utilisés
    __asm
        ld iy,#2     ; pour enjamber les 2 octets de l'adresse de retour
        add iy,sp    ; iy vaut maintenant sp+2, il pointe donc sur x(low)

        ld e,0(iy)   ;x(low)
        ld d,1(iy)   ;x(high)   ; DE contient maintenant x

        ld l,2(iy)  ;y (low)
        ld h,3(iy)  ;y (high)   ; HL contient maintenant y

        call #0xBBEA

        ret
    __endasm;
}

J'ai fait ce code par copier-coller et n'ai pas possibilité de le vérifier (sauf à installer tout l'environnement, ce qui n'est pas à l'ordre du jour)

Dernier point : comme dit par un précédent intervenant, un CALL suivi d'un RET peut être remplacé par un JP mais ça rend le code moins clair et le compilateur fait cette optimisation de toute façon donc autant laisser le CALL-RET

-
Edité par JagV12 7 juin 2021 à 19:12:23

Au fait merci JagV12 oui j'ai résolu mon problème de passage de valeurs pour mes fonctions. Cependant faire du C avec un Z80 n'est pas la meilleure idée que j'ai eu. Difficile à mettre en œuvre, un peu plus rapide que le basic, gourmand quand même une fois compile sachant que je dispose en moyenne de 32ko de mémoire de ram. Du coup je m'oriente vers l'assembleur, qui me permet de pouvoir mélanger programme basic (facile à mettre en œuvre) et routines en langage machine.

Merci @+