 |
Vendredi 23 mai 2025 - 11:00 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Une tonne d'informations sur les puces graphiques spécialisées de l'Amiga. Voici une conversation avec ]ay Miner, le concepteur de ces puces.
Le nouveau micro-ordinateur Amiga de Commodore contient un jeu de puces NMOS (métal-oxyde-semiconducteur à canal négatif) spécialisées qui fournissent de nombreuses et puissantes fonctions graphiques. L'aperçu de l'Amiga dans le numéro d'août de Byte a brièvement décrit ces puces. Plus tard, nous sommes retournés voir les détails et avons parlé à Bill Kolb, le directeur de l'ingénierie matérielle de l'Amiga, et à Jay Miner, le vice-président du développement des produits et le concepteur des puces. Jay Miner a également conçu le matériel graphique pour les ordinateurs personnels Atari VCS (2600), 400 et 800.
Bien que l'équipe de l'Amiga se soit fixée pour objectif de construire un micro-ordinateur à usage général, Bill Kolb affirme fermement "Nous ne voulions pas seulement des graphismes, nous voulions suffisamment de puissance pour faire de vrais graphismes animés où vous ne vous contentez pas de déplacer un sprite sur l'écran. Nous voulions franchir une nouvelle étape majeure et le VLSI [intégration à très grande échelle] était le seul moyen d'être aussi agressif et de maintenir les coûts à un niveau raisonnable".
L'Amiga était à l'origine l'idée de Jay Miner pour proposer la machine de jeu la plus puissante au monde mais au fur et à mesure que d'autres personnes ont rejoint l'équipe, cette conception a changé et des fonctionnalités, des capacités et plus de ROM (mémoire morte) ont été ajoutées au système.
Quels sont les noms des trois puces ?Bill Kolb : Agnus, Denise et Paula. Tous les canaux DMA (accès direct à la mémoire) résident dans Agnus. Agnus est une sorte de raccourci du générateur d'adresses. Denise gère la plupart des sorties vidéo. Les deux fonctions principales de Paula sont le son et les diverses fonctions d'entrées/sorties. Logiquement, c'est une seule grosse puce. Par exemple, Denise et Paula dépendent toutes deux d'Agnus pour leurs adresses mais il n'était pas possible de les réunir en une seule puce. Elles ont donc été séparées sur le plan fonctionnel et cela ressemble à un bloc de contrôle géant pour un programmeur en assembleur.
Schéma structurel d'Agnus
Quand ce projet a-t-il commencé ?Jay Miner : il a vraiment commencé avec la création de l'entreprise. Au début, l'accent était davantage mis sur le jeu vidéo que sur l'ordinateur personnel. Les objectifs de coûts étaient pour une machine beaucoup moins chère. Au début, nous pensions à 300 dollars ou moins.
À l'époque, nous prévoyions d'utiliser le processeur 68000 et nous ne nous attendions pas à avoir beaucoup de mémoire ou un lecteur de disquette intégré. La machine de jeu à bas prix n'aurait peut-être même pas de clavier mais elle aurait une haute résolution, une puce 68000 et des graphismes de qualité supérieure. Puis, au fil du temps, elle a sans cesse évolué. Les puces spécialisées ont aussi évolué. Les gens du logiciel nous ont convaincus d'intégrer des choses comme le dessin des lignes et le remplissage de façon matérielle.
Schéma structurel de Paula
Donc, même au
début, vous imaginiez des puces spécialisées pour les graphismes ?Oh, oui. J'ai réalisé le jeu de puces qui était dans l'Atari 400 et 800 et dans la machine Atari VCS originale. J'avais une bonne appréciation de la puissance des puces graphiques spécialisées. Nous étions loin d'avoir l'étendue des circuits qui se trouvent sur les puces aujourd'hui. Nous avions des visions d'une forme assez grossière de Blitter, rien d'aussi sophistiqué que le Blitter généralisé à trois entrées que nous avons maintenant.
Parlez-nous du Blitter.J'aime l'appeler "Bimmer" parce que c'est l'abréviation de "bit-mapped image manipulator". Le terme Blitter est un vestige de la littérature faisant référence au transfert de blocs. Cette machine fait du transfert de bloc mais elle fait beaucoup plus car elle a trois entrées, et ces trois entrées peuvent être combinées de nombreuses manières différentes.
Les opérations logiques qui peuvent être effectuées sont complètes. Si vous pensez à trois variables, vous pouvez effectuer 256 opérations logiques sur elles. Le Bimmer est conçu comme une machine non temps réel qui transforme des images d'un endroit à un autre ou inversement. Ses principales caractéristiques distinctives sont les fonctions logiques sur les quatre entrées et la capacité de décalage à barillet, de sorte que vous pouvez déplacer une image sur n'importe quelle limite de pixel. Seules deux des sources ont la capacité de décalage à barillet. En outre, le Bimmer peut effectuer des "modulos", ce qui signifie que si vous regardez une grande image dans une mémoire en mode point, le Bimmer peut opérer sur une petite partie de cette image. Lorsqu'il arrive à la fin de cette petite portion, vous ajoutez un modulo à l'adresse pour passer à la ligne suivante. C'est le cas de l'ensemble du circuit d'affichage : tous les plans de bits ont la même caractéristique, ce qui permet d'afficher une petite image à partir d'une image plus grande.
Nous sommes
assez familiers avec l'Atari 800 et ses puces. Pour faire un défilement horizontal et vertical, il fallait
réinitialiser le pointeur sur un nouvel octet.Vous ne pouviez déplacer qu'un seul octet avant de devoir réinitialiser les choses en mémoire. Ici, vous pouvez faire la même chose, mais vous pouvez aussi afficher une partie d'une mémoire plus grande. Il y a deux façons de procéder ici. Le moteur qui affiche les plans de bits à l'écran a également une capacité modulo, de sorte que l'adresse à la fin d'une ligne ne doit pas nécessairement être inférieure d'une unité à l'adresse du début de la ligne suivante. Elle peut être beaucoup plus petite. En changeant simplement le pointeur de début de l'écran entier, vous pouvez déplacer l'image dans la mémoire. Vous lui donnez une adresse de départ, qui est l'adresse du point en haut à gauche de l'écran. Vous lui donnez une longueur et une valeur modulo.
Ce serait toute la largeur ?Oui. Bien, ce serait la différence entre ce que vous montrez et la largeur totale. Il y a la possibilité de six plans de bits dans cet élément. Les plans de bits peuvent être regroupés en deux champs de jeu ("playfields") et chaque champ de jeu a son propre modulo et son propre registre de défilement horizontal, le même type de défilement horizontal que sur l'Atari 800. Nous avons pensé plusieurs fois à donner à chaque plan de bits son propre modulo, mais je n'ai pas trouvé d'affichage qui en fasse bon usage et le matériel supplémentaire ne semblait pas en valoir la peine. Tous les pointeurs, les modulos, les sauvegardes et l'additionneur 18 bits qui les fait fonctionner - en effectuant à la fois l'incrémentation et les sauts de modulo - sont sur Agnus, tout comme la logique de contrôle qui définit la priorité pour savoir lequel de ces canaux DMA arrive sur le bus à quel moment.
La ligne provenant du bloc logique de contrôle des priorités d'Agnus devrait en fait être appelée "DBR", ce qui signifie demande de bus de données. Mais ce n'est pas vraiment une demande, c'est une exigence, car Agnus a toujours le contrôle.
Comment déterminez-vous qui a la priorité ?La structure des priorités est vraiment intéressante. Il y a beaucoup de choses qui ont des créneaux horaires individuels qui se produisent, par exemple pendant le rafraîchissement horizontal (ou intervalle de suppression horizontale, "horizontal blanking"). Tous les transferts de données des sprites ont lieu pendant le rafraichissement horizontal et des intervalles de temps précis leur sont attribués. Chaque sprite dispose de son propre intervalle de temps, de sorte qu'il ne peut pas interférer avec le transfert des autres sprites.
Donc, après chaque
synchronisation horizontale, il y a des périodes de temps fixes ?Il y a des périodes de temps fixes pour ces transferts de données qui incluent les sprites, l'audio, qui a quelques périodes de temps [quatre canaux audio], le disque, le rafraîchissement, toutes ces choses sont assignées. Et l'affichage lui-même, bien sûr, est ici dans le temps d'affichage, donc dans un sens, il a aussi des intervalles de temps fixes ; il ne peut jamais rivaliser avec ces autres choses. Il s'agit de la plus haute priorité, de premier niveau. Ils ne sont pas en concurrence les uns avec les autres car ils sont toujours indépendants. Vous pouvez les avoir tous au même niveau de priorité sans vous en soucier. Et les choses qui ont la plus haute priorité sont celles de l'affichage et du transfert de données qui se font dans des intervalles de temps fixes pendant le rafraîchissement horizontal.
Les trois autres choses dont nous devons nous préoccuper sont le coprocesseur, le Bimmer et le processeur principal. C'est comme ça que ça se passe, dans cet ordre. Le coprocesseur est le deuxième plus important. C'est un coprocesseur en temps réel qui est fréquemment utilisé comme moteur en temps réel pour se synchroniser avec le faisceau pour diverses choses comme l'affichage et l'audio. Il récupère tous les cycles vides qu'il peut utiliser mais afin de ne pas le rendre trop gourmand, c'est une machine à un cycle sur deux au maximum. Elle recherche des cycles vides. Si elle en trouve un, elle l'utilisera mais elle n'en utilisera pas deux à la suite.
Dans la
première priorité, il n'y a pas d'espaces vides ?Oh, il y a des espaces vides, surtout en basse résolution. En basse résolution, la partie de l'écran comporte des espaces vides, une autre caractéristique clé de la machine. Notre résolution normale, ce que nous considérons comme une basse résolution normale - 320 points sur l'écran - laisse 50% d'espaces vides pendant l'affichage.
Il émet
un point et ensuite il a un peu de temps ?Non, l'émission de points est continue. Je parle des récupérations de mémoire pour gérer ces points, qui ont un cycle vide sur deux.
Et il y a
assez de temps pour basculer et laisser quelqu'un d'autre utiliser ce cycle de mémoire et ensuite rebasculer ?Oui, un cycle vide est toujours à disposition et pendant le rafraîchissement horizontal, pour maintenir ce concept, nous avons un intervalle sur deux assigné à un sprite ou à un rafraîchissement audio. Cela signifie que pendant le rafraîchissement horizontal, 50% des cycles de mémoire sont vides. Donc, en regardant l'ensemble du temps, environ 50% des cycles sont vides. La raison pour laquelle nous avons fait cela est que le processeur 68000 ne peut utiliser le bus efficacement que 50% du temps.
Pourquoi cela ?À cause de la façon dont il est conçu en interne. Il doit aller chercher une instruction, qui est un cycle de mémoire, décoder cette instruction et effectuer une opération comme le stockage de données. De la manière dont il est configuré, la durée - le nombre de tics d'horloge nécessaires pour décoder l'instruction - est presque égale au temps qu'il passe sur le bus. Ainsi, à la résolution la plus faible - 320 points sur l'écran - nous correspondons au processeur et celui-ci pense que le bus est vide parce qu'il s'intercale juste entre ces cycles d'affichage. C'est quelque chose qui est unique à cette machine. Et le processeur est heureux comme un poisson dans l'eau ; il pense qu'il a un accès complet au bus.
Si nous passons de 320 points à 640 points, cela remplit le temps d'affichage. Mais ce que je viens de dire reste vrai pendant le rafraîchissement horizontal. Le microprocesseur a le bus tout le temps qu'Agnus lui laisse. Le coprocesseur est une machine à tous les autres cycles. Il utilise les intervalles de temps comme il peut, en se basant sur ces règles.
Le Bimmer, par contre, est un vrai accapareur. Si un intervalle de temps est disponible, le Bimmer l'utilisera, surtout quand il est dans ce qu'on appelle le mode "méchant". Maintenant, il y a un mode où vous pouvez dire au Bimmer. "Hé, ne sois pas si méchant, ne prends pas autant de cycles, laisses-en pour le processeur principal au cas où il y aurait une interruption." Parce que si le Bimmer se met à opérer lourdement, il opère sur une grande surface d'écran de manière non réelle, en faisant tourner la mémoire. il peut monopoliser beaucoup de cycles de bus. Bien sûr, c'est le bras droit du processeur principal, donc il fait des choses que le processeur principal devrait faire autrement, en termes de manipulation graphique. Néanmoins, si vous voulez être un tant soit peu réactif aux interruptions - et dans une machine multitâche comme celle-ci, vous devez être réactif aux interruptions - vous devez disposer d'un mode dans lequel, de temps en temps, le pilote fait une pause et dit : "Ok, processeur, je vais te donner quelques intervalles de temps".
Nous sommes
curieux d'en connaître davantage sur le matériel des sprites.Contrairement à l'Atari 400 et 800, nous n'avons pas de sprites "joueurs" avec une carte de bits verticale. L'idée était d'économiser les registres verticaux et les comparaisons verticales dans le matériel et de les mettre dans le logiciel en demandant au programmeur de repositionner l'image dans la carte de bits verticale.
Schéma structurel des puces de l'Amiga 1000
C'était une
conséquence directe de la façon dont on représentait les joueurs sur l'Atari 2600, où ils n'avaient qu'une ligne
de long et un bit de large. Vous deviez les redéfinir à la volée pour chaque ligne vidéo. Une extension
logique serait de les rendre bidimensionnels.Ce n'était pas tant ça. Vous voyez, l'Atari 2600 n'avait pas de carte de bits du tout, sauf dans la ROM, où il y avait quelques cartes de bits d'images de sprites. Tous ces éléments étaient créés à la volée. J'étais vraiment limité sur l'espace de registre - les règles de conception étaient grandes - nous essayions d'économiser autant de matériel que nous pouvions et de mettre les fonctions dans le logiciel. Nous avons donc eu l'idée que si nous n'avions pas du tout de comparateurs verticaux et pas de registres de position verticale, nous obtiendrions un sprite qui ne serait pas un vrai sprite dans les deux directions, mais seulement dans la direction horizontale. Dans la direction verticale, c'est une carte de bits. C'est le concept que nous avons breveté sur la machine Atari. Nous ne l'avons pas du tout ici sur Amiga. Nous avons un sprite polyvalent à la fois horizontal et vertical, un concept de sprite classique avec une position de départ verticale et une position de fin verticale.
Le sprite a
une largeur de 16 bits, mais il peut avoir n'importe quelle hauteur ?Il peut avoir n'importe quelle hauteur parce qu'il peut avoir n'importe quelle position de départ et de fin, mais sa hauteur n'est pas liée à l'image de la carte de bits comme c'est le cas sur les Atari 400 et 800. Sa hauteur est liée au nombre de lignes donné par un registre de contrôle de démarrage et un registre de contrôle de fin. Il y a huit moteurs de sprites. Chacun a une profondeur de deux bits (ce qui permet d'avoir quatre couleurs par sprite) et une largeur de seize bits en basse résolution (au taux horizontal de 320 points).
Quels choix
avez-vous pour les quatre couleurs ? Y a-t-il une table de couleurs distincte pour chaque sprite ?Il y a une table de couleurs séparée, mais pas pour chaque sprite. Il y a un certain partage qui doit se faire. Nous n'avons que 32 registres de couleurs et ils doivent être partagés entre les champs de jeu et les sprites. Parfois, le champ de jeu utilise seize des trente-deux couleurs et les sprites ont les seize autres. Parfois, certaines d'entre elles sont partagées, en fonction du nombre de couleurs que vous essayez d'afficher sur le champ de jeu. Ces huit sprites peuvent être combinés pour créer quatre sprites de quatre bits de profondeur avec seize couleurs chacun. Cependant, la résolution totale des sprites n'est pas aussi fine que celle du champ de jeu haute résolution.
Comment obtenir
plus de huit sprites ?Vous pouvez réutiliser les moteurs de sprites quand vous le souhaitez.
Vous voulez
dire qu'il suffit de les réinitialiser entre les images ?Vous les réinitialisez horizontalement ou verticalement. Une fois que vous avez fini d'en utiliser un verticalement, vous devez attendre un temps de ligne avant de pouvoir utiliser le même moteur à nouveau verticalement. Vous pouvez utiliser le même moteur à plusieurs reprises sur une ligne horizontale si vous disposez de suffisamment de temps processeur ou de temps coprocesseur pour réécrire les registres.
Lorsque vous
émettez des données RVB, comment sont-elles restituées ?Elles sortent sur quatre bits, quatre bits et quatre bits.
Et c'est comme ça que les moniteurs RVB
prennent normalement leurs informations ?Sur la puce, elles vont dans une échelle. Il y a trois groupes de quatre bits qui sortent directement des trente-deux registres de couleur puis il y a une échelle à quatre résistances sur chacun d'eux qui les convertit en trois valeurs analogiques. C'est ce qui va vers les moniteurs.
Ensuite, les
valeurs de ces données analogiques - que vous avez modifiées à partir des données numériques - déterminent
la puissance de chacun des canons RVB lorsqu'ils tirent sur un point particulier ?Oui. sur le RVB dit analogique. Il y a deux types de RVB : numérique et analogique. Il est important de le souligner parce que quand IBM parle de seize couleurs, en réalité il s'agit de deux nuances de huit couleurs, et ces deux nuances sont toujours de la même couleur, il n'y a aucun moyen de les changer. C'est ce que l'on appelle le RVB numérique, ou RVBi. Il y a le rouge qui s'allume et s'éteint, le vert qui s'allume et s'éteint, le bleu qui s'allume et s'éteint, et un niveau d'intensité qui détermine la luminosité ou l'obscurité pour chacune d'entre elles. C'est un contrôle à quatre fils, mais c'est complètement numérique. Nous l'avons aussi mis en place pour être compatible, mais nous avons aussi mis en place le RVB analogique, qui a quatre bits, quatre bits et quatre bits, en échelle, donc vous obtenez seize valeurs de rouge, seize valeurs de vert et seize valeurs de bleu. C'est équivalent à 212 couleurs et luminances totales.
Donc,
sur la sortie analogique, vous pouviez avoir le nombre de bits que vous vouliez ? Vous pouviez mettre dix bits
sur chaque ligne ?Oui, si vous aviez des registres assez grands. En fait, c'est probablement l'une des choses que nous allons développer dans le futur jeu de puces.
Pourquoi avoir
choisi quatre bits en premier lieu ?À l'origine, il ne devait pas s'agir de RVB, mais de la norme NTSC [National Television System Committee]. Le NTSC travaille sur l'intensité, la teinte et la saturation. La couleur et la luminance. Ils l'appellent YIQ. Le "Y" est l'intensité, et le "I" et le "Q" définissent un vecteur qui détermine la saturation. Avoir quatre bits pour chacun d'entre eux était à peu près le mieux que nous pouvions faire en termes d'échelles sur puce qui prendraient les quatre bits pour chacun d'entre eux et les convertiraient en un angle de phase réel.
Donc,
cette échelle est sur Denise ?Non. C'était quand nous avions le YIQ ; quand nous mettions l'accent sur le NTSC. nous avions une échelle à bord. Puis nous l'avons déphasé. Nous avons trouvé une puce Motorola qui faisait un bon travail de conversion de RVB en NTSC. Nous avions besoin de l'espace supplémentaire sur la puce Denise pour une meilleure résolution des registres de couleur, donc nous avons complètement abandonné le YIQ NTSC. Mais nous sommes restés sur les quatre, quatre, quatre bits. De plus, il y a une réelle limitation des broches sur une puce comme celle-ci. Nous avons essayé de garder la puce simple et peu coûteuse à fabriquer et les échelles sur puce prennent beaucoup de place. Elles sont notoirement imprécises et vous pouvez acheter des résistances externes de 1% pour un centime pièce.
Schéma structurel de Denise
Y a-t-il
encore une sortie NTSC sur l'Amiga ?Dans le boîtier, oui. Mais pas dans les puces.
Expliquez-moi
un peu mieux les plans de bits. Vous avez des 1 et des 0 en mémoire et vous les superposez ; vous regardez
un groupe d'entre eux simultanément pour déterminer la couleur d'un élément qui se trouve à l'écran. Avez-vous
une adresse pour le début de chaque zone de plan de bits ?Oui. Le concept de plans de bits est très profondément ancré dans cette architecture. Il y a vraiment deux concepts d'affichage contradictoires. L'un est l'adressage par pixel, l'autre l'adressage par plan de bits. Nous avons choisi le plan de bits. Une des raisons de notre décision est que nous voulions faire un remplissage de zone très efficace.
Vous voulez dire
remplir une zone particulière de l'écran ?Oui, et cela se fait très bien et efficacement avec l'adressage par plan de bits sur une base de plan de bits unique. Nous voulions avoir beaucoup de variété dans le nombre de plans de bits que vous pouvez spécifier. Nous voulions avoir nos deux structures écran séparées, chacune avec un nombre contrôlable de plans de bits. Nous ne voulions pas gaspiller beaucoup de transferts de données si nous avions moins de plans de bits que les autres. Nous avons donc décidé de ne pas transférer les données par pixel, ce qui fait perdre beaucoup de temps de transfert si vous n'utilisez pas tous vos pixels ou tous les bits d'un pixel. Même si vous ne les utilisez pas tous, vous devez toujours les adresser et cela prend toujours un cycle de mémoire. Lorsque vous êtes orienté plan de bits, si vous n'avez que deux plans de bits au lieu de huit, puisque vous déplacez les données à partir d'un seul plan de bits, cela n'a pas d'importance car vous utilisez tous les bits qui passent. C'est pour cette raison qu'il a été créé : pour améliorer l'efficacité des transferts de données et des transferts de sprites pour différents nombres de plans de bits et différentes organisations.
Lorsque le Bimmer
fonctionne sur ses trois sources et envoie à sa destination, fonctionne-t-elle sur des parties de plans de bits ?Il fonctionne toujours sur un seul plan de bits à la fois. Si vous voulez faire une image avec plusieurs plans de bits, il suffit de faire la même routine et de la diriger vers l'endroit où se trouve l'autre plan de bits.
Mais il ne peut
pas prendre un bloc et le déplacer du plan de bits numéro 1 vers le plan de bits numéro 2 ?Il pourrait, bien sûr. Mais ce n'est pas comme ça que cela se passe normalement. Habituellement, vous définissez les plans de bits et vous opérez sur eux comme s'ils étaient des images l'une derrière l'autre.
L'écran que
vous avez et qui regarde une section de la grande image regarde en fait les plans de bits empilés les uns
sur les autres ?Non. Les plans de bits ne sont jamais vraiment empilés.
Eh bien, dans la
mémoire alors, parce que la mémoire est juste étendue.La mémoire est contiguë, d'accord. Donc les plans de bits sont vraiment situés séparément dans la mémoire, mais comme ils sont récupérés par le canal DMA de plan de bits, un mot à la fois de chaque plan de bits, ils sont placés dans ces registres de maintien dans Denise. Ensuite, quand le plan de bits numéro 1 arrive, ils savent qu'ils ont tous été remplis, donc vous les convertissez simultanément de parallèle à série et commencez à les faire sortir. Pendant qu'ils sortent, le parallèle est rechargé pour être prêt pour la prochaine sortie. Pendant qu'ils sortent, vous les regardez comme s'ils étaient un pixel, à un seul instant dans le temps.
Quelle est
la place du décaleur à barillet ("barrel-shifter") ?La fonction "barrel-shift" du Bimmer permet de déplacer des images sur des frontières de pixels. Sans cette fonction, le concept de plan de bits ne fonctionnerait pas du tout. Lorsque vous faites de l'adressage par pixel, comme chaque pixel a sa propre adresse, pour déplacer un élément d'un pixel, il suffit d'incrémenter l'adresse de 1. Il n'y a aucun problème à déplacer des objets en utilisant l'adressage par pixel sur des limites de pixels arbitraires. Mais lorsque vous utilisez des techniques de plan de bits comme nous le faisons, où chaque mot représente un ensemble de pixels d'un plan de bits, alors pour déplacer cette image dans un mot, dans une limite d'un seul pixel, vous devez la décaler d'un nombre arbitraire de 0 à 15.
Même à
travers les mots ?Oui. C'est ce que vous permet de faire le décalage. Lorsque les données sont transférées de la source à la destination, vous pouvez les déplacer d'un nombre arbitraire de pixels.
Pouvez-vous
expliquer le processus du défilement ?Les plans de bits ont besoin des bits de sortie du compteur de synchronisation horizontale parce qu'ils doivent récupérer les données encore et encore sur la ligne. Ils doivent également effectuer un défilement. Les plans de bits intègrent une capacité de retardement appelée défilement horizontal. En fait, ce défilement matériel retarde la récupération des données pour qu'elles s'affichent plus tard sur l'écran. Pour cela, il faut avoir un compteur qui provoque un retard de 0 à 15 bits.
Ce qui s'affiche à l'écran est la taille de l'affichage de l'écran. L'image en mémoire peut être beaucoup plus grande que cela, et elle peut avoir plusieurs plans de bits. Il y a deux façons de modifier ce qui s'affiche à l'écran. L'une consiste à faire défiler horizontalement et en douceur de 0 à 15 bits dans un mot. L'autre est de changer le pointeur d'une valeur de mot entier. Ainsi, vous pouvez déplacer la chose simplement en changeant le pointeur. Si vous arrivez au bord de la grande image, vous devez faire quelque chose dans le logiciel : déplacer des blocs, etc.
Qu'en
est-il des informations transmises aux contrôles des plans de bits et de toute l'interaction entre
les plans de bits et les sprites ? La détection des collisions n'a rien à voir avec ce qui est montré :
elle vous indique simplement quand quelque chose s'est produit, non ?Exactement. La détection des collisions consiste à observer en temps réel l'apparition simultanée d'objets. Les sprites sont sur les seize lignes du bloc "sprite-serialize" et les plans de bits sont sur les six lignes du bloc "bit-plane-serialize". Toute occurrence simultanée et en temps réel de plus d'un objet au niveau de la logique de détection des collisions sera détectée et stockée dans un verrou du registre de stockage des collisions. Le programme ou le programmeur peut relire ce registre à tout moment.
Comment
savez-vous qu'il y a un objet ici s'il y a toujours une sorte de donnée sur la ligne ? Si
cette ligne est basse, alors vous supposez que ce n'est pas une donnée ?C'est ça. 0, c'est toujours rien. 0 est la transparence.
Mais la
collision est plus compliquée qu'un simple "Il y a deux choses ici".Le contrôle des collisions est assez complexe. Nous avons une capacité dans cette machine que je n'ai jamais vue dans aucune autre machine auparavant. Prenons un champ de jeu comprenant quatre plans de bits. Voici un sprite qui arrive. Il peut entrer en collision avec le champ de jeu en frappant n'importe lequel de ces plans de bits. Toute cette architecture est orientée vers les plans de bits plutôt que vers les pixels. Je peux entrer en collision avec n'importe quel plan de bits ou masquer n'importe quel plan de bits de la collision. Je peux aussi inverser la polarité du plan de bits avec lequel je vais entrer en collision. Le registre de contrôle de collision décide quels plans de bits sont examinés par le moniteur de collision et avec quelle polarité. Vous pouvez être très pointilleux sur les types de champs de jeu avec lesquels les sprites entrent en collision. En utilisant tous les plans de bits et en obtenant la bonne polarité, vous pouvez avoir une collision avec n'importe quelle couleur individuelle.
Avec la
possibilité de 128 sprites virtuels et les différents plans de bits, il semble que le registre
de contrôle des collisions doive tenir compte d'un nombre énorme de choses.Eh bien, le registre de contrôle des collisions ne garde pas la trace de ces sprites virtuels. Il ne garde la trace que des collisions du moteur des sprites réels. Pour les sprites réels, vous utilisez le registre de contrôle des collisions à chaque fois qu'il y a un rafraîchissement vertical et si un sprite est entré en collision au cours de l'image précédente, vous savez qu'une collision s'est produite.
|
