Un petit post pour vous exposer pour l'instant quelques réflexions et pistes de recherche par rapport au rafraichissement de l'écran sur Prizm, qui est un des facteurs rendant l’exécution de programmes "lente". Rien de bien concret pour l'instant, mais je partage juste des idées/explications pour avoir des éventuels retours.

Il y a quelques temps, avec Lancelot, nous avions discuté de la faisabilité d'une fonction équivalente à Bdisp_PutDisp_DD() (ou la fonction permettant de transférer le contenu de la VRAM à l'écran et donc de l'afficher). Le "truc" c'est que la quantité d'informations à envoyer à l'écran est assez énorme : la VRAM est un buffer de 165ko environ (au passage plus que ce qu'un malloc peut allouer comme espace ). Le syscall évoqué plus haut pratique donc une copie en utilisant le principe de DMA, soit un accès direct à la mémoire. Cela permet de "décharger" le processeur qui ne s'occupe que de lancer le transfert (et éventuellement de contrôler le bon déroulement de celui-ci). Cependant, ce syscall est en quelque sorte bloquant, c'est à dire que tant que le transfert n'est pas terminé, et bien, le programme est en pause. Ce n'est pas une ineptie totale de Casio, mais quelque chose d'assez logique/sécuritaire car il serait fâcheux de ré-entrer dans des fonctions de dessin qui modifieraient le contenu de la VRAM avant même que celle-ci ait fini d'être transférée, ou même de relancer un transfert alors qu'un autre est déjà en cours... Cela peut néanmoins s'avérer gênant car le temps de transfert est assez conséquent.

ProgrammerNerd, auteur notamment du port d'Open JackRabbit ou du lecteur Mpeg2 que vous pouvez voir dans cette news, a développé une fonction permettant de résoudre quelque-peu ce problème. Il a écrit un "set" de fonctions (qui est d'ailleurs une sorte de "traduction" en C de la fonction en ASM que l'on peut voir dans la doc de SimLo, donc plus simple à mettre en place) qui se décompose en deux fonctions : l'une permettant simplement de lancer le transfert, et l'autre permettant de bloquer le programme en attendant la fin du transfert. Le transfert n'est donc théoriquement pas plus rapide, car utilisant la même unité de DMA, mais... enfin, j'explique ça dans la suite.

Je vous mets ici le code tel qu'il est dans le lecteur Mpeg2



C'est pas très joli je vous l'accorde (en mettant en parallèle avec la doc de SimLo et les commentaires, on arrive à comprendre quelques trucs, mais après, le principe est juste de lancer un transfert, donc rien de bien passionnant). Quoi qu'il en soit, la fonction DoDMAlcdNonblock(); permet de lancer le transfert et DmaWaitNext() comme son nom l'indique permet de "bloquer" le programme jusqu'à la fin du transfert précédent.

Présentée comme ça, la fonction n'est pas très intéressante, car elle se base uniquement sur la VRAM et oblige donc à attendre la fin du transfert précédent pour pouvoir dessiner dedans. Néanmoins, on voit clairement que l’adresse de la VRAM est juste mise dans un registre comme adresse de source pour la copie : il me semble donc envisageable d'utiliser 2 buffers et de les copier en alternance : ainsi, l'un est en train d'être copié tandis que l'autre est en train d'être remplis. Le soucis majeur serait la taille de ce buffer relativement conséquente, mais il faut savoir qu'il existe une zone de la mémoire destinée à contenir la copie de la VRAM (donc de même taille que cette dernière) crée suite à l'appel de SaveVRAM_1() qui est potentiellement exploitable (j’attends une réponse sur Cemetech pour en savoir plus et confirmer/infirmer la chose). Cela aurait quelques inconvénients (comme le fait de devoir travailler en (char*) et non plus en (short*), l'adresse 0 de la zone étant impaire) mais je pense que le potentiel semblant de "multithreading" (on copie d'un côté et dessine de l'autre) peut être assez "rentable" pour faire abstraction de ces défauts.

On peut envisager un programme fonctionnant ainsi :



Où les adresses des buffers vidéos utilisées dans la fonction de dessin et de rafraichissement seront alternativement échangées : calcul() et dessin() seront donc potentiellement appelée alors que le transfert est toujours en cours, ce qui n'est pas possible avec le syscall de base !
Le DmaWaitNext() reste important car empêchant les transferts de se chevaucher .

Une autre piste que l'on peut envisager est le fait de pouvoir restreindre la zone de la VRAM à copier pour, par exemple, dans le cadre d'un RPG, actualiser uniquement les zones qui doivent être actualisées (mouvement des persos) et ne pas toucher au décor par exemple (je n'ai pas fait de tests à ce niveau là, donc plus hypothétique peut être), ce qui aurait, je pense le mérite d’accélérer à nouveau les transferts.