La Place des Développeurs Coder en C avec SDCC
Reprise du message précédent
C'est à EricB de voir, mais vu qu'il semble souhaiter une lib "clef-en-main", ça me semblerait dangereux de proposer du code qui ne gère pas ce genre de cas.Après, on peut aussi considérer que jouer avec le VDP dans les hook est une utilisation trop "avancé" pour nécessité d'être supporté par Fusion-C.
Ca se discute.
On est toujours ignorant avant de savoir.
Mes routines "classiques" VDP sont toutes protégées par DI/EI en entier.
Par contre j'ai fait comme GRAUW pour la routine que j'utilise pour faire les PrintBitmap.
Je vais sans doute les protéger aussi...
Par contre comme j'utilise aussi HMMC/LMMC ce topais est très intéressant
https://www.msx.org/forum/msx-talk/development/transferring-data-after-hmmc-lmmc-command?page=0
Par contre j'ai fait comme GRAUW pour la routine que j'utilise pour faire les PrintBitmap.
Je vais sans doute les protéger aussi...
Par contre comme j'utilise aussi HMMC/LMMC ce topais est très intéressant
https://www.msx.org/forum/msx-talk/development/transferring-data-after-hmmc-lmmc-command?page=0
J'ai un peu de mal à voir l'intérêt de contourner ce "problème" avec cette astuce plus lourde pour le VDP alors qu'il est si simple d'utiliser HMMC/LMMC normalement. 
Perso, j'envoie ma premier commande avec data[0] dans couleur, puis je fais une boucle sur ++data. C'est tout.
Perso, j'envoie ma premier commande avec data[0] dans couleur, puis je fais une boucle sur ++data. C'est tout.
On est toujours ignorant avant de savoir.
Oui aoineko, après coup, je me suis aperçu qu'on avait pas besoin de ça, en tout cas en C avec les structures c'est inutile. Peut être que dans d'autres circonstances ça doit avoir un intérêt, sinon il n'y aurait pas un topic dédié... ? 
Edité par
ericb59
Le 28/01/2021 à 10h34
Edité par
ericb59
Le 28/01/2021 à 10h34
Le seul défaut de la méthode par défaut, c'est que c'est pas très intuitif.
Mais une fois encapsulé dans les fonctions qui vont bien, c'est transparent et je vois pas en quoi ça pourrait poser problème (même en assembleur).
Ceci dit, la notion de commande 'dummy' est intéressante ; je vois pas d'application concrète, mais c'est toujours bon à savoir.
Mais une fois encapsulé dans les fonctions qui vont bien, c'est transparent et je vois pas en quoi ça pourrait poser problème (même en assembleur).
Ceci dit, la notion de commande 'dummy' est intéressante ; je vois pas d'application concrète, mais c'est toujours bon à savoir.
On est toujours ignorant avant de savoir.
@aoineko SI tu as l'occasion, peux tu tester la version 4.07 de SDCC ?
J'ai des problèmes pour l'utiliser sur Windows...ca compile mal, et Hex2bin me sort des trucs aberrants...
Où bien il y a un truc que j'ai pas compris avec cette version peut être ?
J'ai des problèmes pour l'utiliser sur Windows...ca compile mal, et Hex2bin me sort des trucs aberrants...
Où bien il y a un truc que j'ai pas compris avec cette version peut être ?
J'ai testé la version SDCC 4.0.7 #12003 il y a qq semaines et j'ai vu aucun problème (il y avait même qq optims sympa sur le code assembleur).
Tu testes quelle version exactement ?
Après, la version 4.0.7 n'est pas encore une version stable, donc c'est pas impossible qu'il reste qq soucis.
Perso, je préfère toujours rester sur la dernière version stable... à moins qu'une super fonctionnalité mérite vraiment le risque d'utiliser une nightly-build.
Tu testes quelle version exactement ?
Après, la version 4.0.7 n'est pas encore une version stable, donc c'est pas impossible qu'il reste qq soucis.
Perso, je préfère toujours rester sur la dernière version stable... à moins qu'une super fonctionnalité mérite vraiment le risque d'utiliser une nightly-build.
On est toujours ignorant avant de savoir.
je pense que tu n'as pas du t'apercevoir de quoi que ce soit en fait. Du fait que tu n'utilises pas la librairie par défaut.
Il semble qu'il aient changé le nom de fonctions, comme _uitoa ou _itoa, en les remplaçant par des version avec un double underscore __itoa.
DU coup ma fonction printf, qui utilise ces fonctions ne fonctionnais plus... Pas grave, je me suis dit, je vais mettre à jour...
Sauf qu'après la recompilation de la librairie, plus rien ne fonctionnait !
Est-ce que tu connais un endroit où toutes les motifs effectuées dans les updates sont répertoriées en détail ? Car le changelog.txt ne semble pas complet et surtout ne m'informe pas beaucoup.
Il semble qu'il aient changé le nom de fonctions, comme _uitoa ou _itoa, en les remplaçant par des version avec un double underscore __itoa.
DU coup ma fonction printf, qui utilise ces fonctions ne fonctionnais plus... Pas grave, je me suis dit, je vais mettre à jour...
Sauf qu'après la recompilation de la librairie, plus rien ne fonctionnait !
Est-ce que tu connais un endroit où toutes les motifs effectuées dans les updates sont répertoriées en détail ? Car le changelog.txt ne semble pas complet et surtout ne m'informe pas beaucoup.
Les trucs importants sont directement dans la doc SDCC : http://sdcc.sourceforge.net/doc/sdccman.pdf
Depuis la 4.0.0, il n'y a qu'un point qui a été ajouté et c'est effectivement ne renommage des fonctions de conversion de nombre vers chaine de caractère :
Depuis la 4.0.0, il n'y a qu'un point qui a été ajouté et c'est effectivement ne renommage des fonctions de conversion de nombre vers chaine de caractère :
Code :
• In 4.0.3, _itoa, _uitoa, _ltoa, _ultoa were renamed to __itoa, __uitoa, __ltoa, __ultoa.
On est toujours ignorant avant de savoir.
Alors ce qui est étrange c’edt que sur Mac j’utilise la 4.0.3 et maintenant la 4.0.7 sans que je ne me sois aperçu de rien...
Je n’ai pas eu d’avertissement à la compilation , alors que sur Windows ça m’affiche des erreurs
Je n’ai pas eu d’avertissement à la compilation , alors que sur Windows ça m’affiche des erreurs
Rien à voir, mais pour info, j'ai archivé un module de gestion de l'horloge RTC (Ricoh RP-5C01) via les ports (sans accès au Bios).
https://github.com/aoineko-fr/CMSX/blob/master/cmsx/src/clock.h
J'ai aussi ajouté une font style "horloge digitale" et un programme de test (s_clock.c).
https://github.com/aoineko-fr/CMSX/blob/master/cmsx/src/clock.h
J'ai aussi ajouté une font style "horloge digitale" et un programme de test (s_clock.c).
On est toujours ignorant avant de savoir.
@ericb59 Y a un problème avec la fonction que tu as mis sur MRC (http://msx.ebsoft.fr/fusion-c/examples/ft_wait.c).
Prenons l'exemple d'un jeu ou tu veux synchroniser ta boucle de jeu toutes 4 frames du VDP, ça te laisse plein de temps pour des opérations CPU ou GPU, mais du coup, le temps que ta boucle principale arrive à la fonction de synchronisation, plusieurs cycles VDP seront déjà potentiellement passés. Donc si tu fais un FT_Wait(4), tu vas attendre 4 frames en plus de celles qui se sont déjà écoulées.
Ce qu'il faut faire, c'est incrémenter un compteur dans le H.TIMI, attendre que cette valeur arrive à 4, puis la reset et relancer une nouvelle boucle de jeu.
Un truc du genre :
Prenons l'exemple d'un jeu ou tu veux synchroniser ta boucle de jeu toutes 4 frames du VDP, ça te laisse plein de temps pour des opérations CPU ou GPU, mais du coup, le temps que ta boucle principale arrive à la fonction de synchronisation, plusieurs cycles VDP seront déjà potentiellement passés. Donc si tu fais un FT_Wait(4), tu vas attendre 4 frames en plus de celles qui se sont déjà écoulées.
Ce qu'il faut faire, c'est incrémenter un compteur dans le H.TIMI, attendre que cette valeur arrive à 4, puis la reset et relancer une nouvelle boucle de jeu.
Un truc du genre :
Code C :
unsigned char g_VSynchCount = 0; void HTIMI_Handler() { // ... g_VSynchCount++; } void FT_Wait(unsigned char cycles) __FASTCALL { while(g_VSynchCount < cycles) {} g_VSynchCount = 0; }
On est toujours ignorant avant de savoir.
Ben, le gars demande comment faire une PAUSE, pas de faire une synchro...
Ma routine mets en pause le programme pour X frames...
Je ne comprend pas où tu veux en venir en fait...
Ma routine mets en pause le programme pour X frames...
Je ne comprend pas où tu veux en venir en fait...
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie