Comment des appareils comme le Game Boy Advance atteignent-ils leur taux de rafraîchissement?

J'ai conçu mon propre appareil de jeu portable basé sur un microcontrôleur AVR et un petit écran OLED.

J'ai commencé avec un écran monochrome 128x64 pixels et je peux facilement y dessiner à plus de 60 images par seconde.

Je l'ai récemment retravaillé pour utiliser un OLED RVB, 128x128 pixels sans vraiment trop réfléchir pour constater que je ne pouvais atteindre que 4 FPS. Après une réflexion et une refactorisation soigneuse, je peux obtenir jusqu'à 12 images par seconde si je ne me soucie pas trop de faire autre chose!

Ma question est - comment un appareil comme le GBA (Game Boy Advance) a-t-il atteint une fréquence d'images de près de 60 images par seconde? J'ai pensé à avoir un «processeur graphique» séparé mais j'ai réalisé que je serais toujours goulot d'étranglement en transférant les données d'affichage à cela.

Je me demandais également à propos de l'utilisation de l'interface parallèle 8 bits résiduelle que la plupart de ces écrans ont tendance à avoir, ce qui pourrait me permettre d'accélérer de 8 fois, sauf que les MCU modernes n'ont pas tendance à avoir des interfaces matérielles parallèles comme elles le font pour la série et le bit. frapper mangera probablement beaucoup de gain de vitesse.

Quelles autres options existent?

J'utilise actuellement un ATmega1284P connecté à un contrôleur OLED SSD1306 via USART-SPI. Voilà la version monochrome.

L'écran couleur était un SSD1351, non connecté à l'origine au SPI matériel. Je n'étais pas convaincu que cela ferait suffisamment de différence, c'est tout simplement trop lent dans l'ensemble

Je sais que je peux obtenir des MCU plus rapides, mais je veux savoir quelles autres options je pourrais explorer - le processeur GBA est beaucoup plus lent que mon 1284!

D'autres réponses couvrent assez bien votre question à un niveau abstrait (matériel), mais ayant une expérience réelle avec la GBA en particulier, j'ai pensé qu'une explication plus détaillée pourrait valoir la peine.

Le GBA avait de nombreux modes et paramètres de dessin qui pouvaient être utilisés pour contrôler la façon dont le processeur graphique interprétait la RAM vidéo, mais une chose était incontournable: la fréquence d'images. Le processeur graphique dessinait à l'écran dans une boucle presque constante (plus de détails ci-dessous). (C'est probablement le bit le plus pertinent pour votre question.)

Il tracerait une ligne à la fois en prenant une très courte pause entre chacun. Après avoir tracé la dernière ligne du cadre, il faudrait une pause à peu près égale au temps nécessaire pour tracer 30 lignes. Puis recommencez. Le timing de chaque ligne et le timing de chaque image étaient tous prédéterminés et gravés dans la pierre. À bien des égards, le processeur graphique était vraiment le maître de ce système et vous deviez écrire vos jeux sur son comportement, car il continuerait à faire ce qu'il faisait, que vous soyez prêt ou non.

Environ 75 à 80% du temps, il poussait activement vers l'écran. Quelles fréquences d'images pourriez-vous atteindre si vous faisiez de même?

Ce 80% du temps était également ce que le CPU devait traiter les entrées utilisateur, calculer l'état du jeu et charger les sprites / tuiles dans les zones de VRAM qui étaient actuellement hors écran (ou du moins non incluses dans la ligne en cours de tracé).

Les 20% entre les images étaient tout ce que le CPU devait modifier les paramètres vidéo ou la RAM qui auraient un impact sur l'ensemble de l'image suivante.

À la fin de chaque ligne, le processeur graphique enverrait une interruption de synchronisation de ligne au CPU. Cette interruption peut être utilisée pour modifier les paramètres de quelques sprites ou de quelques calques d'arrière-plan (c'est ainsi que vous pouvez obtenir un effet comme un projecteur conique, en modifiant la taille et l'emplacement de l'un des masques rectangulaires entre chaque ligne tracée. en ce qui concerne le matériel, toutes ces régions sont rectangulaires.). Vous devez faire attention à garder ces mises à jour petites et terminer avant que le processeur graphique commence à dessiner la ligne suivante ou vous pouvez obtenir des résultats moches. Le temps passé à traiter ces interruptions réduit également ces 80% du temps de traitement du processeur ...

Pour les jeux qui ont tiré le meilleur parti de ce système, ni le CPU ni le processeur graphique n'ont jamais pris une vraie pause; chacun se poursuivait dans la boucle en mettant à jour ce que l'autre ne regardait pas actuellement.

La caractéristique clé de toutes les consoles de jeux qui les distinguaient des premiers PC et pratiquement tous les ordinateurs personnels (1) était les sprites matériels .

Le guide de programmation GBA lié montre comment ils fonctionnent du point de vue du processeur principal. Les bitmaps représentant le joueur, l'arrière-plan, les ennemis, etc. sont chargés dans une zone de mémoire. Une autre zone de mémoire spécifie l'emplacement des sprites. Ainsi, au lieu d'avoir à réécrire toute la RAM vidéo à chaque image, ce qui prend beaucoup d'instructions, le processeur n'a qu'à mettre à jour l'emplacement des sprites.

Le processeur vidéo peut alors travailler pixel par pixel pour déterminer le sprite à dessiner à ce point.

Cependant, cela nécessite une RAM à double port partagée entre les deux, et je pense que dans le GBA, le processeur vidéo est sur la même puce que l'ARM principal et le processeur Z80 secondaire.

(1) Exception notable: Amiga

"Ma question est - comment un appareil comme le GBA a-t-il atteint une fréquence d'images de près de 60fps?"

Pour répondre à la question, ils l'ont fait avec un processeur graphique. Je suis sûr que le Game Boy a utilisé des graphismes de sprites. À un niveau supérieur, cela signifie que le processeur graphique reçoit des éléments tels qu'une image d'arrière-plan, une image de Mario et une image de Princess Peach, etc. beaucoup en x et y, superposer l'image n ° 3 de Mario à cette position x, y ", etc. Ainsi, le processeur principal ne se préoccupe absolument pas de dessiner chaque pixel, et le processeur graphique ne se préoccupe absolument pas de calculer l'état de la Jeu. Chacun est optimisé pour ce qu'il doit faire, et le résultat est un très bon jeu vidéo sans utiliser beaucoup de puissance de calcul.

Le GBA avait un processeur assez lent. L'ARM7 est très agréable; ils l'ont juste exécuté lentement et ne lui ont donné presque aucune ressource.

Il y a une raison pour laquelle beaucoup de jeux Nintendo à ce moment-là et avant étaient des défileurs latéraux. MATÉRIEL. Tout se fait en hardware. Vous aviez plusieurs couches de tuiles plus un ou plusieurs sprites et le matériel a fait tout le travail pour extraire les pixels de ces tables et piloter l'affichage.

Vous construisez la tuile à l'avant et avez ensuite une petite mémoire qui était une carte de tuiles. Vous voulez que la tuile inférieure gauche soit la tuile 7? Vous mettez un 7 dans cet emplacement mémoire. Vous voulez que la prochaine tuile soit la tuile 19? Dans le jeu de tuiles, vous y mettez un 19, et ainsi de suite pour chaque couche que vous avez activée. Pour le sprite, vous définissez simplement l'adresse x / y. Vous pouvez également effectuer une mise à l'échelle et une rotation en définissant certains registres et le matériel s'occupe du reste.

Le mode 7, si je me souviens bien, était un mode pixel, mais c'était comme une carte vidéo traditionnelle où vous mettez des octets qui couvrent la couleur d'un pixel et le matériel s'occupe du rafraîchissement vidéo. Je pense que vous pouvez jouer au ping-pong ou du moins lorsque vous avez un nouveau cadre, vous pouvez les retourner, mais je ne me souviens pas. Encore une fois, le processeur était assez sous-synchronisé pour ce jour-là et ne disposait pas de trop de ressources rapides. Donc, alors que certains jeux étaient en mode 7, beaucoup étaient des défileurs latéraux à base de tuiles ...

Si vous voulez une solution qui est une fréquence d'images élevée, vous devez concevoir cette solution. Vous ne pouvez pas simplement prendre n'importe quel ancien écran que vous trouvez et lui parler via SPI ou I²C ou quelque chose comme ça. Placez au moins un framebuffer devant, idéalement deux, et contrôlez les lignes et les colonnes si possible sur cet affichage.

Un certain nombre d'écrans que je soupçonne que vous achetez ont un contrôleur sur lequel vous parlez réellement. Si vous voulez des performances de type GBA / console, vous créez / implémentez le contrôleur. Ou vous achetez / construisez avec un GPU / une puce vidéo / un blob logique et utilisez HDMI ou une autre interface commune dans un moniteur de stock.

Ce n'est pas parce qu'un vélo a des pneus, une chaîne et des engrenages qu'il peut aller aussi vite qu'une moto. Vous devez concevoir le système pour répondre à vos besoins de performance de bout en bout. Vous pouvez mettre cette roue de vélo sur cette moto, mais elle ne fonctionnera pas comme souhaité; tous les composants doivent faire partie de la conception globale.

Les astéroïdes ont également fonctionné de cette façon; il n'en fallait qu'un 6502. Les graphiques vectoriels ont été réalisés avec une logique distincte; le 6502 a envoyé une petite chaîne de données au contrôleur graphique vectoriel, qui a utilisé une ROM et ces données pour faire le tracé xy du faisceau et z, on / off ... Certains standups avaient des processeurs séparés pour gérer l'audio et la vidéo séparément de le processeur qui calcule le jeu. Bien sûr, aujourd'hui, la vidéo est gérée par des centaines, voire des milliers de processeurs séparés du processeur principal ...

Comment un appareil comme le GBA a-t-il atteint une fréquence d'images de près de 60 images par seconde?

Matériel.

Il a une mémoire graphique, qui peut ou non partager le même bus que la mémoire programme / données ... mais le bit important est qu'il dispose d'un processeur graphique qui lit la mémoire 60 fois par seconde et envoie les données à l'écran LCD à l'aide d'un interface optimisée conçue pour le faire efficacement.

Vous pouvez faire de même avec n'importe quel microcontrôleur moderne équipé d'un périphérique "interface LCD", par exemple le LPC4330 bien que cela puisse être excessif. Bien sûr, vous aurez besoin d'un écran LCD compatible.

Avec les microcontrôleurs rapides modernes (c.-à-d. ARM et non AVR) et un écran si petit, vous n'aurez probablement pas besoin de sprites ou d'un blitter pour accélérer les opérations graphiques. Avec un AVR 8 bits, cela peut être lent.

Mais peu importe le processeur, le fait de cogner l'interface à l'écran va être nul.

Je pense que l'Atari 2600 a utilisé le bit banging du processeur pour envoyer l'image au téléviseur. C'est un peu obsolète.